OSDev.org

JohnnyTheDon wrote:#define is also nice when you need to define a lot of numerical constants.

That can be done using the const modifiers. Any sane compiler will recognize it's a constant value, and will not generate a memory access for the variable, it will simply inline the value.
But I agree doing it with preprocessor macros looks nicer.

The effect of the three is more or less identical. I prefer #2, because it's the only one that actually is straightforward and typesafe.

ru2aqare wrote:

JohnnyTheDon wrote:#define is also nice when you need to define a lot of numerical constants.

That can be done using the const modifiers. Any sane compiler will recognize it's a constant value, and will not generate a memory access for the variable, it will simply inline the value.
But I agree doing it with preprocessor macros looks nicer.

GCC isn't sane then. It exports the const variables, causing a bunch of multiple definitions. Also, when declaring global or stack arrays const variables cannot be used.

JohnnyTheDon wrote:

ru2aqare wrote:

JohnnyTheDon wrote:#define is also nice when you need to define a lot of numerical constants.

That can be done using the const modifiers. Any sane compiler will recognize it's a constant value, and will not generate a memory access for the variable, it will simply inline the value.
But I agree doing it with preprocessor macros looks nicer.

GCC isn't sane then. It exports the const variables, causing a bunch of multiple definitions.

That they are exported doesn't mean they are not inlined in the current module. Also, to avoid that you can always declare them as static const (possibly in the header).
There's also a way I'm sure GCC inlines your constant. Inter-module analysis is achieved in GCC by feeding everything into it at once, and running with -O3 -fwhole-program -combine. Once, I did it on a university work and the boy inlined everything into a HUGE main(). I doubt this mass-inlining approach is always an intelligent optimization, however.

Also, when declaring global or stack arrays const variables cannot be used.

Did not remember that. In fact, in C this doesn't work.
However, in a modern language, you don't have to fear this limitation. In Java, you can put non-constant initializers in attributes (including static ones, afaik), and I guess you can do this in D and in C# either.

Alas, IMHO C has a very important role as a relatively low-level language, specially in operating system development (as all of you know). I think it would be a fairly good idea to redesign the language, not to bloat it and to add every imaginable feature, but just to modernize it. Removing that old header-inclusion scheme and that type-unsafe preprocessor, and instead rely on the compiler to optimize away unneeded code and function calls would help a lot. Adding namespaces and a template facility would also be a good idea.
Redesigning setjump/longjump in order to make it easer to implement threading libraries and SEH libraries without assembly code would be a good idea, too.
Personally, I don't like very much the C syntax. But killing would be a nasty idea. People love it.

I don't think it would be easy, though. There are also a bunch on C dialects out there, and non of them has the goal of cleaning-up the original language, so I don't think there are many people inclined to this kind of redesign to the language.

JJ

JohnnyTheDon wrote:That isn't allways true. There are some things (like conditional compilation) that can't be done w/o the preprocessor, at least not in a sane way.

I forgot to comment this.
This point, once again, should be done by the compiler. See: You create your static const value and then you employ and if() around the code that will be the subject of the conditional compilation.
At compile time, the static const gets inlined by the optimizer, which then observes that the if is always true/false and optimizes away the extra code.

If you are worried about legibility, then syntactic sugar could be used. There could be, for example, a capitalized IF() or a IFDEF(), semantically equivalent to if(), but intended to be used, by convention, for conditional compilation.

This solution has also the advantage that if you wanted, e.g., to compile a kernel that would use SSE instructions on machines supporting SSE, but would not crash on machine without SSE support, you could just remove the const and set the variable on initialization.

JJ

I think it would be a fairly good idea to redesign the language, not to bloat it and to add every imaginable feature, but just to modernize it.

This is what D tried to do. It actually declares itself as a systems programming language, but kind of falls short. IMHO, anything with a GC is going to be unreliable for systems programming, at least in the kernel.

One feature I wish this forum had is to put any code above a certain size into it's own "frame" so that code dump posts aren't 6 miles long. It's really quite easy, just add "max-height: Xpx; overflow: auto" to the code tag's css/style. IIRC there were a few display problems getting it working on my site, though.

This already happens.

Under which themes? It would be nice if the default theme did this to, as that's the one I prefer.

JohnnyTheDon wrote:

I think it would be a fairly good idea to redesign the language, not to bloat it and to add every imaginable feature, but just to modernize it.

This is what D tried to do. It actually declares itself as a systems programming language, but kind of falls short. IMHO, anything with a GC is going to be unreliable for systems programming, at least in the kernel.

The problem with that approach is, if you add GC, then you are adding a core feature (and in this case, it's a fairly expensive one).
No. I think a C replacement must be based on the same simplistic principles as C. Traditional procedural programming, minimalistic standard library, data manipulation similar to the asm programmer's usual approach (e.g. strings being just arrays of characters), minimalistic abstractions imposed by the language, no GC, classical pointers, no exceptions, no additional runtime support required for the basic language constructs apart from the usual stub that calls main(), easily optimizable for speed, etc. Additional features could then be added as extensions, or as a PlusPlus variant of the language, but the base being simple, while still fixing some of the longstanding C flaws.

About what I called "templates" in the last post, I meant something like "parametric namespaces", where the namespace could be "imported" and accessed with different parameters. Those parameters could be either integers or pointers. This would help implementing e.g. linked lists, because the compiler would just have to reserve the needed space where the parameter type is unknown at compile time.

JJ

Firestryke31 wrote:Under which themes? It would be nice if the default theme did this to, as that's the one I prefer.

It works just fine for me under the default theme. Let's check again:
EDIT: yep, it looks just fine here...

Subsilver 2 doesn't. Relevant CSS:
Could be changed to: Edit: When I said "default" theme, I meant the one guests see, which is the one set when I registered.

It doesn't work on the MegaTokyo theme.. which, IMHO, should be the default.

There are times when the preprocessor is useful. I wrote an event system and I had a file called EVENTS.H which basically contained:
and each time I included EVENTS.H DEFEVENT(name, params) was defined to something different. (e.g. first time it would define fireMouseMove(int x, int y)), second time it would create an array of each object listening to that event, and third time it would create a virtual function called void onMouseMove(int x, int y)). A lot of other stuff was also preprocessed (register that the object listens for an event).

I'm sure there could have been a better way to do it, but it was designed to add/remove lots of events easily.

What about using the preprocessor to increase speed of the program, and ease on the developer?

I discovered the C preprocessor was capable of this nifty little thing earlier yesterday. With this, I get where the panic occured in my code, and the code(x) for the panic. Before I knew of this, I had to either type that huge long line, or just use codes, which didn't tell me exact information.

the preprocessor is very handy in the hands of those that know how to use it. But, it can be easily abused too.

edit:
Is there any way to do this in your precious D? I didn't see any replacement for such a macro in that C preprocessor vs. D link...