Why sometimes C code gets wrapped with curly braces without declaring a variable in them?
e.g. (from FreeRTOS source code, file 'tasks.c'):
portENTER_CRITICAL();
{
xTicks = xTickCount;
}
portEXIT_CRITICAL();
This is just an inner scope. The benefit is that code shows your intent in that case. e.g. This scope is the critical section.
There is no need to use curly braces like this, but it helps readability.
It's a choice of style by the author, I suppose :)
Related
Some of my code got a review comment saying something like "move const outside the function to avoid redeclaration". This was a normal function component, something like this:
export default function someComponent() {
const someString = 'A string';
///...
}
I was confused about the idea of this causing a redeclaration, because it does not, I know that the record that holds the variables and constants belong to the scope, so it's not exactly that.
But then i remembered that typescript does not allows you to have a const inside a class, not sure about the reason or is this is related. But then ts added the readonly modifier in ts v2, so the confusion remains.
Should const be outside function components, or not?
I would love to know more opinions.
There are 2 sides to the coin. Firstly, in terms of clean code and readability, I strongly prefer local declarations like in your example. I would love using more nested functions as well.
However, in JavaScript, every time the function executes, the local definitions will be redeclared, even if they are constants or functions. So it's a trade-off. If the function is called many times, this becomes an overhead.
I think it would not be hard for a compiler like TypeScript's tsc or some other pre-processor to extract those definitions at compile time to have best of both worlds. But it's likely that they do not do this to remain fully compatible. I am not aware of such tools but would be interested if there are some.
The docs say that a JSX attributes with strings are the same as attributes with braces...
<Thing attr='val' /> === <Thing attr={'val'} />
I thought I read something that said only use braces when needed because strings are more performant, but I can't find the reference now. Is there an evaluation cost for braces?
No there is no performance difference. Look at the code that's generated by each style:
<div first="abc" second={"def"}/>
// Compiles to:
React.createElement("div", { first: "abc", second: "def" });
Nicer to avoid unneeded braces though.
JSX is actually parsing it to a JS object anyway, so it's either string creation overhead for the parser or string creation overhead in your component. It's trivial either way. With a string literal, though, it's just visually noisy in the code. It only really serves a purpose if the val is a variable or expression.
There is, however, a perfomance hit in a templating engine, such as that employed by the new interpolated strings. E.g.:
`It is a ${'cat'}`
would be slower than:
`It is a dog`
which should be slower still than just a plain literal:
'It is a dog'
I'll leave it as an exercise for the reader to find the interpolation part in the JSX engine. ;) https://github.com/jsx/JSX/tree/master/src
Is there an evaluation cost for braces
Yes, As you can see anything inside {} will be considered as javascript code, so that will be executed , if you just want to assign the string then
just simply use the attr='val' rather than attr={'val'}
but if you have assignment condition based then you can use attr={'val'}
like
attr={ (condition) ? 'val1' : 'val2'}
I Hope , this will clear your thoughts.
For more details :
https://reactjs.org/docs/jsx-in-depth.html
Here you can read behind the scenes of string interpolation and speed performance :
https://koukia.ca/string-interpolation-vs-string-format-string-concat-and-string-builder-performance-benchmarks-c1dad38032a
Example:
.. member:: CK_UTF8CHAR model[16]
Gives me both the type and the name bolded and hyperlink not working.
Practically we are forced to use this cases like that:
.. member:: model
Because otherwise it would be incorrect (use it without array and with the same type).
Well, this seems to be a real bug in Sphinx. I reported that and it was confirmed. I've come up with a little workaround for now, but it's more of a crutch. Just put the following to the layout.html file of your Sphinx theme:
<script>
$('dl.member dt').each(function() {
$(this).find('big:first').text('[')
$(this).find('big:last').text(']')
});
</script>
Now you may use parenthesis instead of brackets in broken structures: model(16) becomes model[16] (and label(\ ) becomes label[], but only within the .. member:: directive.
I know it is not a very elegant solution, but it is OK as a temporary fix, until the bug gets resolved.
I'm customizing the standard "c.vim" syntax file in order to tune the visualisation of my C code.
I would like to distinguish the color of the "called functions" from the one of the "declared functions".
Exemple:
int declared_function()
{
int m;
m = called_function();
return (m)
}
I read in depth the VIM documentation, and millions of forums and google results, but all the solutions I tried didn't work.
To resume, I did this:
I defined a region in a recursive way in order to consider all the code within the braces:
syn region Body start="{" end="}" contains=Body
Then I defined through VIM patterns a general function syntax:
syn match cFunction "\<\h\w*\>\(\s\|\n\)*("me=e-1 contains=cType,cDelimiter,cDefine
I did this because I thought I could combine the two in a "if else" condition in the .vimrc file... but after a whole day of failing tests I need the help of someone, who can tell me if it's possible and how to do it.
Thanks everybody.
You're very close. First, you don't need the recursive definition, but contain all other top-level C syntax elements in it, plus the special group you'll define for called functions:
:syn region Body start="{" end="}" contains=TOP,cFunctionUse
Actually, scratch that, the default $VIMRUNTIME/syntax/c.vim already defines a cBlock syntax group.
Then, define a different syntax group that is contained in the cBlock group.
:syn match cFunctionUse "\<\h\w*\>\(\s\|\n\)*("me=e-1 contained containedin=cBlock contains=cType,cDelimiter,cDefine
Finally, link or define a different highlight group for it, so that it actually looks different:
:hi link cFunctionUse Special
You can put those into ~/.vim/after/syntax/c.vim, so that they'll be added automatically to the default C syntax.
I thought the below was a neat way to implement enums in C.
struct states
{
enum
{
waitPackage,
waitReference,
waitData
};
}state;
This adds some type safety and I can also acces each member through state.XXX which I think is a lot more neat than prepend all the names of the enum items, and access the members in a fashion like state_XXX. Or what do you think, have I missed something?
However, I cant use the enum above in a switch-case statement as the compiler says that state isn't a constant.
Is there a way to tell the compiler that I don't intend to change the members of the enum ot it could be used in switch-case? Or another way to accomplish what I would like here?
In a C++ I solved it by placing the enums in namespaces but thats a not an option here.
Types in C are always global and never nested. So there is no way to have scoped constants.
Thus the :: notation is not allowed in C, it is not part of the syntax. E.g your constants as waitPackage are visible as such everywhere.