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

Is C++ Doomed?

tednesday.wordpress.com

Post reply on HN
Print view View original

161–168 of 168 posts

Re: Is C++ Doomed?

#161

Post by Jtsummers »

throwaway5486nv wrote: post #159
b20000 wrote: post #140

Earlier quoted context omitted.

C++ is a multi paradigm language, it is not “object oriented” necessarily. also, there is nothing wrong with C++. it’s C with additional language constructs and the STL. use as much or as little as you want of it. also, there is no such thing as leaking a pointer. you can leak a piece of memory. at the end of the day you need to understand operating systems and how memory management, CPUs and instruction sets work an…

What other paradigms are popular with C++? Never came across anything else other than object programming.

Generic, functional (with the introduction of lambdas and closures, in particular), procedural. Some of the features may use the class system under the hood, but with a very shallow hierarchy it's more akin to a trait/interface system if you drop the deep class hierarchy style that was more prevalent in the 90s.

Re: Is C++ Doomed?

#162

Post by throwaway5486nv »

Jtsummers wrote: post #161
throwaway5486nv wrote: post #159

Earlier quoted context omitted.

What other paradigms are popular with C++? Never came across anything else other than object programming.

Generic, functional (with the introduction of lambdas and closures, in particular), procedural. Some of the features may use the class system under the hood, but with a very shallow hierarchy it's more akin to a trait/interface system if you drop the deep class hierarchy style that was more prevalent in the 90s.

Are there any popular open source projects that has adopted non object oriented programming style?

Re: Is C++ Doomed?

#163

Post by Jtsummers »

throwaway5486nv wrote: post #162
Jtsummers wrote: post #161

Earlier quoted context omitted.

Generic, functional (with the introduction of lambdas and closures, in particular), procedural. Some of the features may use the class system under the hood, but with a very shallow hierarchy it's more akin to a trait/interface system if you drop the deep class hierarchy style that was more prevalent in the 90s.

Are there any popular open source projects that has adopted non object oriented programming style?

I'd just look at the C++ Standard Library which relies far more on the procedural, generic, and functional styles than OO. Using it, you often (IME) end up writing code more along the trait/interface style than the OO-hierarchy style that was popular in the 90s. But I have no idea about open source C++ projects, I don't follow them and mostly don't care. I've really only used C++ at work where 99% of the code seems to be procedural, not OO. The closest is that they have "classes" which are barely more than plain data objects ("smart" structs), if they have methods it's to enforce data invariants and almost nothing else.

Re: Is C++ Doomed?

#164

Post by colejohnson66 »

nine_k wrote: post #116
colejohnson66 wrote: post #110

Earlier quoted context omitted.

The Arduino and friends can run on C++. The Arduino “IDE” uses “C almost ++”, but C++ compilers for AVR and ARM boards do exist.

Certainly you can write C++ for MCUs; the question is, should you, and does the ecosystem encourage that. OTOH a bigger ARM core can very well be found on a small embedded computer, and it's capable enough to run something like a browser. At this scale, pure C becomes burdensome, and libraries (like a browser engine, or Qt) are in C++ anyway.

> and does the ecosystem encourage that.

In the case of Arduinos? Yes. As I said, the original Arduino IDE has partial C++ support. Classes are used by almost every library. The AVR series originally targeted are 8 bit MCUs, and they run fine despite the ATMega328p, for example, having only 32 KB of flash.

Re: Is C++ Doomed?

#165

Post by Animats »

b20000 wrote: post #140
Animats wrote: post #17

The basic problem with C++ is that it has has hiding without safety. C has neither, and most newer languages have both. Attempts to add safety to C++ via templates always seem to leak raw pointers, since many APIs never converted to C++. It's significant that there isn't a C++ Linux kernel API, where you use C++ strings for everything and get rid of the null-terminated stuff. You see this in the original poster's exa…

C++ is a multi paradigm language, it is not “object oriented” necessarily. also, there is nothing wrong with C++. it’s C with additional language constructs and the STL. use as much or as little as you want of it. also, there is no such thing as leaking a pointer. you can leak a piece of memory. at the end of the day you need to understand operating systems and how memory management, CPUs and instruction sets work an…

