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

201–210 of 264 posts

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

#201

Post by pcwalton »

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(); } };

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

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

#202

Post by gnaritas »

jandrese wrote: post #162
superuser2 wrote: post #156

Earlier quoted context omitted.

Insider trading is a term with a specific meaning, and that is not it.

This argument always feels like "It's not a Pyramid Scheme! It's a Triangle Opportunity!" People use the term not because it is an exact fit, but because it is the closest match we have and the intention is largely the same. HFT being a lot about using computers to gain tiny information advantages (racing the speed of light between exchanges for example) to make perfectly safe arbitrages millions of times a day and e…

> HFT being a lot about using computers to gain tiny information advantages (racing the speed of light between exchanges for example) to make perfectly safe arbitrages millions of times a day and effectively skim off of the top of the market.

That's entirely wrong. There's nothing safe about it, and they aren't skimming, they're trading exactly like every other trader is, making a guess and risking cash to see if they're right.

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

#203

Post by gnaritas »

nickpsecurity wrote: post #164
jandrese wrote: post #162

Earlier quoted context omitted.

This argument always feels like "It's not a Pyramid Scheme! It's a Triangle Opportunity!" People use the term not because it is an exact fit, but because it is the closest match we have and the intention is largely the same. HFT being a lot about using computers to gain tiny information advantages (racing the speed of light between exchanges for example) to make perfectly safe arbitrages millions of times a day and e…

Exactly my intent. Well-worded. I'm not sure quite how to describe it how average person would understand. So, insider trading is one option to approximate it. Pyramid Scheme seems like another one in the rip-off aspect but doesn't fix the specifics as well. The traits to categorize are it's rigged, parasitic on others, requires enormous investment, and requires physical proximity that's fairly exclusive.

And all of those descriptions are wrong. They are not trading on inside information, it is not in any way a pyramid scheme or a rip-off, nor is it rigged or parasitic. If you think HFT is bad, you don't understand what it is. HFT improves market prices providing buyers and sellers with better prices than they had before HFT by narrowing the spread you have to pay to find liquidity. HFT is good and benefits retail traders.

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

#204

Post by gnaritas »

sklogic wrote: post #165
superuser2 wrote: post #156

Earlier quoted context omitted.

Insider trading is a term with a specific meaning, and that is not it.

Getting an information ahead of the rest of the crowd sort of fits under this specific meaning.

No it doesn't, insider trading means using non public information; not getting information faster which is and has always been a thing long before HFT ever existed. Information takes time to impact the market and always has and there's always been and always will be traders fighting traders to know that information first.

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

#205

Post by gnaritas »

nickpsecurity wrote: post #173
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.

It's algorithms guessing about something in nanoseconds with little context. Feels like that would reduce accurate pricing. Not a finance guy, though, so my intuition could be wrong.

> Feels like that would reduce accurate pricing.

Nope, exactly the opposite, it creates better pricing. HFT is a bidding war to see who can create the best prices and still make enough profit to survive, this reduces trading costs for everyone else by reducing the spread.

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

#206

Post by dragontamer »

pcwalton wrote: post #196
dragontamer wrote: post #182

Earlier quoted context omitted.

> effectively have to decide when to free No. You just pass around the unique_ptr. Don't actually pass a reference to the object. When a function is done using the unique_ptr, it gets returned to its parent object. You'll never have a use-after-free if you use unique_ptr correctly. As others have noted: make_unique() and pass it around with movement semantics. The worst that can happen is that you dereference NULL (u…

> You'll never have a use-after-free if you use unique_ptr correctly. As others have noted: make_unique() and pass it around with movement semantics. This is far too limiting to handle anywhere near every real world use case. For example, you can't really call any non-&& methods on the referent following the discipline you propose, because "this" is a raw pointer!

Yeah, so use shared_ptr and weak_ptr in those cases. Shared_ptr is basically equivalent to C# and Python garbage collection (loops never get collected). So that should be "good enough" for the generic case.

unique_ptr is supposed to be used in a very limited fashion as I described. Its more efficient than shared_ptr, but much much more limited.

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

#207

Post by halayli »

This article is coming from a frustrated developer and lacks any scientific evidence. The frustration (understandably) is coming from the overwhelming complex new features and patterns that barely a compiler can understand.

C++11 onward revamped the language to make up for the lack of progress in the past 10 years. The majority of C++ developers that aren't keeping up with the new features because they are busy with their daily jobs feel that they are falling behind and the language they thought they new has changed underneath them.

C++03 already had a steep learning curve, but with C++11+ that learning curve is orders of magnitude more.

On the upside, you can use C++11 without understanding most of the details and it will do the right thing most of the them. And I think that's the bet that the language is making.

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

#208

Post by pcwalton »

dragontamer wrote: post #206
pcwalton wrote: post #196

Earlier quoted context omitted.

> You'll never have a use-after-free if you use unique_ptr correctly. As others have noted: make_unique() and pass it around with movement semantics. This is far too limiting to handle anywhere near every real world use case. For example, you can't really call any non-&& methods on the referent following the discipline you propose, because "this" is a raw pointer!

Yeah, so use shared_ptr and weak_ptr in those cases. Shared_ptr is basically equivalent to C# and Python garbage collection (loops never get collected). So that should be "good enough" for the generic case. unique_ptr is supposed to be used in a very limited fashion as I described. Its more efficient than shared_ptr, but much much more limited.

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…)

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

#209

Post by gpderetta »

lomnakkus wrote: post #183
gpderetta wrote: post #172

Earlier quoted context omitted.

"If you want a flat memory space you have to guarantee an access to any memory address in less than X cycles otherwise you have a NUMA architecture[1]" There is nothing wrong with NUMA (well, ccNUMA, but today that's a given). Even a simple modern two socket server is a NUMA machine. Anyways, as I've commented elsewhere, I'm not arguing that shared memory is practical today on a large HPC cluser.

> Anyways, as I've commented elsewhere, I'm not arguing that shared memory is practical today on a large HPC cluser. I think the point that was being made was that it'll never be practical purely for physical reasons. Any physical separation means that light takes a certain amount of time to travel and no known law of physics will let you circumvent that... A distance of a foot will always incur a latency of ~1ns (at…

I don't get it, our models have been accounting for latency for the last 30 years at least. We routinely use three level of caches and higly out of order memory accesses for trying to make latency manageable.

Now it is possible that our best coherency protocols simply aren't effective at high latencies, but that doesn't mean we can't come up with something workable in the future. Is there any no-go theorem in the field?

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

#210

Post by namelezz »

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(); } };

I think what pcwalton might be talking about is this:

std::unique_ptr owner(new Person("name"));

auto stolen = std::move(owner);

std::cout name Rust compiler will detect the usage of moved ownership and would not compile. C++ compiler will happily compile but result unhelpful run-time error.

Post reply on HN