Lately I've settled on eclipse CDT as my primary IDE for C++ development. It has it's own built-in incremental C++ compiler which doesn't always exactly agree with GCC.
I came across this snippet while brushing off some old code:
GCC compiles this just fine. However, the eclipse compiler signals a "syntax error" on the const array initializer (marked with a comment). Looking at this code, I don't know what I was thinking. Why is this way of initializing structs even compiling at all in GCC? Is this a non-standard extension of the language?
Eclipse does not have it's own compiler, it uses GCC/mingw.
But I've never seen that syntax for initialising arrays of objects before, is it a gcc thing?
It's probably a non-standard extension like you said. The standard way to do the same in C99 looks like this:
struct Blah { int a, b, c; }; const struct Blah blah = { .a = 10, .b = 20, .c = 30, };
I don't think that works in C++ though.
If Neil is correct about Eclipse using GCC, you may just need to enable GCC extensions in your IDE and it will compile again.
Eclipse does not have it's own compiler, it uses GCC/mingw.
That is not correct. Eclipse CDT does have its own internal compiler, which is used for indexing, code completion and compilation checking while you type.
It uses GCC/MinGW for the final build.
I didn't know that.
I just gave up on CTD after I realised it wanted to force the Java folder/file hierarchy and project management system on me and it simply didn't fit with C++ so I moved to NetBeans.
Obsolete gcc extension: http://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html ("Another syntax which has the same meaning...")
Why create extensions, just stick with the fecking rules, they're there for a reason.
The C language doesn't accept single-line comments // (until C99) or embedded assembler asm {} (never). Good compilers implemented useful features before waiting for all vendors to agree on them.
Why create extensions, just stick with the fecking rules, they're there for a reason.
Because why not?
Nothing wrong with giving you a few more useful options. It's up to you if you want to use them or stick to the standard.
aye, but // is a de-facto standard and fairly harmless, modifying the way things are created/initialised/tested is not. That's my view anyway.
Someone felt the need for something, compiler authors implement it as an extension and see if it works. If enough people (or the right people) think the feature is worthwhile then it gets codified into a standard, using the lessons learnt from the extension.
I just gave up on CTD after I realised it wanted to force the Java folder/file hierarchy and project management system on me and it simply didn't fit with C++ so I moved to NetBeans.
When I first started using eclipse, I really had to get used to the idea of multiple projects in a workspace. But now I love the fact that I can browse and search all my code across multiple projects.
Also, I figured out later that it's not required to have your code live under ~/eclipse/workspace or whatever, you can always override the defaults for project locations.
I don't know what other issues could arise from the Java project structure. Maybe you don't like separating header and source files? But I have always done that, so that doesn't bug me.
I think it was I wanted to include the source code from other projects in the build but keep them in a different folder. CTD either wanted me to simply link to the library files or have the code as a completely new eclipse project, neither of which is what I wanted to do.
Mabye this is something new, but you can definitely do that. I do that in my projects too, I have a "shared" folder that is shared between a lot of projects.
Simply go to Project properties -> C/C++ general -> Paths and Symbols -> Source Location, and click "Link Folder". You can link to any folder on your system.