FMH

[pphaneuf]

Was going so nice this morning, but now I'm all stuffy, and I've just "discovered" that charming lack of a type system in C. I was changing types around in parameters, trying to find out some information about the code I was looking at, but silly me, anything can convert to and from void*. Awesome.

Comments

[swestrup]

Well, function pointers don't. Or at least, they aren't supposed to.

[pphaneuf.livejournal.com]

Well, good for them, at least that's that. But I'm dealing with pointers to structs and such...

[swestrup]

Ah well, bad code can be written in any language.

[pphaneuf.livejournal.com]

I think it's easier than it should be here, though. This is basically a silent cast by the compiler, not a matter of me screwing up. Well, then, when I do provide the screw-up, the compiler won't tell me about it, anyway, which is the part i don't like.

While I don't nearly think that C++ is the end-all, be-all of computer languages, I definitely disagree with sps: if you're going to write something and your only two choices are C and C++, there needs to be a ridiculously good reason to pick C. At the extreme, writing C-style code, merely using the C++ compiler so that you get better diagnostics.

[swestrup]

It all depends on your programming style, I suppose. I hate C++ for its outstandingly bad diagnostics. (Four paragraphs of nonsense because you've passed the wrong type to a template and all sorts of strange autoconversions have messed everything up.)

I also prefer C for anything embedded, where code and data space are tight and you need fine control of what is and is not compiled into PROM. (there are proposed C++ mechanisms to help in this regard, but they don't exist yet.)

On the other hand, C++ does have a number of features I wish C had.

[pphaneuf.livejournal.com]

Usually, the more junk you put into it, the more comes out. If you skip on templates and don't overload, then you never get the big diagnostics (they scale with the number of things they have to differentiate between, usually).

By "what is compiled into PROM", you mean what goes in the text segment? C++ offers just as good controls on that as C, I find, but it is true that initialization of global variables can be less efficient in C++ (usually when a constructor gets involved, but there's a few other ticklish details)...

At the worst case, I'd say that a very tight embedded context might be one where, yes, in the end, you might have to skip on C++.

But I'm on big-iron cluster hardware here, for goodness' sakes!

[swestrup]

Well, avoiding templates and/or overloading in C++ is like avoiding void * in C: Its hard to do when working on legacy code.

As for the PROM comment, very often in embedded systems the RAM is at a premium, so you need to have as much of your static data constructed at compile time and loaded into a read-only segment that can be in PROM.

Its very hard to make static structured data in C++ that doesn't need to be initialized at runtime.

[dcoombs.livejournal.com]

anything can convert to and from void*.

Oh come now, that is C's most "convenient" "feature". Love it!

[pphaneuf.livejournal.com]

You're a sick man.

[thebabynancy.livejournal.com]

ROFLMAO! Twisted, too.

[azrhey.livejournal.com]

GEEK!

I think that's my cue to post nekkid women...

[swestrup]

Go for it!

I aim to please...

[azrhey.livejournal.com]

Re: I aim to please...

[pphaneuf.livejournal.com]

Danke!

[graydon.livejournal.com]

Its type system is too underpowered to be useful without an escape hatch. Try to write any generic data structure in C with no void*. Very sad.

It would be nice if the escape hatch returned an opaque address with a runtime type descriptor, and the only way "back inside" the type system involved a runtime check; but it'd also be nice if the type system just had type variables in the first place. This was an intentionally minimalist language, relative to its contemporaries.

[pphaneuf.livejournal.com]

I'm just asking for non-silent casting. Is that too much? Well, no, I know it's not, because C++ doesn't wildly yanks thingies* into void* and back.

Not asking for runtime type system, reflection or anything fancy like that. Foo* doesn't cast automatically into Bar*, and void is no different than Bar or Foo. That's not asking for the moon, isn't it? Couldn't they figure that out back then? No, they had to have a magic type and screw me over more than thirty years later!

[(Anonymous)]

Non-silent casting is one of the very few backwards compatibility breaks that C++ made from C. C can't ever learn that lesson because they can't just have old C programs suddenly stop working one day when you upgrade the compiler (gcc developers notwithstanding). So try to forgive them their mistake, it was the 1970's and 80's, after all, and they're not allowed to fix it.

However, you can take advantage of the fact that C++ is so similar to C. Simply use the C++ compiler to compile your C programs. I've used this technique several times in past lives to track down bugs that standard C didn't want to tell me about. Beware, though, that you might find yourself discovering a lot of *other* bugs you didn't really want to fix. :)

You can use any subset of C++ you want. This technique is just using a very, very, very strict subset.

--apenwarr

[pphaneuf.livejournal.com]

I gave that a try, but let's say the usage of "#ifdef __cplusplus" was humorous.

*stab*