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

211–220 of 264 posts

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

#211

Post by restalis »

cm3 wrote: post #114
netheril96 wrote: post #110

Earlier quoted context omitted.

How do you know that it is c++11 switch that dramatically increased your compile time, instead of the header file and the headers it includes? Two conditions are changed, and you feel confident that one of them is responsible for the outcome. Why?

Because it's a C++11 header that doesn't exist in C++98. And I cannot compile that version without switching to C++11 mode. Edit: there appears to be some confusion here. I don't include the C++11 header myself. I include a public API header of another project which now happens to include a C++11 header in their public include file. Unless I want to stay on the old version of that API and accept the risks, I don't ha…

The right answer should have been "because that was the bench-marked time result for the same code-base compiled in both modes" (before including the new header).

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

#212

Post by jupp0r »

namelezz wrote: post #142
jupp0r wrote: post #57

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. As an example, replacing boost::bind with lambdas allowed the compiler to inline functor calls and avoided virtual function calls in a large code base I've been working with, improving performance. Move semantics also boosted performance. Designing APIs wit…

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

Learning Rust actually helped me understand what's considered good C++ memory management design nowadays.

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

#213

Post by gnaritas »

Retric wrote: post #188
kbenson wrote: post #177

Earlier quoted context omitted.

To make money, they have to be accurately pricing. If the spread on something was $0.50, meaning that there are people on record as willing to buy at $0.50 lower than others are on record as willing to sell, the real price is somewhere within that range. Presumably, the real value of the stock is somewhere in the middle, but we don't know, because there's not any transactions happening right now, and the real value o…

One of the most useful HFT tools is to reduce liquidity. Doing this over an hour would cost ridiculous amounts of money, but cornering a specific exchange over 0.01 seconds is cheap and potentially profitable. Remember, if a HFT extracts money that means the actual seller and actual buyer's price never meets which means the market is not doing accurate price discovery instead providing two prices separated by fractio…

What? None of that made any sense. The only way they can reduce liquidity is to stop trading, or buy it all up, neither of which is bad.

> Remember, if a HFT extracts money that means the actual seller and actual buyer's price never meets which means the market is not doing accurate price discovery instead providing two prices separated by fractions of a second.

Just no, that is not at all correct. HFT increases price accuracy, it doesn't reduce it.

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

#214

Post by jandrese »

kbenson wrote: post #170
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…

> 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 their books are all 0.

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

#215

Post by sheepleherd »

superuser2 wrote: post #156
nickpsecurity wrote: post #131

Earlier quoted context omitted.

I think I see what commenter meant. You have to physically be on the inside in the sense you need a direct, short connection to the network that cost ridiculous money along with HW and SW that costs ridiculous money. A prestigious position most stock traders couldn't compete with if they wanted to. Plus, you get to preempt all of them from this position without them even knowing it.

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

Insider trading is a term with a specific meaning, and that is not it; true, but nor is the specific meaning of insider trading what most people think it is.

"Trading on inside information" is a term for what many people attempt to do that is illegal.

"Insider trading", on the other hand, is when insiders trade, which is totally legal, it's just regulated in certain circumstances when the size of the the trade is large or the person's role is at the executive level, an upcoming trade needs to be announced (made public) in advance as if itself it is information.

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

#216

Post by Retric »

gnaritas wrote: post #213
Retric wrote: post #188

Earlier quoted context omitted.

One of the most useful HFT tools is to reduce liquidity. Doing this over an hour would cost ridiculous amounts of money, but cornering a specific exchange over 0.01 seconds is cheap and potentially profitable. Remember, if a HFT extracts money that means the actual seller and actual buyer's price never meets which means the market is not doing accurate price discovery instead providing two prices separated by fractio…

What? None of that made any sense. The only way they can reduce liquidity is to stop trading, or buy it all up, neither of which is bad. > Remember, if a HFT extracts money that means the actual seller and actual buyer's price never meets which means the market is not doing accurate price discovery instead providing two prices separated by fractions of a second. Just no, that is not at all correct. HFT increases pric…

Liquidity means the price is stable not that trades will go through.* Stable prices prevent HFT traders from making money.

Price accuracy is somewhat debatable. Many HFT traders may toss lot's of trades around at a price, but that does not mean you can buy or sell large numbers of shares at that price as they can easily just be trading relatively small number of shares back and forth.

*Dramatic price swings are often tacked onto this. But, that's also relative to number of shares traded. If selling 1,000 shares at ~20.00 each involves any price shift it's hard to call that stable.

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

#217

Post by stagger87 »

pcwalton wrote: post #157
PeCaN wrote: post #146

Earlier quoted context omitted.

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

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

Rust dev baiting in a C++ thread...

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

#218

Post by dragontamer »

pcwalton wrote: post #208
dragontamer wrote: post #206

Earlier quoted context omitted.

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

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.

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

#219

Post by AnthonyMouse »

pcwalton wrote: post #201
AnthonyMouse wrote: post #197

Earlier quoted context omitted.

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?

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

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

#220

Post by netheril96 »

Ygg2 wrote: post #185
ygra wrote: post #54

Earlier quoted context omitted.

You can only do that when using pointers or references: class B; class A { B* b; } class B { A* a; } because the compiler can (obviously) not tell how large the instances of the other class are when you have a field of that type. Remember that the class layout has to be fixed at compile time and both instance sizes depend on one another. That's not solvable. C# does the same, actually: struct A { B b; } struct B { A…

This is also what I attempted, and as I remember it didn't work either, though to be honest I was really worn out fighting the obscure compiler errors by that point, I might have missed a sigil somewhere. I spent good solid 30min trying to understand why defining and not defining my constructor was causing issues, to realize that the constructor error was actually a previous error, somewhere above the constructor. Ru…

Your compile error is likely because you use references instead of pointers. Reference as a class member is really hard to get right because it can be initialized only once, and cannot be copied or moved.
Post reply on HN