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

Convincing C programmers to switch to C++: A look at human behavior (2016)

blog.kareldonk.com

Post reply on HN
Print view View original

81–87 of 87 posts

Re: Convincing C programmers to switch to C++: A look at human behavior (2016)

#81

Post by raverbashing »

jernfrost wrote: post #67
raverbashing wrote: post #34

How to convince them: - Show them how classes makes things easier (automatic object management, some operator overloading, etc) - Show how the STL makes most things easier (arrays, maps, etc) How not to convince them: - Show uses of excessive/pathological inheritance - Use of templating beyond the basics - Insist they use C++ functions for every single thing - Insist they OOify every interface in their code - Creatin…

Why would that convince them of C++ and not any other modern language like D, Rust, Swift, Go or Nim? I really can't see what C++ has to offer anybody. It is a horribly complex language, which doesn't interface with anything except C.

I wouldn't, but C++ is an improvement over C in most situations and will fit situations where modern languages won't run

Re: Convincing C programmers to switch to C++: A look at human behavior (2016)

#82

Post by self_awareness »

deorder wrote: post #19

“If you’re arguing, you’re losing.”. That is a quick way to stop any discussion. The reason I am not using C++ is because C already does everything I need: - Easier to write code generators for : I use libclang to read in annotations that will generate new code according to where the annotations are being used. If I have to take care of every edge case and new features added to the latest C++ standard it would make t…

You're using C in a cool way, but:

1) By using libclang to parse your own annotations you're kind of using your own fork of C language, not the standard one. You can't really bring your annotation parsing engine to some company to work on an existing C project,

2) C++ also uses plain old data structures, using 'class' does not magically introduce any overhead in structures, unless you start using virtual functions, but nothing forces you to do it,

3) I think that by stripping name mangling you actually increase binary incompatibility, because without mangling you can't know what ABI was the function compiled against. Which compiler was it? What are the arguments? Is it MS ABI or UNIX ABI? Nobody knows for sure even if it seems to work correctly for some set of arguments. Disabling mangling sure is convinient at the beginning, but brings problems and incompatibilities at later stage.

4) Given that Windows or macOS kernel drivers are written in C++ (more or less), low level access is possible in C++ as well.

Re: Convincing C programmers to switch to C++: A look at human behavior (2016)

#83

Post by deorder »

self_awareness wrote: post #82
deorder wrote: post #19

“If you’re arguing, you’re losing.”. That is a quick way to stop any discussion. The reason I am not using C++ is because C already does everything I need: - Easier to write code generators for : I use libclang to read in annotations that will generate new code according to where the annotations are being used. If I have to take care of every edge case and new features added to the latest C++ standard it would make t…

You're using C in a cool way, but: 1) By using libclang to parse your own annotations you're kind of using your own fork of C language, not the standard one. You can't really bring your annotation parsing engine to some company to work on an existing C project, 2) C++ also uses plain old data structures, using 'class' does not magically introduce any overhead in structures, unless you start using virtual functions, b…

I am aware that all of this is possible in C++ as well and for many things C++ might be the better choice (more standardized compiler hints instead of using pragmas, generics and templates etc.).

What I meant is that C++ does not add anything for me personally.

POD-structures are all I need and the way I fetch/store the data may require the struct layout to be interleaved or non-interleaved (depending on the platform / architecture I am targeting for a specific build) requiring different code to be generated to access them.

I do not need to disable name mangling or add 'extern "C"' everywhere (I still do in case the code will be used from C++) when I just use plain C.

I like the many new features added to C++ like concepts, lambdas etc. but for these I prefer to use Nim (they just added complete concept support as well).

Re: Convincing C programmers to switch to C++: A look at human behavior (2016)

#84

Post by dllthomas »

sqeaky wrote: post #70
jernfrost wrote: post #65

Earlier quoted context omitted.

LOL, C++ developers complain about C developers being impervious to reason, yet can't admit one of the most blindly obvious problems with C++. Plenty of language manage to be more expressive than C++ while being far less complex. C++ is an uncritical grab bag of features. If you don't carefully design features to complement each other you can C++ style complexity. C simplicity is real. It makes it easy to write compi…

You are lumping me in with some strawman who insulted you, then you insult me calling me "impervious to reason". You are not interested in a real exchange of ideas. I will respond to your points in the spirit of open exchange anyway, but if you continue to be rude it will just shine a poor light on C programmers as a whole. Since I feel you ideas are lacking factually this might seem like an attack, it is not an atta…

> it will just shine a poor light on C programmers as a whole.

Hey now, most of us have nothing in particular to do with this guy!

Re: Convincing C programmers to switch to C++: A look at human behavior (2016)

#85

Post by dllthomas »

self_awareness wrote: post #53

Well, I've tried plain C in one project. The compiler didn't complain when I did some invalid casts, didn't complain when I forgot to return values from functions, provided some warnings against using some undefined functions, but compiled the units anyway (failing on linking stage), I had to write my own implementation of vector (probably buggy and slow), and probably I've forgot to free memory in some situations be…

> because types are so weak in C

You can get nominal typing in C by wrapping your primitives in single-element structs. Slight syntactic overhead, no runtime overhead. In my C code, I try to avoid passing primitives between functions. It worked out well on my last large C project.

Re: Convincing C programmers to switch to C++: A look at human behavior (2016)

#86

Post by jstewartmobile »

C and C++ have a lot of wiggle room when it comes to implementations. I prefer C (when possible) just because there's less surface-area for arbitrary behavior (which is already more than enough arbitraryness).

I'm writing this mostly as a plug for DJB's proposal for a "boring" C compiler: https://groups.google.com/forum/m/#!msg/boring-crypto/48qa1k...

Re: Convincing C programmers to switch to C++: A look at human behavior (2016)

#87

Post by jpfr »

jstewartmobile wrote: post #86

C and C++ have a lot of wiggle room when it comes to implementations. I prefer C (when possible) just because there's less surface-area for arbitrary behavior (which is already more than enough arbitraryness). I'm writing this mostly as a plug for DJB's proposal for a "boring" C compiler: https://groups.google.com/forum/m/#!msg/boring-crypto/48qa1k...

The kcc compiler is really good at being predicatable. A formal semantics of the language gives warnings whenever undefined behavior occurs.

https://github.com/kframework/c-semantics

Post reply on HN