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

221–230 of 264 posts

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

#221

Post by aspiringuser »

20 year C++ programmer here. I work on multithreaded server code. Stopped using modern C++ features 5 years ago. I'd compare my use of C++ to be roughly equivalent to the use of C++ in the NodeJS project or the V8 project. I'm not a user of Boost.

I have to agree with the author of the article. It takes longer to train developers to write idiosyncratic modern C++ code and compilation times explodes. Compiler support for bleeding edge C++ features is spotty at best. Harder to reason about the correctness of modern C++ code.

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

#222

Post by gpderetta »

jandrese wrote: post #214
kbenson wrote: post #170

Earlier quoted context omitted.

> effectively skim off of the top of the market The problem with this point of view is that it implies they are just taking, and not providing. HFT provides a more accurate market price by providing liquidity at small price differences. Whether what they provide justifies their cost is another question though.

Isn't this exactly the opposite effect? You place a bid for what is currently showing on the market, and the HFT firms use their speed advantage go and buy up most of the stock at that price and relist it for a bit more. So the price is never what you actually think it is, it is what you see plus whatever the HFT firm decides to add. HFT firms can't provide liquidity--they don't hold positions! At the end of the day…

That's not how markets work. If an HFT firm saw your order resting, means that nobody wanted to trade with you at that price in the first place.

If you cross the market then there is nothing the HTF firm can do. When it becomes aware of your order it will be too late. Of course the order you want to trade with might have disappeared while your order is in flight, but that would not be casually related to you sending the order to the market.

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

#223

Post by kbenson »

jandrese wrote: post #214
kbenson wrote: post #170

Earlier quoted context omitted.

> effectively skim off of the top of the market The problem with this point of view is that it implies they are just taking, and not providing. HFT provides a more accurate market price by providing liquidity at small price differences. Whether what they provide justifies their cost is another question though.

Isn't this exactly the opposite effect? You place a bid for what is currently showing on the market, and the HFT firms use their speed advantage go and buy up most of the stock at that price and relist it for a bit more. So the price is never what you actually think it is, it is what you see plus whatever the HFT firm decides to add. HFT firms can't provide liquidity--they don't hold positions! At the end of the day…

This only works because the HFT firm is confident they can immediately sell at that higher price. That is, they have more, or quicker information than the market is aware of. This results in a more accurate price, because if the stock was prices at that originally the market would have shown it, and the HFT would have had nothing to do.

You can try to classify that as the HFT taking money the seller would have made if they had noticed and repriced quick enough, or taking money from the buyer if they noticed and bought at the original price, but I think both argument could easily be extrapolated to the rest of the stock market and regular users (this plays out quickly, on fairly public info, but it's the same process that goes into someone making a decision on what price to buy at and what to sell at, just sped up quite a bit).

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

#224

Post by aspiringuser »

leni536 wrote: post #46
adrianratnapala wrote: post #36

Earlier quoted context omitted.

"Big ball of mud" dependency structures are common because the most pragmatic quick-fix for so many compile errors it to just whack in a new #include. C++ is worse than most languages in this way, because private members are defined in public headers. This forces you add #includes to the headers. Thus the #include graph is much denser than the true dependencies in your program. There's tricks for getting around this,…

>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.

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

#225

Post by gpderetta »

fish2000 wrote: post #155
hellofunk wrote: post #3

This article is not very general. Much of what it tries to convince us is not going to matter for most developers, and has the cost of suggesting modern features are not good for any developers. For example: >It is not rare to see Modern C++ applications taking 10 minutes to compile. With traditional C++, this number is counted in low seconds for a simple change. This is simply a bogus statement with respect to what…

“A Variadic Template A Day Keeps The Job Security In Play”

You should see the code that variadic templates replace.

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

#226

Post by jandrese »

gpderetta wrote: post #222
jandrese wrote: post #214

Earlier quoted context omitted.

Isn't this exactly the opposite effect? You place a bid for what is currently showing on the market, and the HFT firms use their speed advantage go and buy up most of the stock at that price and relist it for a bit more. So the price is never what you actually think it is, it is what you see plus whatever the HFT firm decides to add. HFT firms can't provide liquidity--they don't hold positions! At the end of the day…

That's not how markets work. If an HFT firm saw your order resting, means that nobody wanted to trade with you at that price in the first place. If you cross the market then there is nothing the HTF firm can do. When it becomes aware of your order it will be too late. Of course the order you want to trade with might have disappeared while your order is in flight, but that would not be casually related to you sending…

You're forgetting that "the market" isn't one monolithic thing anymore, it's a number of independent exchanges. Your order goes out to all of them, and the HFT firm sees it on the nearest market then races (and beats!) your offer to all of the other markets. That's why they care about nanoseconds so much, they're racing the speed of light. That's why you get a tiny fraction of your bid filled and then everything else suddenly dries up and is relisted at a higher price (aka Arbitrage).

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

#227

Post by slavik81 »

AnthonyMouse wrote: post #197
pcwalton wrote: post #157

Earlier quoted context omitted.

I never quite understood why unique_ptr and move semantics are supposed to improve memory safety over new and delete. They reduce leaks, sure, since the compiler inserts free for you at a hopefully-useful place. But you still effectively have to decide when to free, and there is no protection against dangling iterators, references, or pointers. From a security point of view, use after free is far worse than leaking,…

class fail { foo * p; void init() { p->some_init(); if(p->some_error()) { delete p; throw some_exception(); } } public: fail() { p = new foo; init(); } ~fail() { delete p; } void reinit() { init(); } }; vs. class ok { unique_ptr p; void init() { p->some_init(); if(p->some_error()) { throw some_exception(); } } public: ok() { p = make_unique (); init(); } void reinit() { init(); } };

That fail class has major problems that are probably not obvious to those unfamiliar with C++.

It breaks the rule of three [1]. It cannot be safely copied, and you haven't disabled the copy-constructor or assignment operator, which makes it super-dangerous.

[1] https://en.wikipedia.org/wiki/Rule_of_three_%28C%2B%2B_progr...

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

#228

Post by pcwalton »

dragontamer wrote: post #218
pcwalton wrote: post #208

Earlier quoted context omitted.

Just to be clear, you're suggesting to use shared_ptr for every object you want to call methods that don't take "this" by move on? (Which is not enough by any means to ensure memory safety, of course…)

Obviously, full memory safety is not ensured if you ever move over to raw pointers. But if you're copying shared_ptrs around, the reference counting almost always ensures that the memory is valid. The idea is to rarely use references or raw-pointers unless you know you have to.

I'm not questioning how shared_ptr works. I'm claiming that using it as extensively as you describe is totally impractical, and no C++ code works this way.

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

#229

Post by pcwalton »

AnthonyMouse wrote: post #219
pcwalton wrote: post #201

Earlier quoted context omitted.

What fraction of security-sensitive UAF bugs in the real world have had to do with exception safety?

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.

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

#230

Post by monocasa »

pjc50 wrote: post #6

There are two separate rants here that aren't delineated well. 1) C++ is too complicated, and therefore hard to reason about and slow to compile. We're going to argue about this forever, but you'll have to agree that the spec is very large and warty compared to other languages, and that C++ tends to take far longer to compile (this was already a problem a decade ago, it's not specific to "modern" C++). 2) The future…

SystemC is actually C++. It's built on a bunch of #defines for classes and templates.
Post reply on HN