Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why artificially limit your code to C?

stackoverflow.com

Post reply on HN
Print view View original

21–30 of 40 posts

Re: Why artificially limit your code to C?

#21

Post by renata »

I work on aviation software. We have to use C because C++ generates too much code behind the scenes for you. If you don't create a constructor or destructor, there is an implicit one created. Templates are instantiated once for each type, but we still have to prove that (and test each instantiation). We'd also have to certify a new compiler, since our current one only supports C.

My point is basically that in domain-specific cases, C can be a good choice because of the lack of sugar and simplicity. I doubt this applies to most cases though.

Re: Why artificially limit your code to C?

#23

Post by kabdib »

You have a large body of code that is using C just fine, thanks, and moving it to C++ (while probably "trivial" for some meaning of trivial involving a few weeks/months/years of refactoring) would expose you to every C++ yahoo's whim.

"I wanna use maaaaaap! Why can't I use map? Map map mapmaapmap."

"Because this stuff runs in an interrupt handler, and is shared with thread-world code through a very carefully designed API involving a couple layers of synchronization. Many Bothans died to make this work well, and fast."

"No map?"

"No map. Go read about NUMA."

"What about streams?"

[buries head in hands]

tl;dr; It's an idiot shield. Kids, get off the lawn :-)

Re: Why artificially limit your code to C?

#24

Post by cageface »

ExpiredLink wrote: post #18
comex wrote: post #14

The fact that C++ is almost a superset of C is commonly used as an argument for C++, and the accepted answer in the post is a common response - C++ is not quite a superset of C, you have to cast malloc, you lose out on C99 features, etc. But I think it misses the point: if you could really get the advantages of C++ by using its features in a few necessary places in your C code, I think it would be worth it to make yo…

> where the caller of your method is a closing brace Although I agree with the sentiment of your comment destructors and RAII in general are arguably the best C++ features. If I were forced to use C++ again I would restrict my code to a lightweight subset of C++, especially I would not use the C++ Standard library (STL, iostreams, string) and of course not use BOOST (or any template heavy library) and C++0x. But I wo…

The big problem with RAII and destructors is that you have no way of returning an error. You're not supposed to throw an exception and you have no way to return an error code so you can't really do much in a destructor if you want to write 100% correct code. Manually managing error codes is tedious but it's also more explicit and flexible.

Re: Why artificially limit your code to C?

#25

Post by fauigerzigerk »

The question is pretty weird in the first place. If I like a particular language, why would I automatically like some arbitrary superset of that language?

But there are many practical reasons as well. One that hasn't been discussed much is exceptions. In order to use C++ libraries in C code you'd have to "RAIIfy" your entire codebase. That means wrapping all dynamic memory allocations in their own objects and replacing malloc with new. What's left of C after doing that?

Switching off exceptions on the compiler level isn't a viable solution either because it leads to undefined behavior.

Re: Why artificially limit your code to C?

#26

Post by cageface »

georgemcbay wrote: post #11
TheNewAndy wrote: post #3

No one there mentions symbol scrambling, and how it makes C++ libraries unportable across multiple compilers for the same platform.

Actually this is mentioned by "Rhythmic Fistman", but the post only got 6 points. From a purely practical standpoint, the lack of an ABI is the #1 reason I don't bother with C++ anymore because chances are pretty good that I'll want to interface the lower-level code with something like Python or Go, both of which integrate with C code much more easily than C++.

This is exactly the problem with C++ today. C++ "wants to be on top". Unlike C, it makes for a very uncooperative lower layer for other languages to build on. Unlike C, it's difficult to build up component libraries in C++ that can be easily used by the rest of your code. C++ makes more sense if you're writing your entire application in C++ but that's just way too much hassle for most applications.

Re: Why artificially limit your code to C?

#27

Post by cageface »

wladimir wrote: post #20
ExpiredLink wrote: post #18

Earlier quoted context omitted.

> where the caller of your method is a closing brace Although I agree with the sentiment of your comment destructors and RAII in general are arguably the best C++ features. If I were forced to use C++ again I would restrict my code to a lightweight subset of C++, especially I would not use the C++ Standard library (STL, iostreams, string) and of course not use BOOST (or any template heavy library) and C++0x. But I wo…

What would you use for string handling, then? Please don't tell me you prefer strcpy/strcat and zero-terminated strings?

You could use bstring:

http://bstring.sourceforge.net/

Re: Why artificially limit your code to C?

#28

Post by cageface »

pjmlp wrote: post #7
TheNewAndy wrote: post #3

No one there mentions symbol scrambling, and how it makes C++ libraries unportable across multiple compilers for the same platform.

Everyone loves to bash the lack of a C++ ABI. Now please name another language with native implementations with a standard ABI across different compilers. C implementations have a standard ABI, because they usually are the operating system ABI.

It's also much easier to specify a C abi. You don't have to worry about name mangling, exception propagation, inheritance relationships, templates etc.

Re: Why artificially limit your code to C?

#29

Post by cygx »

wladimir wrote: post #20
ExpiredLink wrote: post #18

Earlier quoted context omitted.

> where the caller of your method is a closing brace Although I agree with the sentiment of your comment destructors and RAII in general are arguably the best C++ features. If I were forced to use C++ again I would restrict my code to a lightweight subset of C++, especially I would not use the C++ Standard library (STL, iostreams, string) and of course not use BOOST (or any template heavy library) and C++0x. But I wo…

What would you use for string handling, then? Please don't tell me you prefer strcpy/strcat and zero-terminated strings?

Depending on the use case, libc, Windows API or ICU.

Personally, I'd like to see a simple C string library using modified UTF-8 (to be compatible with ASCIIZ) which is grapheme aware.

I'm tempted to take a shot at writing one myself, but haven't gotten around to it yet. If anyone is interested, see http://unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries for the algorithm and http://www.unicode.org/Public/UNIDATA/auxiliary/GraphemeBrea... for the property data...

Re: Why artificially limit your code to C?

#30

Post by batista »

TheNewAndy wrote: post #10
pjmlp wrote: post #7

Earlier quoted context omitted.

Everyone loves to bash the lack of a C++ ABI. Now please name another language with native implementations with a standard ABI across different compilers. C implementations have a standard ABI, because they usually are the operating system ABI.

I'm not sure what you mean here by "name another language". Do you mean other than C? I don't understand what that would demonstrate.

That it's not that common?
Post reply on HN