Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Orthodox C++ (2016)

bkaradzic.github.io

Post reply on HN
Print view View original

111–120 of 238 posts

Re: Orthodox C++ (2016)

#111

Post by jstimpfle »

wavemode wrote: post #89
nly wrote: post #75

Earlier quoted context omitted.

Your map example only concerns the standard library, not the language.

Its behavior is dictated by the language. The context of this thread is that someone stated that the C++ standard library sucks, and someone replied to them saying that it's just some implementations that suck, but that's separate from the language. The point I'm trying to make, in response, is that it is about the language. It's not just "some" implementations - there is no implementation of the C++ standard library…

In my reading, they didn't say it's due to bad implementations, though. They were trying to separate the standard into two parts, the one about the language syntax and semantics, and the one about the standard library. And I think this is a fair separation actually. But that doesn't make the core language any better ;-)

Re: Orthodox C++ (2016)

#112

Post by forrestthewoods »

PaulDavisThe1st wrote: post #86
flohofwoe wrote: post #66

Earlier quoted context omitted.

> for (auto const & ess : esses) { This is allowed by Orthodox C++ > dynamic_cast (base_ptr) This isn't because it requires RTTI, but dynamic_cast is also a typical code smell. Orthodox C++ isn't generally against new C++ features, it only advices to wait about 5 years (or at least one C++ version) for stabilization and to apply some common sense before adopting them. The notes about not using RTTI, exceptions and st…

> This is allowed by Orthodox C++ I can see no rationale for this whatsoever. It is nothing but syntactic sugar. > Branmir (of BGFX fame Appeals to authority don't really work for me. I've been writing a cross-platform DAW (0) for 25+ years, in C++, and what a game dev has to say about the language in their own work might be of passing interest but not much more. Being aware of the pitfalls of particular features of…

Your level of vitriol and anger at someone expressing an opinion is really weird.

Literally everyone who uses C++ decides which features to use/embrace and which to avoid. Someone sharing their particular preference is pretty normal and fine.

> Appeals to authority don't really work for me. I've been writing a cross-platform DAW (0) for 25+ years, in C++

I love how you reject appeal to authority and then try to establish yourself as an authority. That’s cute.

Re: Orthodox C++ (2016)

#113

Post by fasterik »

rfgplk wrote: post #8
PaulDavisThe1st wrote: post #2

You can take for (auto const & ess : esses) { ... } from my cold dead hands. Also, you can fight me if you want to take dynamic_cast (base_ptr) and force me to implement my own typing system every time I need to upcast. Basically, stick with C and leave C++ programmers alone. I haven't seen a less useful article about C++ in a long time, and as an HN reader, that's really saying something.

One thing I've noticed about a lot of these "strict C" developers is that quite often they actually refuse to learn C++. One of the most common complaints of C developers regarding C++ is "it does things behind the scenes/performs magic", often with regards to operator overloading. When they refuse to actually look at the implementation (y'know you can check if an operator has been overloaded) AND they refuse to ackn…

I don't think "refusing to learn C++" is the right way to frame it. I want to use the language features that are actually useful to me, without being forced into a specific programming style. I can't speak for every "orthodox C++" programmer, but for me that means using exclusively plain-old-data structs, non-member functions, and "dumb" pointers. I have no issue with learning to use a C++ feature when it's directly useful to a problem I'm trying to solve.

As one example, I recently found templated lambdas useful in making animations.

https://www.youtube.com/watch?v=cw-h0dePYZM

Re: Orthodox C++ (2016)

#114

Post by lelanthran »

delta_p_delta_x wrote: post #98
uecker wrote: post #94

Earlier quoted context omitted.

GCC was implemented in C and there are plenty of other C compilers written in C. GCC has been converted to C++ at some point, but large parts are still essentially C and I do not think the change to C++ was actually helpful (but others may disagree). In any case, the idea that one needs C++ to have C compilers is certainly simply wrong.

Clang/LLVM with its more permissive licence sees _much_ wider use and is written purely in C++. PlayStation, automotive, platforms and runtimes like Chromium/V8, Android, etc. are all built with Clang.

Clang usage is a fraction of GCC usage.

Regards, an embedded dev.

Re: Orthodox C++ (2016)

#115

Post by nuc1e0n »

rfgplk wrote: post #8
PaulDavisThe1st wrote: post #2

You can take for (auto const & ess : esses) { ... } from my cold dead hands. Also, you can fight me if you want to take dynamic_cast (base_ptr) and force me to implement my own typing system every time I need to upcast. Basically, stick with C and leave C++ programmers alone. I haven't seen a less useful article about C++ in a long time, and as an HN reader, that's really saying something.

One thing I've noticed about a lot of these "strict C" developers is that quite often they actually refuse to learn C++. One of the most common complaints of C developers regarding C++ is "it does things behind the scenes/performs magic", often with regards to operator overloading. When they refuse to actually look at the implementation (y'know you can check if an operator has been overloaded) AND they refuse to ackn…

