Is uv_prepare_init deprecated?
In uv.h there is a function definition, but nowhere I could find the function body in C file. However, on documentation, there are no keyword, as deprecated.
Is there any solution to replace uv_prepare_init?
I need this handle for executing before polling I/O.
uv_prepare_init isn't deprecated.
See the file loop-watcher.c for more details. It's available both for unix (libuv/src/unix) and windows (libuv/src/win).
So, what's the magic?
How is it that there is no definition but the function is part of the library?
Macros. That's all. The definition is there, even though a bit obfuscated.
There exists a macro called UV_LOOP_WATCHER_DEFINE, a part of which follows:
#define UV_LOOP_WATCHER_DEFINE(name, type) \
int uv_##name##_init(uv_loop_t* loop, uv_##name##_t* handle) { \
uv__handle_init(loop, (uv_handle_t*)handle, UV_##type); \
handle->name##_cb = NULL; \
return 0; \
} \
// ... continue ...
Immediately after the definition, the macro is used as:
UV_LOOP_WATCHER_DEFINE(prepare, PREPARE)
You can easily do the substitution for yourself and find that it's actually defining uv_prepare_init.
Therefore we can say that the function is part of the library, it isn't deprecated (at least in v1.x) and you can freely use it for your purposes.
No need to replace it in any way.
Related
I want to use macro parameter like this:
#define D(cond,...) do{ \
#if cond \
#define YYY 1 \
#else \
#define YYY 0 \
} while(0)
Is it possible?
UPD
Maybe when sources will be preprocessed twice: gcc -E source.c | gcc -xc - next will work:
#define D(cond,...) #define YYY cond&DEBUG
#if YYY
#define D(...) printf( __VA_ARGS__ )
#else
#define D(...)
#endif
No, because C 2011 [N1570] 6.10.3.4 3 says, about macro replacement, “The resulting completely macro-replaced preprocessing token sequence is not processed as a preprocessing directive even if it resembles one,…”
This is not possible. Read about the GNU cpp preprocessor and the C11 standard (i.e. n1570), and check here. The C preprocessor is (conceptually at least) run before the rest of the compiler (which gets the preprocessed form of your translation unit). BTW, for a file foo.c you could use gcc -C -E foo.c > foo.i (using GCC) to get inside foo.i its preprocessed form, and you can inspect that foo.i -since it is a textual file- with a pager or an editor.
However, a .c file can be generated (generating C code is a common practice, at least since the 1980s; for example with yacc, bison, rpcgen, swig, ....; many large software projects use specialized generators of C or C++ code...). You might consider using some other tool, perhaps the GPP preprocessor (or GNU m4) or some other program or script, to generate your C file (from something else). Look also into autoconf (it might have goals similar to yours).
You may want to configure your build automation tool for such purpose, e.g. edit your Makefile for GNU make.
No, this is not possible.
During translation, all preprocessing directives (#define, #include, etc.) are executed before any macro expansion occurs, so if a macro expands into a preprocessing directive, it won't be interpreted as such - it will be interpreted as (invalid) source code.
As pointed out by others this is not possible but there is a work around:
int YYY;
/* global scope variables are sometimes considered bad practice... */
#define D(cond,...) do{ \
if (cond) { \
YYY = 1; \
} \
else { \
YYY = 0; \
} \
} while(0)
Use an optimizing flag (ex: gcc/clang -O3) and it will replace the dead code as if it was a macro. Obviously you may want to change the type of YYY but you seem to use it like a boolean.
No, you cannot. The C preprocessor cannot know what is going to occur during runtime.
The preprocessor goes through the program before it is even compiled and replaces every macro defined with its assigned value.
This is some poor man's code generation, for when integrating another tool to the project is overkill.
Define a macro like this, expanding for your needs:
#define NESTED /* Comment out instead of backslash new lines.
*/ /*
*/ UNDEF REPLACED /*
*/ /*
*/ IFDEF CONDITION /*
*/ DEFINE REPLACED 1 /*
*/ ELSE /*
*/ DEFINE REPLACED 0 /*
*/ ENDIF
Your version of NESTED can be a function-like macro, and REPLACED can have a more elaborated body.
Leave CONDITION and the directive named macros without a definition.
DEFINE CONDITION to control which value NESTED gets on compilation, similarly to normal #ifdef usage:
DEFINE CONDITION
NESTED
int i = REPLACED; //i == 1
UNDEF CONDITION
NESTED
int z = REPLACED; //z == 0
Source code that uses NESTED and the other macros will not compile. To generate a .c or .cpp file that you can compile with your chosen options, do this:
gcc -E -CC source.c -o temporary.c
gcc -E \
-DDEFINE=\#define -DUNDEF=\#undef \
-DIFDEF=\#ifdef -DELSE=\#else -DENDIF=\#endif \
temporary.c -o usableFile.c
rm temporary.c #remove the temporary file
-E means preprocess only, not compile. The first gcc command expands NESTED and all normally defined macros from the source. As DEFINE, IFDEF, etc. are not defined, they and their future arguments remain as literal text in the temporary.c file.
-CC makes the comments be preserved in the output file. After the preprocessor replaces NESTED by its body, temporary.c contains the directive macros in separate lines, with the comments. When the comments are removed on the next gcc command, the line breaks remain by the standard.
# is accepted in the body of a macro that takes no arguments. However, unlike macros, directives are not rescaned and executed on expansion, so you need another preprocessor pass to make nested defines work. All preprocessing related to the delayed defines needs to be delayed too, and made available to the preprocessor at once. Otherwise, directives and arguments needed in a later pass are consumed and removed from the code in a previous one.
The second gcc command replaces the -D macros by the delayed directives, making all of them available to the preprocessor starting on the next pass. The directives and their arguments are not rescaned in the same gcc command, and remain as literal text in usableFile.c.
When you compile usableFile.c, the preprocessor executes the delayed directives.
Browsing through MRI's code, I found these #defines I don't understand:
#define ROBJECT_EMBED_LEN_MAX ROBJECT_EMBED_LEN_MAX
#define ROBJECT_EMBED ROBJECT_EMBED
enum {
ROBJECT_EMBED_LEN_MAX = 3,
ROBJECT_EMBED = RUBY_FL_USER1,
ROBJECT_ENUM_END
};
What's the point of those #defines? They seem to do nothing...
This code is found in the ruby/include/ruby/ruby.h file in the ruby github repo.
The #defines make it possible to test for the existence of the definition at compile-time using #ifdef. (You cannot test for the existence of an enum at compile-time.)
Since the C preprocessor doesn't do recursive substitution, defining a symbol as itself effectively does nothing; the symbol is replaced once with itself, and then passed normally to the compiler.
I'm writing C code which requires me to use multiple function calls of the same definition which differ only by single characters. Is there a way I can make a macro function which takes say a number and can insert these calls into my code for me where I call the macro given I know the numbers at compile time:
i.e.
#define call_pin_macro(X)
enable_pin#X();
do_thing_pin#X();
do_other_thing_pin#X();
.
.
void pin_function(void){
call_pin_macro(1);
call_pin_macro(2);
call_pin_macro(3);
}
Instead of:
void pin_function(void){
enable_pin1();
do_thing_pin1();
do_other_thing_pin1();
enable_pin2();
do_thing_pin2();
do_other_thing_pin2();
enable_pin3();
do_thing_pin3();
do_other_thing_pin3();
}
As a note I have looked at stringification (Hence the included #X's) in gcc however I cannot get the above code to compile which I get an error "error: '#' is not followed by a macro parameter". And it thus it seems this isn't exactly the functionality I am after. Thanks in advance.
In gcc you can do it like this:
#define call_pin_macro(X) \
enable_pin##X(); \
do_thing_pin##X(); \
do_other_thing_pin##X();
The double hash is the macro concatenation operator. You don't want to use stringify because that will put quotes around it.
The backslashes allow you to continue the macro over several lines.
I have this bit of code (part of an interpreter for a garbage-collected Forth system, actually):
#define PRIMITIVE(name) \
do \
{ \
VocabEntry* entry = (VocabEntry*)gc_alloc(sizeof(VocabEntry)); \
entry->code = name; \
entry->name = cstr_to_pstr(#name); \
entry->prev = latest_vocab_entry; \
latest_vocab_entry = entry; \
} \
while (false)
PRIMITIVE(dup);
PRIMITIVE(drop);
PRIMITIVE(swap);
// and a lot more
but there's a problem: in the line
entry->name = cstr_to_pstr(#name);
the name field is substituted for dup, drop, swap, and the rest. I want the field name to not be substituted.
So, is there any way to solve this, other than simply renaming the macro argument?
For an answer, please explain if there is, in general, a way to suppress the substitution of a macro argument name in the macro body. Don't answer "just do it this way" (please).
You can define a different macro to expand to name, like this:
#define Name name
and change the name field in the PRIMITIVE macro to use the new macro, like this:
#define PRIMITIVE(name) \
do \
{ \
VocabEntry* entry = (VocabEntry*)gc_alloc(sizeof(VocabEntry)); \
entry->code = name; \
entry->Name = cstr_to_pstr(#name); \
entry->prev = latest_vocab_entry; \
latest_vocab_entry = entry; \
} \
while (false)
Other than using something different from the parameter name in the macro body or changing the parameter name, there is no other way to do this in the C language. Per C 2011 (N1570) 6.10.3.1 1, when a function-like macro is recognized, parameter names are immediately substituted except when # or ## is present, and there no other exceptions:
After the arguments for the invocation of a function-like macro have been identified, argument substitution takes place. A parameter in the replacement list, unless preceded by a # or ## preprocessing token or followed by a ## preprocessing token (see below), is replaced by the corresponding argument after all macros contained therein have been expanded.
The # token changes the parameter name to a string, which is no use in this situation. The ## token expands the parameter name and pastes it together with an adjacent token, which is also no use in this situation.
No, there is not.
To see why, you need to consider the way macro expansion actually happens. Expanding a function-like macro requires three main steps:
the arguments to the macro are fully expanded, unless the macro uses the # or ## operators on them (not relevant in the example since they're single tokens)
the entire replacement list is scanned, and any occurrence of a parameter name is replaced by the corresponding argument
after step 2 is complete, the expanded replacement list is itself rescanned, and any macros appearing are expanded at this point
This is outlined in standard section 6.10.3 (C11 and C99).
The upshot of this is that it is impossible to write some kind of macro that can take name and abuse the suppression-rules of '##' or anything like that, because the replacement step in the body of PRIMITIVE must run completely before any of the macros within the body are allowed their turn to be recognised. There is nothing you can do to mark a token within the replacement list for suppression, because any marks you could place upon it will only be examined after the replacement step has already run. Since the order is specified in the standard, any exploit you find that would let you mark a token in this way is a compiler bug.
Best I can suggest if you're really set on not renaming the macro argument is to pass na and me as separate arguments to a concatenation macro; the token name will only be formed after replacement is done and the list is no longer being examined for parameter names.
EDIT wish I typed faster.
No, there is no way to suppress the replacement within a macro's body of a token identical to that of a declared argument to said macro. Every possible solution short of jumping into the preprocessor code will require you to rename something, either the argument name or the name of the field (potentially just for purposes of that macro, as Eric's answer does).
Normaly if I make a small code snipet, I usually put it in a whathever.c - file. From the C-file I include a .h -file with other includes or some global varaibles.
I've just heard that the compiler makes the code in a header faster, or somtehing I would love if someone could explain or comment this.
Example code in a header instead of a c-file (could be in a c) ->
#define PWM_INTERRUPT \
void InterruptHook(void) \
{ \
PR4 ^= _SoftPWM_Toggle; \
\
PIR3bits.TMR4IF = 0; \
\
_asm \
INCF PR4,0,ACCESS \
CPFSLT TMR4,ACCESS \
_endasm \
\
/* if(TMR4 > PR4) */ \
PIR3bits.TMR4IF = 1; \
\
SOFT_PWM_PIN ^= 1; \
\
_asm \
RETFIE 1 \
_endasm \
}
You can't put a macro in a separate .c file, because macros are handled by the preprocessor, which is the first step in the compilation process, and separate .c files are handled in the link stage, which is the last step.
Using a macro instead of a function might be faster, because it avoids the overhead of a function call. However, it will slow your compiles down because it compiles the same code multiple times. It will make your code larger because of redundant copies. If caching is an issue, it might actually run slower because of repeatedly fetching different redundant copies into cache. There's no way to know for sure without profiling.
If you're talking about the difference between putting a macro in the same .c file and a header file, there's no difference performance-wise. You just would have to copy and paste it into every .c file that uses it.
The "rumor" you heard relates to the way some compilers (most notable C++) tend to inline code that it is placed in a .h file.
This link (Michael Barr's) provides some very good tips on what belongs (and doesn't belong) in a C header file.
Before anything in your .c/.cpp file is compiled the preprocessors replaces all of the #include directives with the content of the given *.h file => This end up in a single file for the compiler => No difference in performance between source and header files.
In your example, the macro was defined in a header file in order to be used in multiple compilation units (c files) - I doubt it has anything to do with speed.
Acctually, another answer is: When declaring the high priority interrupt within a macro, the code within the macro is the only one going there, thous doing the interrupt handler fast.
When I define the interrupt outside the macro as a ordinary function, I noticed a lot of code put in the interrupt rutine by the compiler, code I could'nt see whitout using Disassambly Listing in MPLAB IDE.
The later slowing down my rutine fron 16 cycles to 168.