This question already has answers here:
Why does everybody typedef over standard C types?
(4 answers)
Closed 3 years ago.
Please help me understand reason of defining C types in some projects.
In my current company I found that someone made definitions of types that are equivalent of those that are already defined in <stdint.h>.
Such approach makes harder to integrate 3party code into project, and makes programmer work, bit more frustrating.
But I can also see that some projects, like gnome do the same. There is a gchar, gsize, and gint32 for example.
Because I don't see ANY reason for such approach, I kindly ask for explanation.
What is the reason that <stdint.h> isn't sufficient.
This is not good practice. It only leads to less compatibility and portability. I don't see any reason that it should be done. stdint.h exists to avoid this.
<stdint.h> was standardized in C99. Perhaps the codebase predates <stdint.h>, or it needs to compile on platforms that don't have it. It was an extremely common thing to do in C89 and K&R C when there were no portable fixed size typedefs. Even modern projects may keep around these compatibility shims if they still aim to be compilable on decades-old platforms.
In my current company I found that someone made definitions of types that are equivalent of those that are already defined in <stdint.h>.
If your codebase targets C99 or later then there's no need.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Basically, I have a inline function in C:
struct array {
unsigned long size;
void* items;
};
typedef struct array* Array;
inline Array array_create(unsigned long initsize);
inline void array_free(Array this);
Am I free to use the this keyword in this kind of situation, or is it better to avoid it, and why (not)?
EDIT: This question originated from a bug in my code where I used inline void array_free(Array array); which changed the result of sizeof(array); and gave me the idea to use this instead of adapting to the (in my opinion ugly) sizeof(struct array);.
It's technically correct because C is not C++, so this is not a keyword in C.
Whether it's wise, now that's a different question. If there is any chance that this piece of code will ever be compiled as C++, then an identifier called this will break the code.
Using this in any fashion you want is totally valid C.
What you have to ask yourself, by the way these apply to any C++ reserved words like class, final etc, is :
Do I use a program that highlights this as a keyword conveing the wrong message ? e.g. Visual Studio highlights this even when you're in a .c file so some confusion may arise.
Do I plan to promote my code to C++ in the future ? In such a case you'll have some extra work to do that could be avoided.
Does my code interact with C++ ? This is not a problem per se but you have to bear in mind that your code will interact with C++ programmers as well. And you don't won't to confuse people that may not be aware of C in great detail (even though someone may say it's their duty do be aware of what they're doing when reading another language).
Since this is something that can be avoided I find using it immoral but not incorrect.
I'm not saying you have to study C++ prior to writing C, but once you know something, it's a good practice to make good use of it.
A subtle problem you may cause is to make your code 'uncallable' from C++ for example a
#define this some_definition
in a C header file that is later included from C++ may have weird effects to your code.
The reasons not to use this in standard C is that it makes your code:
Slightly less readable, due to the "well-known" usage of this in C++. Your code can look as if it's C++ and an uninformed reader can easily get confused.
Unportable to C++. If you (or someone else) ever want to take this code and use it in a C++ compilation, it will fail. That's a downside and an upside at the same time, since getting an error can be indicative that care must be taken, where's not getting one might let important issues slip.
It depends what your objective is.
If your C code program will always be built with a C compiler that is not a C++ compiler, then it makes no difference whether you use this as an identifier in your code. It is not a reserved identifier, so you are free to use it.
The potential problem with that premise is that a number of mainstream C compilers are actually C++ compilers, or they support some C++ features as extensions, so they may reject your code (or - less likely - do something with it that you don't expect). It is not possible to predict with absolute certainty that the vendor of your compiler(s) of choice will never (even if they give you a promise in writing) release a future version of their C compiler that will reject or do something unexpected with your code. The likelihood of this happening is relatively low, but non-zero.
In the end you need to decide what risk you are willing to take with maintaining your code in future.
Of course, if you are a C fanatic who wants your code to have an incompatibility with C++ (yes, such people do exist) then using a number of keywords or reserved identifiers that are specific to C++, as well as using such keywords or identifiers that are specific to (more recent versions of) C may be a worthwhile approach.
As it is already mentioned, you can use any non-reserved keyword as a variable name.
However, I suggest to use something like 'pThis', or '[struct name]This' or similar to express your intent of using a C struct together with functions that are taking as first argument a pointer to [struct name] instance, and are meant to be used in a similar manner as member functions of a C++ class.
This way your code may be more readable and your intent more understandable by someone who is using it.
In C you do not have the this keyword. Only in C++ and in a class, so your code is C and you use your this variable as a local method parameter, where you access the array struct.
Yes, you can. If the code happens to get compiled as C++, it is not your fault. However, in case that happens, other things won't be accepted; the fact that you likely assign to items without a cast, for instance, because C++ does not allow that unlike C.
This question already has answers here:
Why does the C preprocessor interpret the word "linux" as the constant "1"?
(5 answers)
Closed 8 years ago.
With in a source code I know you can use platform specific information such as
#ifdef __APPLE__
or
#ifdef __ANDROID__
I am working on a new platform and need to use such macros. Where does the definition occur? If it is done at the compiler, where can i look to find this information?
It is said that the NaCl MACRO for instance is defined at the compiler as follows:
/* The NACL compiler defines __native_client__ and __pnacl__
* Ref: http://www.chromium.org/nativeclient/pnacl/stability-of-the-pnacl-bitcode-abi
*/
EDIT:
I guess I'm Looking for predefined compiler macros like the ones mentioned in http://sourceforge.net/p/predef/wiki/Compilers/. But is there a way I can look into a given compiler to find these information to find additional information? The one I use is based on arm-gcc.
Some sources:
http://www.netbsd.org/docs/pkgsrc/fixes.html#fixes.build.cpp
http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/predefined-macros-platform.html
Boost has a library Predef that define a lot of macro of a lot of platform too.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question appears to be off-topic because it lacks sufficient information to diagnose the problem. Describe your problem in more detail or include a minimal example in the question itself.
Closed 9 years ago.
Improve this question
I used Microsoft Visual Studio to write a C code in C++ project and It's working fine there when I convert the file extension from my.cpp to my.c and tried to run in via TurboC++ 3.0 then it gives me number of errors like "Constant Expression Required" and "Declaration is not allowed here".
I tried to run my code online compiler but its not giving me these error there.
Can anyone help me with this ?
I hope it's due to C99 mode but not confirmed.
TurboC++ 3.0 Supports C99 or not ?
Note: I can't share my code directly here due to project research work , If anyone want to have a look at my code I can send you via private message , Sorty for that
The error: Declaration Not allowed here is due to the mixed type declaration of variables and the error: Constant Expression required is because of the variable length arrays.
Mixed type variables and variable length arrays are are allowed in C99 and latter. Neither MSVC nor Turbo C++ supports C99.
I tried to run my code online compiler but its not giving me these error there.
This is because almost all new (and online) C compilers support C99.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
How to code a compiler in C?
How would I start writing a compiler from scratch (no Flex or Bison or Lex or Yacc) in C? I have a language that I wrote an interpreter for, and it's kind of like Forth. Sort of. It takes in symbols and interprets them one at a time, using a stack.
How would I make a compiler?
That wasn't a particularly spammy bit; just to show people the syntax and simplicity.
http://github.com/tekknolagi/StackBased
Simple!
You tokenize the input.
You build a proper representation of it, generally this is an Abstract Syntax Tree, but that is not required.
You perform any tree transformations you may require (optional).
You generate the code by walking the tree.
You link any disparate portions together (optional)
Flex and Bison help with stage 1 and 2, everything else is up to you. If you're still stuck, I suggest going through "Programming Language Pragmatics" or The Dragon Book.