c memory allocation functions can be implemented in 1000 lines or so. I've done it myself. Maybe more are needed to handle strange operating systems or architectures, as glib does.

Re: Orthodox C++ (2016)

#116

Post by lelanthran »

rfgplk wrote: post #8
PaulDavisThe1st wrote: post #2

You can take for (auto const & ess : esses) { ... } from my cold dead hands. Also, you can fight me if you want to take dynamic_cast (base_ptr) and force me to implement my own typing system every time I need to upcast. Basically, stick with C and leave C++ programmers alone. I haven't seen a less useful article about C++ in a long time, and as an HN reader, that's really saying something.

One thing I've noticed about a lot of these "strict C" developers is that quite often they actually refuse to learn C++. One of the most common complaints of C developers regarding C++ is "it does things behind the scenes/performs magic", often with regards to operator overloading. When they refuse to actually look at the implementation (y'know you can check if an operator has been overloaded) AND they refuse to ackn…

All the foot guns in C are still in C++, and C++ adds a significant multiple more.

Re: Orthodox C++ (2016)

#117

Post by miroljub »

delta_p_delta_x wrote: post #93
jstimpfle wrote: post #85

Earlier quoted context omitted.

They're not useable for anything serious, i.e. high throughput, low frequency, massively concurrent work. In other words, most of the things for which you shouldn't better have chosen a different language in the first place. They're also unusable by the way because of ergonomic and software architecture factors, such as bad modularity, terrible compile times, unreadable error messages, unreadable symbol names... Yes…

> anything serious, i.e. high throughput, low frequency, massively concurrent work Why is only 'high throughput, low frequency, massively concurrent work' considered 'serious'?

Because if you don't need any of these, any slop implementation will do.

Re: Orthodox C++ (2016)

#118

Post by WalterBright »

lelele wrote: post #25
rfgplk wrote: post #8

Earlier quoted context omitted.

One thing I've noticed about a lot of these "strict C" developers is that quite often they actually refuse to learn C++. One of the most common complaints of C developers regarding C++ is "it does things behind the scenes/performs magic", often with regards to operator overloading. When they refuse to actually look at the implementation (y'know you can check if an operator has been overloaded) AND they refuse to ackn…

> y'know you can check if an operator has been overloaded And there lies the problem with C++: to be sure, you have to check. C++ code can't be taken at face value -- the most innocuous-looking code could be a ticking bomb.

My favorite was the regex engine that was implemented using C++ operator overloading. The author was very proud of it, but you could not tell what code was regex code and what code was math code.

I went to some lengths with D to discourage such abusive operating overloading practice.

Re: Orthodox C++ (2016)

#119

Post by Pannoniae »

delta_p_delta_x wrote: post #93
jstimpfle wrote: post #85

Earlier quoted context omitted.

They're not useable for anything serious, i.e. high throughput, low frequency, massively concurrent work. In other words, most of the things for which you shouldn't better have chosen a different language in the first place. They're also unusable by the way because of ergonomic and software architecture factors, such as bad modularity, terrible compile times, unreadable error messages, unreadable symbol names... Yes…

> anything serious, i.e. high throughput, low frequency, massively concurrent work Why is only 'high throughput, low frequency, massively concurrent work' considered 'serious'?

They're just clearly inferior in pretty much any situation.

The map stuff the other posters summed up well but even std::vector is dogshit with pretty much all implementations having inlined grow code in push_back, a not too great API and missed optimisations e.g. no trivial relocation when growing the vector / moving it and no useful APIs such as "grow but don't initialise"...

Re: Orthodox C++ (2016)

#120

Post by jstimpfle »

Pannoniae wrote: post #119
delta_p_delta_x wrote: post #93

Earlier quoted context omitted.

> anything serious, i.e. high throughput, low frequency, massively concurrent work Why is only 'high throughput, low frequency, massively concurrent work' considered 'serious'?

They're just clearly inferior in pretty much any situation. The map stuff the other posters summed up well but even std::vector is dogshit with pretty much all implementations having inlined grow code in push_back, a not too great API and missed optimisations e.g. no trivial relocation when growing the vector / moving it and no useful APIs such as "grow but don't initialise"...

To be fair grow-but-don't-initialize is a pretty fundamental part of the API, the reserve() method.

But already the basic premise that you should push back without thinking is wrong. You will suffer reallocations and invalisations when you least expected them, and frankly you have to architect around that fact which is a terrible restriction. You can work around by pre reserving but at that point it's just a basic fixed heap allocated array but worse because the type gives you a weird look all the time, "I'll realloc as soon as you don't pay attention, harhar"!

Post reply on HN