Live data from Hacker News

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

linkedin.com

191–200 of 264 posts

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

#191

I know why I don't like C++ anymore, it's just no fun.Its slow to compile, the errors are like 6 lines long full of template and class hierarchy that makes it hard to understand what exactly happened, and then of course there's the common coding shortcut of declaring everything auto. (What type is this list? I don't know, it's auto all the way down.) Then there's the whole thing about making constructors, but leaving…

shrugs I still like to code in C++. Beats having to use JS ;)

Well that's faint praise indeed. ;)

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

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

Totally depends on what you want to use your programming skills for. In case you are just writing programs for yourself, or even starting a company writing the software from scratch with a handful of people you might as well learn Rust. If you want to get hired with many jobs to choose from, need to interface with/use lots of third party code or generally need to maintain legacy software C++ is a sure bet.

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

#194
post #188

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…

Hmm, in which case I guess it would be more accurate to say that HFT's provide some limited ability to control liquidity, whether that's increasing it or decreasing it.

Assuming decreased liquidity is bad (I don't know if there's situations where it's seen as beneficial to the market), the question is how to we disincentivize the use of the ability to decrease liquidity that HFTs have, or do we just accept it as a consequence of their participation, and accept that it happens from regular brokers as well?

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

#195

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

> I never quite understood why unique_ptr and move semantics... It's not those types, in particular, it's because C++11 allows you move your ownership model into the type system. And then, and this might sound familiar, writing code cognizant and explicit in its ownership semantics leads to safer, cleaner code.

True, but if you use smart pointers for that purpose, you cannot at the same time use references to protect against null pointers.

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

#196

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

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

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

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

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

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

#199

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

> I never quite understood why unique_ptr and move semantics... It's not those types, in particular, it's because C++11 allows you move your ownership model into the type system. And then, and this might sound familiar, writing code cognizant and explicit in its ownership semantics leads to safer, cleaner code.

> It's not those types, in particular, it's because C++11 allows you move your ownership model into the type system.

But it doesn't ensure that you use it correctly. Most use-after-free isn't the result of not understanding the ownership semantics; it's the result of understanding it but forgetting to handle some edge case or another.

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

#200
post #52

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…

Consultants wanna consult.

Exactly...If the building blocks is simplified enough, they lose their jobs.
Post reply on HN