LWN.net Logo

GCC 4.6.0 released

GCC 4.6.0 released

Posted Mar 28, 2011 0:32 UTC (Mon) by HelloWorld (guest, #56129)
In reply to: GCC 4.6.0 released by elanthis
Parent article: GCC 4.6.0 released

> Removing the C preprocessor isn't necessary because its existence does not mandate its use in new code
But it makes it much harder to write proper tools, such as IDEs. There is a reason why C and C++ IDEs still suck compared to what is available for, say, Java.
> There is a ridiculously large body of C code and C libraries out there for which the D facility for generating "bindings" does not work well, such as libraries that make heavy use of macro tricks which are common given C's weaknesses.
Oh, so first you say that the preprocessor is not a problem because you don't have to use it and then you say that it is in fact, because it breaks the tools that generate C bindings for D. Make up your mind!


(Log in to post comments)

GCC 4.6.0 released

Posted Mar 28, 2011 2:18 UTC (Mon) by tetromino (subscriber, #33846) [Link]

> proper tools, such as IDEs

<rant>
Who needs IDEs? One can be perfectly productive in any text editor as long as it has a few necessary features like indentation support, syntax highlighting, and regex-based search-and-replace.

Back in the day, real programmers used to write software in MS Notepad! With 8-letter filenames and Hungarian variables! And no version control system! They walked to work three hours in meter-deep snow, all year long, uphill both ways! And they *liked* it!
</rant>

GCC 4.6.0 released

Posted Apr 1, 2011 3:29 UTC (Fri) by elanthis (guest, #6227) [Link]

You aren't making any sense.

(1) I said that removing the C preprocessor is a stupid idea.
(2) I said that breaking C compatibility is a stupid idea.

These statements support each other quite well.

My point about "not having to use it" simply means that if you want to write code that doesn't use the preprocessor, you can already do that in C/C++ today. The fact that it exists is not forcing you to use it in new code. However, removing it forces you to not be able to use old code.

Hence, removing it has a measurable cost and no measurable gain.

GCC 4.6.0 released

Posted Apr 1, 2011 3:49 UTC (Fri) by HelloWorld (guest, #56129) [Link]

> You aren't making any sense.
Look who's talking.

> My point about "not having to use it" simply means that if you want to write code that doesn't use the preprocessor, you can already do that in C/C++ today.
This is just a blatant lie. Every non-trivial program uses at least #include to include header files and #ifndef, #define and #endif for include guards, and as you rightly pointed out, due to the "limitations" (I'd rather just call it suckage, but that's just me) of the C language, it's often the only way to avoid tons of boilerplate code.

But anyway, if you want to stick with cpp, go for it. I don't particularly care.

GCC 4.6.0 released

Posted Apr 8, 2011 15:55 UTC (Fri) by etienne (subscriber, #25256) [Link]

> if you want to write code that doesn't use the preprocessor, you can already do that in C/C++ today.

I would really like to have *real* constant in C/C++, something like:

inline const struct {
unsigned user_interface : 1;
unsigned algorithm : 1;
unsigned input : 1;
unsigned output : 1;
} debug = {
.user_interface : 0,
.algorithm : 0,
.input : 1,
.output : 0
};

and write functions like:
void fct (void) {
if (debug.input) printf ("input is: ...");
}

So that the debug code is completely removed when debug is null,
without #ifdef, and variables only used when debug.input is set
do not need an #ifdef too to remove warnings "set but not used"...

GCC 4.6.0 released

Posted Apr 8, 2011 17:51 UTC (Fri) by dtlin (✭ supporter ✭, #36537) [Link]

Doesn't GCC already do that (at least under some optimization levels)?

GCC 4.6.0 released

Posted Apr 11, 2011 12:27 UTC (Mon) by etienne (subscriber, #25256) [Link]

GCC treat const variable as thing which cannot be modified by the code, i.e. more like read-only.
You can modify the const variable in assembler, or in another piece of code where that variable is not declared "const".
Long time ago I read that you could use "static const" in C++ to get the same behaviour but I then tried and the variable was still defined as a piece of memory - and that was not available to C.
What I would like is that no memory is ever reserved for "inline const struct {}" - so the tests are always either true or false at compilation time, address of that variable cannot be taken, etc...

GCC 4.6.0 released

Posted Apr 11, 2011 20:05 UTC (Mon) by jrn (subscriber, #64214) [Link]

const register? constexpr?

GCC 4.6.0 released

Posted Jul 18, 2011 10:03 UTC (Mon) by runciter (guest, #75370) [Link]

How about:

enum DebugFlags {
  DEBUG_INPUT = 0,
  DEBUG_SOMETHING_ELSE = 1,
};

It's constant, doesn't use any memory and doesn't use the preprocessor.

GCC 4.6.0 released

Posted Jul 18, 2011 13:12 UTC (Mon) by etienne (subscriber, #25256) [Link]

But it is not as "structured" as a C structure named "debug" which would contain not only boolean but where to send the ouput (stdout, stderr, serial, filename...) and sub-structures like what to debug in "INPUT".
Anyway GCC-4.6 does introduce the inlining of constants, if you want a read only variable modified in the ELF file or at assembly time before main() is called, you now need to use "volatile const" - I was too quick to do that initial comment...

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds