Why I don't spend time with Modern C++ anymore • Hacker News Board

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

#181

Post by Ygg2 » Wed, May 18, 2016, 5:19 PM UTC

xg15 wrote: post #62

Ygg2 wrote: post #48

Earlier quoted context omitted.

I had to write C++ yesterday and hated every second of it, from the clunky header files, to the errors that make no sense, to the can't make a cyclic dependency between classes i.e. class A { B: b} class B { a: A} Long story short - I was to create a wrapper around a Poco::Runnable, so you can use the wrapper as a Poco::Runnable (don't ask why, it's TEH LAW) but without extending it.

C++noob here, but: Given that the members in your example are no pointers but actual substructures within your data structure, wouldn't that result in an infinite data structure? Therefore it sewms quite logical to me it's not allowed. Disallowing cyclical dependencies via pointer would make no sense though.

It's more of a simplification. Although, I did try references and they didn't compile either. In fact, if I remember correctly the error was "forward declaration forbidden".

After spending about 10-12 years away from C++, I was pretty much on novice level. I remember some things, but most details and day to day specifics are gone. It did serve as a fresh reminder why I hate C++. Or more precisely, why I hate C++ compilers.

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

#182

Post by dragontamer » Wed, May 18, 2016, 5:21 PM UTC

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

> 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 (use a unique_ptr after it has been sink'd to another function).

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

#183

Post by lomnakkus » Wed, May 18, 2016, 5:21 PM UTC

gpderetta wrote: post #172

vmarsy wrote: post #151

Earlier quoted context omitted.

> I'm pretty sure they whish they could [view their datacenters as a single flat cache-coherent memory space]. Many HPC clusters do present a single memory image across thousands of machines. No not really, at some point when you're dealing with PetaBytes of RAM and millions of cores, the Law of Physics kicks in, your RAM is spreading across a large physical area no matter how clever you are. If you want a flat memor…

"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 best), so our models must account for latency. (At some point -- it's not obvious that we've reached the end of how compact a computer can be, but there is a limit where you just end up with a tiny black hole instead of computer.)

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

#184

Post by thinkpad20 » Wed, May 18, 2016, 5:23 PM UTC

> After 1970 with the introduction of Martin-Löf's Intuitionistic Type Theory, an inbreed of abstract math and computer science, a period of intense research on new type languages as Agda and Epigram started. This ended up forming the basic support layer for functional programming paradigms. All these theories are taught at college level and hailed as "the next new thing", with vast resources dedicated to them.

This seems pretty dubious. Dependently typed languages and other projects embracing advanced type theory are still the realm of niche enthusiasts. While some of the more academic colleges might teach them in one or two courses, the vast majority of education a CS college student receives will be taught in traditional imperative languages. If "vast resources" have been devoted to Agda and Epigram, then I'm not sure what kind of language should be used to describe the resources devoted to C, C++, Java, etc. Also as the author mentions, Intuitionistic Type Theory has been around since the 70's, in fact the same year that C was introduced. Certainly it hasn't been taking over the CS world by storm since its inception, as he seems to claim.

Beyond that, the author's argument seems to be a bit incoherent. He critiques the readability of Modern C++, but C++ is notoriously hard to understand, including or especially prior to the development of C++11. It's never going to be an easy language to read except to seasoned developers. If anything, modern C++11 seems to provide abstractions that increase readability and safety. He critiques the performance of modern C++, but then he ends up recommending that people ditch C++ entirely and learn VHDL/verilog instead. Not even vanilla C++ is fast enough for him, then why criticize modern C++ on the grounds of performance?

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

#185

Post by Ygg2 » Wed, May 18, 2016, 5:27 PM UTC

ygra wrote: post #54

Ygg2 wrote: post #48

Earlier quoted context omitted.

I had to write C++ yesterday and hated every second of it, from the clunky header files, to the errors that make no sense, to the can't make a cyclic dependency between classes i.e. class A { B: b} class B { a: A} Long story short - I was to create a wrapper around a Poco::Runnable, so you can use the wrapper as a Poco::Runnable (don't ask why, it's TEH LAW) but without extending it.

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.

Rust, also notes where and how you created an infinite loop.

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

#186

Post by pjc50 » Wed, May 18, 2016, 5:39 PM UTC

nickpsecurity wrote: post #171

jedbrown wrote: post #166

Earlier quoted context omitted.

Most everything here is subjective, inaccurate, or outdated by C99, save Fortran's multi-dimensional array handling which is legitimately superior to C despite partial reconciliation by VLAs.

Well, darn, there goes that. I'll have to re-examine it with C99 reference to assess it's accuracy.

I don't think it's quite that bad, but "for numeric programming" is a very important caveat here. As is "define higher-level".

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

#187

Post by cubano » Wed, May 18, 2016, 5:40 PM UTC

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.

Arbitrage has been around since the very beginnings of modern banking and provides a very important function to allow markets to accurately adjust to proper price signals.

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

#188

Post by Retric » Wed, May 18, 2016, 5:41 PM UTC

kbenson wrote: post #177

nickpsecurity wrote: post #173

Earlier quoted context omitted.

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.

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 fractions of a second.

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

#189

Post by kibwen » Wed, May 18, 2016, 5:45 PM UTC

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…

  > 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 inadequate as every other once the landscape changes and someone now needs a space shuttle.

All-in-one compromise solutions only excel when a market is both small (so that niche solutions that serve only a percentage of the market don't pass the absolute mindshare threshold for viability) and uncompetitive (so that there's no competitive advantage to ditching generality in favor of efficiency in a specific space). As long as the software market keeps growing and remains competitive, specialization and fragmentation will only increase (in the long run, anyway; we'll still be subject to the same bust-and-boom cycles, so it will still be possible for fragmentation to decrease in the short-term).

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

#190

Post by [deleted] » Wed, May 18, 2016, 5:46 PM UTC

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

[deleted]