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

Why I don't spend time with Modern C++ anymore

linkedin.com

Post reply on HN
Print view View original

241–250 of 264 posts

Re: Why I don't spend time with Modern C++ anymore

#241

Post by bogomipz »

PeCaN wrote: post #146
namelezz wrote: post #142

Earlier quoted context omitted.

> In my experience, the opposite of what the author claims is true: modern C++ leads to code that's easier to understand, performs better and is easier to maintain. Can you comment on the memory safety of modern C++? I am wondering if I should learn Rust or modern C++.

std::unique_ptr, move constructors, etc and you're pretty safe, but it's still not in the same league as Rust. In my opinion you should probably learn Rust unless you want to get a job writing C++ (e.g. game development).

Is the general feeling that Rust is largely going to be the future for programming using a statically typed language?

Re: Why I don't spend time with Modern C++ anymore

#242

Post by bogomipz »

hendzen wrote: post #59
justsaysmthng wrote: post #49

HFT is a pretty limited and extreme application case. From what I understand - everything is not enough for HFT - network cards, kernel drivers, cables, etc. You have milliseconds (edit: nanoseconds !) to receive, process and push your orders before someone else does it and gets the prize. It's an arms race between technologists for the purpose of making a small number of people rich. I doubt that these requirements…

Not milliseconds. Nanoseconds. Competitive tick-to-trade times are on the order of 1000ns or less.

How do you tune the machine for that type of latency? User space drivers? Could you elaborate? Not having to go beyond L1 cache doesn't mean much if it takes a few milliseconds to get that trade out of the network card and on to the wire right?

Re: Why I don't spend time with Modern C++ anymore

#243

Post by NotRustAgain »

coldtea wrote: post #43
messel wrote: post #24

Ok. Try a different language :)? A single language needed to solve all problems is a fallacy. I don't see FPGA programming ousting c++, but expect higher level languages with strong parallel semantics to gain "market share". You can always call a dedicated process written in optimized c for the hottest components. Compose the rest in go, elixir, or any high level language (lisp). Architectures will naturally gravitat…

