3 ms·

What's drowning people in C and even more in C++ is not the logic of the language, but the sheer number of tricky concepts and the pure accumulation of informat

by kyllo 13y ago

What's drowning people in C and even more in C++ is not the logic of the language, but the sheer number of tricky concepts and the pure accumulation of information (it is reflected on the size of the specs). I agree, and I'd add that C/C++ is a bit of a leaky abstraction layer over assembly. It aims to be portable, but true portability means that the C/C++ developer really shouldn't have to know/care what assembly instructions the compiler/linker is emitting, because all of that stuff depends on which chip architecture you're targeting. Basically, coding in C/C++ requires an intimate knowledge of how the compiler works, and sometimes even how the target chip works. C/C++ software projects of notable size oftentimes cannot be simply recompiled/linked to a different target architecture without changing things like compiler flags, the makefile, and even the application code itself. That makes it a non-portable, leaky abstraction, and dramatically increases the amount of knowledge that's required of a C/C++ developer.

pjmlp 13y ago
It is a matter of community culture. In the Pascal family of languages, developers tend to think first about having something working and then optimize if not fast enough. In the C and C++ communities, developers tend to micro-optimize every line of written code, even before knowing if it makes sense to do so.
bjackman 13y ago
I've been spending a lot of time recently looking into and thinking about alternatives to C. I'd love to see a language as close to assembly as C is, but with a cleaner disconnect with it. As an example of what I mean: Bitfields would be really handy when writing a device driver. A basic example of the difference they would make is "if (reg.field == VAL)" vs. either "if (reg & MASK == VAL)" or "if (GET_FIELD(reg) == MASK)". But you can't use them for that purpose because their layout is implementation defined. There would be a noteworthy performance benefit to pay for portable bitfields, but I think it would be worth it. Right now I have to write ugly code if I want any attempt at portability (always). I'd much rather have to write ugly code where I need speed (sometimes). I'd love to hear if anyone else has any ideas on this matter (BTW it seems like D solves many of the problems I've been thinking about, but it's memory managed).

by kyllo 13y ago

pjmlp 13y ago

It is a matter of community culture. In the Pascal family of languages, developers tend to think first about having something working and then optimize if not fast enough. In the C and C++ communities, developers tend to micro-optimize every line of written code, even before knowing if it makes sense to do so.

bjackman 13y ago

I've been spending a lot of time recently looking into and thinking about alternatives to C. I'd love to see a language as close to assembly as C is, but with a cleaner disconnect with it. As an example of what I mean: Bitfields would be really handy when writing a device driver. A basic example of the difference they would make is "if (reg.field == VAL)" vs. either "if (reg & MASK == VAL)" or "if (GET_FIELD(reg) == MASK)". But you can't use them for that purpose because their layout is implementation defined. There would be a noteworthy performance benefit to pay for portable bitfields, but I think it would be worth it. Right now I have to write ugly code if I want any attempt at portability (always). I'd much rather have to write ugly code where I need speed (sometimes). I'd love to hear if anyone else has any ideas on this matter (BTW it seems like D solves many of the problems I've been thinking about, but it's memory managed).