Leaking a pointer occurs when you take a raw C pointer from one of the safe templated C++ constructs. This happens far too often because there are so many C APIs around that are still used from C++.

Re: Is C++ Doomed?

#166

Post by brigade »

atq2119 wrote: post #129
brigade wrote: post #79

Earlier quoted context omitted.

Then you can't allocate the object in-place (e.g. on the stack), and also you have to ban copy assignment/construction. Probably a more common solution is like what STL's own fstream does - don't throw an exception on construction, and have a "not valid" state.

Sorry to say it, but your C++ knowledge seems outdated. What the gp comment explained is perfectly viable due to (Named) Return Value Optimization is for. Compilers have been doing that for a while and it's mandatory since C++17. Yes, C++ has started changing a lot about a decade ago, and despite what the naysayers claim, most of the changes (like this one) are for the better.

How exactly do you return a null object by value?

I know about RVO, but that's irrelevant here because a factory function returning an object by value does nothing to avoid needing to throw exceptions if construction fails.

Re: Is C++ Doomed?

#167

Post by ChrisMarshallNY »

Hmm… I’ve been hearing “C++ is dead!” For twenty years or more. Same with PHP, but not quite as long.

C++ is not a language to be used for the vast majority of programming tasks.

It’s basically an industrial tool; for doing industrial things.

There’s a reason that industrial tools aren’t available in your local hardware store.

There’s some things that it’s best suited for; namely, doing big, complicated algorithms, very quickly. It’s flexible enough to afford almost any programming paradigm. Otherwise, I don’t see much of a use case for it.

There’s plenty of other languages, better suited for things like Web service delivery, or GUI programming. I used to use it for GUI programming (Mac programming, using CodeWarrior). It was not the best tool, and I don’t miss it, at all.

These days, I’m not even sure that I’d recommend it as an appropriate language for operating system development.

I did run a C++ image processing pipeline (big, complicated algorithms) shop that used C++, for twenty-five years, and saw it used for what it’s made for.

Re: Is C++ Doomed?

#168

Post by ggreg84 »

jcelerier wrote: post #153
ggreg84 wrote: post #151

Earlier quoted context omitted.

> No they don't. An exception that isn't thrown costs nothing. Wait whaaat? When every expression can throw anything, the compiler and the user both loose the ability to reason about code locally. They change any function from returning one value of one type, to returning any value of any type. This: - has a performance cost: it breaks lots of compiler optimizations that require knowing where and what can functions r…

it's obvious that OP meant a performance cost - as generally when you program in C++ that's the n°1 metric. And for that one, exceptions as they are today are often faster than the equivalent error-code-based code: https://nibblestew.blogspot.com/2017/01/measuring-execution-... Of course if we can get even faster exceptions such as the throwing values model, by all means let's do it... i'm entirely fine with recompil…

> And for that one, exceptions as they are today are often faster than the equivalent error-code-based code: https://nibblestew.blogspot.com/2017/01/measuring-execution-...

The example on that blog post is not representative of how error codes are used.

On all programming languages, C included, but also Rust, functions return a completion value that's either success, or error (and when its error, it includes which error it is, and the error state, etc.).

    int foo();
    switch (foo())
       case 0: break; // success
       case 1: /* error case 1 */
       case 2: /* error case 2 */
       ...
Instead, the blog post has the function return some value in registers that is not an error, and passes the function an ErrorState* as an argument, that the function first sets via memory, and then the handler reads, also via memory.

That this is slow is not rocket science, which is why nobody does this.

I get why the author has to do it. If they were to do it right, error codes would perform significantly better than exceptions. Since returning the error or success is "free" (the function has to return anyways, and up to 2 registers are reserved by the ABI anyways).

Somebody mentions this in the comments, were as far as fixing it and sending a PR (https://github.com/jpakkane/excspeed/pull/1) but the author complains that this is not how GLib does error codes, so they don't care.

So yeah, if you do C error codes like GLib does, which is essentially a poor man's emulation of exceptions, then sure, exceptions are faster than doing error codes wrong.

Most people using C do it right, and so does Rust's Result (and all Rust programs).

Post reply on HN