> A single language needed to solve all problems is a fallacy. Has that been proven and do we have pointers to any peer reviewed papers on that? Because else its just an old's wives tale. I don't see any logical impossibilities for one language to solve all problems (meaning, to work well for at least 4 domains: OS and drivers a la C, apps/games a la C++, network programming a la Go, Java etc, and scripting a la Pyth…

>> A single language needed to solve all problems is a fallacy.

> Has that been proven and do we have pointers to any peer reviewed papers on that?

I agree with you and can't stand it when people say things like: "All languages have their strengths and weeknesses" or "you just need to choose the right tool for the job".

I can't see any reason a clean and simple language can't have high level constructs when you want them and low level performance when you need it. It's just that no one has done it well enough yet.

Re: Why I don't spend time with Modern C++ anymore

#244

Post by NotRustAgain »

kibwen wrote: post #189
coldtea wrote: post #43

Earlier quoted context omitted.

> A single language needed to solve all problems is a fallacy. Has that been proven and do we have pointers to any peer reviewed papers on that? Because else its just an old's wives tale. I don't see any logical impossibilities for one language to solve all problems (meaning, to work well for at least 4 domains: OS and drivers a la C, apps/games a la C++, network programming a la Go, Java etc, and scripting a la Pyth…

> I don't see any logical impossibilities for one > language to solve all problems There are no logical impossibilities in constructing a vehicle that can serve as a passenger vehicle, dump truck, submarine, and airplane, but tensions in design will very likely result in a compromise that is more complicated, more expensive, and less capable than a dedicated solution. Not only that, but your vehicle will be just as i…

> a passenger vehicle, dump truck, submarine, and airplane

The problem with using metaphors to make your argument is we generally have to argue about whether the metaphor is even appropriate enough that the conclusions apply to the original topic... It's simpler just to argue the topic.

Within a huge class of problems, I don't need to get a new computer to solve each new thing that comes up. That's a very general tool. Why do I need different programming languages?

> All-in-one compromise solutions only excel [...]

Who asked for a compromise? I could make a short list of all the features I want in a language, and while there isn't one single languages that currently has all those features, I doubt you could make a proof that creating such a language is impossible or would involve some horrible trade off. Your list might be different than mine, but that's not the point.

Re: Why I don't spend time with Modern C++ anymore

#245

Post by NotRustAgain »

jerf wrote: post #74
coldtea wrote: post #43

Earlier quoted context omitted.

> A single language needed to solve all problems is a fallacy. Has that been proven and do we have pointers to any peer reviewed papers on that? Because else its just an old's wives tale. I don't see any logical impossibilities for one language to solve all problems (meaning, to work well for at least 4 domains: OS and drivers a la C, apps/games a la C++, network programming a la Go, Java etc, and scripting a la Pyth…

Languages can incorporate as many features as they like, but where two features conflict, they have to privilege one over the other. Nothing stops a language from having both statically- and dynamically-typed elements, but the library it ships with is going to privilege one over the other, and it's going to drag the rest of the code in the language in that direction. Nothing stops a language from having both immutabl…

> but the library it ships with is going to privilege one over the other

This really just seems to me a matter of no one having done it right yet...

Following your example (which I like), I can have both mutable and immutable types in my language. Your point is that the library will favor one or the other, but I think you admit both libraries are possible. Why can't I have twice the library?

Yeah, it might be more work to have a library twice as big, (and again, no one seems to have done it yet) but it's not more work than having two languages with two libraries.

All that to say, you're summarizing what's been done, but you haven't proven that something better couldn't be done.

Re: Why I don't spend time with Modern C++ anymore

#246

Post by unscaled »

pjc50 wrote: post #105
pjmlp wrote: post #93

Earlier quoted context omitted.

Well, we also have to thank C for the set back in optimizing compilers. Fran Allen. In Coders at Work (pp. 501-502): --- Begin Quote --- -Seibel-: When do you think was the last time that you programmed? -Allen-: Oh, it was quite a while ago. I kind of stopped when C came out. That was a big blow. We were making so much good progress on optimizations and transformations. We were getting rid of just one nice problem a…

That's some serious sour grapes by Allen. Her assertion that Fortran and COBOL are higher level than C is .. difficult to support given the reliance of both languages on GOTO. The assertion that compilers weren't taught any more is just silly.

Higher level does not necessarily mean more modern language features and paradigm - it only means language's computation model is farther removed from the actual hardware.

Allen was specifically discussing auto-optimizations (what we nowadays would just call 'compiler optimizations') and essentially argued that low level languages, in the quest of allowing fine-grained manual optimization, prevent many types of advanced auto-optimizations.

Specifically speaking, it is well known that FORTRAN still often beats C in numerical calculations just by the virtue of not supporting pointer aliasing (especially pointers pointing to arbitrary positions in the middle of an array which is being looped over).

Re: Why I don't spend time with Modern C++ anymore

#247

Post by AnthonyMouse »

pcwalton wrote: post #229
AnthonyMouse wrote: post #219

Earlier quoted context omitted.

It isn't limited to exception safety. The problem previously had been that there was no clear answer to the question, when should "delete" (and "~foo()") be called for a pointer? If you do it before some other code expected you to then you have UAF. If you do it in more than one place then you may have double free (and two calls to ~foo()). Now the answer is that unique_ptr will do it when the pointer itself goes out…

> Now the answer is that unique_ptr will do it when the pointer itself goes out of scope. And my claim is that this doesn't effectively reduce UAF. It doesn't eliminate dangling references, etc.

It seems like you're making the perfect the enemy of the good.

Look at my example above. The problem isn't just exception safety, the first class is five kinds of catastrophe waiting to happen.

If the user calls reinit() then init() may delete the pointer (because it was written expecting to be called during construction). So now the object exists but the pointer is invalid and any further use of the object will be UAF. Even if the caller understands the exception to mean that the object should not be used anymore, the ~fail() destructor is going to call the ~foo() destructor again and double free anyway.

On top of that, the default copy and move constructors and assignment operators for a naked pointer just copy the pointer, which produces UAF as soon as the first copy to be destroyed frees the pointer the others still hold.

None of that happens with the unique_ptr version. No explicit call to delete is required so we lose that opportunity to accidentally call it before the surrounding object ceases to exist. The default move constructor actually works and the default copy and assignment operators are deleted, so attempting to copy without an explicit deep copy implementation becomes a compile error instead of runtime UAF. And it's less code too.

It can't actually stop you from having dangling references because if it did then it wouldn't be able to compile existing code anymore. But how is it not an improvement over the status quo?

Re: Why I don't spend time with Modern C++ anymore

#248

Post by hellofunk »

aspiringuser wrote: post #224
leni536 wrote: post #46

Earlier quoted context omitted.

>There's tricks You mean PIMPL?

PIMPL pattern is great for reducing compilation time and creating stable user-facing APIs but it has a runtime cost. The "implementation" part is usually heap allocated and calling its methods have extra overhead of crossing the pointer to implementation barrier.

With the use of link-time optimization, most of the overhead of using pimpl idiom is removed. Both the outter wrapper functions as well as the implementation functions can be inlined, making the function calls effectively like a normal class implemented inside a header.

Re: Why I don't spend time with Modern C++ anymore

#250

Post by aspiringuser »

hellofunk wrote: post #248
aspiringuser wrote: post #224

Earlier quoted context omitted.

PIMPL pattern is great for reducing compilation time and creating stable user-facing APIs but it has a runtime cost. The "implementation" part is usually heap allocated and calling its methods have extra overhead of crossing the pointer to implementation barrier.

With the use of link-time optimization, most of the overhead of using pimpl idiom is removed. Both the outter wrapper functions as well as the implementation functions can be inlined, making the function calls effectively like a normal class implemented inside a header.

The heap allocation for the implementation won't be removed by LTO.
Post reply on HN