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

Modern C++ Won't Save Us

alexgaynor.net

Post reply on HN
Print view View original

221–230 of 395 posts

Re: Modern C++ Won't Save Us

#221

Post by fooker »

usrnm wrote: post #131
mempko wrote: post #118

Earlier quoted context omitted.

C++ is designed for people to make nice libraries. Unlike other languages there is nothing special about the standard library (no magic language hacks). All libraries are first class citizens by design.

Good luck implementing something like std::is_standard_layout without "magic language hacks". No, not all libraries are made equal and std is part of the language now, there is no way back

A look into the type_traits header reveals that is_standard_layout is implemented with standard C++.

Re: Modern C++ Won't Save Us

#222

Post by DoingIsLearning »

0xDEEPFAC wrote: post #180
DoingIsLearning wrote: post #166

Earlier quoted context omitted.

> by today's standards You make it sound like Ada stopped in the 80's. They don't release standards in rapid succession but 'Ada 2012' has pretty much all of the features that people were asking for in C++ since 2011. The only issue (on top of the obvious lack of coolness and hype around it) is that professional grade Ada compilers/toolchain are still quite a high cost for single developers or small companies. AdaCor…

Many of AdaCore's "community" versions are the full compiler and if they dont have builds available for your bareboard arch you can build it yourself or get one from gcc. The only difference is that use of the special "GNAT.X" packages outside the standard runtime are under a GPL restriction and you would be required to export those dependencies as a separate lib and do open dev on it. Otherwise you are free to sell…

TIL. I was under the impression they were a lot less permissive outside a commercial license.

Re: Modern C++ Won't Save Us

#223

Post by coldtea »

geezerjay wrote: post #146
colanderman wrote: post #95

Earlier quoted context omitted.

What parts specifically? By my estimation, the only non-deprecated part of the standard library that really reeks of pre-C++11 (what I believe most consider the advent of "modern") is iostream. Most of e.g. the containers have been kept up to date with new features of the language (e.g. move semantics, constexpr). The standard library certainly is lacking things which are commonly used (say, JSON parsing or database…

> The standard library certainly is lacking things which are commonly used (say, JSON parsing or database connection), I strongly disagree. It's quite obvious that the C++ standard library does not need to add support for "common things", because they already exist as third-party modules. In fact, this obsession to add all sorts of cruft to the C++ standard is the reason we're having this discussion. If there is no w…

>I strongly disagree. It's quite obvious that the C++ standard library does not need to add support for "common things", because they already exist as third-party modules.

It's not obvious to me at all.

In fact, if that was a valid argument, it would be for C++ not having a standard library at all, as everything (including vectors, strings, etc) also exists as "third-party modules".

Re: Modern C++ Won't Save Us

#224

Post by coldtea »

Maken wrote: post #210
adrianN wrote: post #199

Earlier quoted context omitted.

I believe that C++ needs a fat standard library because using third party libraries is a bit cumbersome in C++. Alternatively there could be a blessed build system that makes third party library integration as easy as Cargo or Go Modules.

I would say that CMake pretty much covers that. What it lacks is somehow a central registry, but I think C++ never intended to have one.

What C++ intended and what C++ should have intended are two different things.

Re: Modern C++ Won't Save Us

#225

Post by pjmlp »

fetbaffe wrote: post #209

Without any data to back this up, my guess is that there is no good reason to pick C++ for a new project except when the developer is already fluent in C++. Assume we have this abstract developer that has a good knowledge in programming theory but has no experience in programming languages. The developer starts a new project, but in what language? web: Don't see any reason for this. Exist lots of great alternatives.…

NVidia is designing their GPUs with C++ in mind as source language.

desktop-GUI: I guess you might be joking here with Electron, I rather use my GPU for something else other than blinking cursors. Even with Cocoa, UWP and WPF, the underlying UI shaders are written in C++.

Embedded: Yes, C does rule over C++, which is a reason why embedded is so open to security exploits due to wrong manipulation of string and arrays.

Parallellism: HPC, FinTech, GPGPU all domains where C++ rules for the time being.

3D game development: C++ is king here, even with Unity the core engine is written in C++. Yes many of us hope to see the day when Unity is 100% written in a mix of C# and HPC#, but even then, LLVM will be part of the stack.

Scientific: Someone needs to write those Fortran and C++ libs called by Python and Matlab.

System development: Google, Apple and Microsoft use C++ on their driver layers for their respective OSes.

IDE tooling: C++ is known for not having IDEs that match what Java/.NET are capable of. Languages that want to take C++'s place, are even worse than C++ in IDE tooling.

Re: Modern C++ Won't Save Us

#226

Post by 0815test »

the_trapper wrote: post #46
wwright wrote: post #23

Earlier quoted context omitted.

That’s very true. But all of those communities, ecosystems, standards, and use cases have an extreme learning curve and a very deep problem with security. :-)

Rust's learning curve isn't exactly a shallow one either. For the record I think Rust has a lot going for it, but it is not the C++ killer that many are touting it to be.

> Rust's learning curve isn't exactly a shallow one either.

I don't know how people can be so sure of this. We know essentially nothing about how to teach or learn Rust effectively, it's something that the community is just starting to look at. However, one thing we do know is that the detailed support that the Rust compiler provides to the novice programmer is quite simply unparalleled in other mainstream languages. It's basically the ultimate T.A.

Re: Modern C++ Won't Save Us

#227

Post by gmueckl »

adrianN wrote: post #201
gmueckl wrote: post #185

Earlier quoted context omitted.

That is why use tools like valgrind to verify that you got it right.

Together with a test-suite that covers the exponential number of paths through your code...

Changing programming language neither reduces the need for test coverage nor does it magically increase coverage.

Re: Modern C++ Won't Save Us

#228

Post by adrianN »

gmueckl wrote: post #227
adrianN wrote: post #201

Earlier quoted context omitted.

Together with a test-suite that covers the exponential number of paths through your code...

Changing programming language neither reduces the need for test coverage nor does it magically increase coverage.

A type system changes the need for test coverage because it eliminates whole classes of bugs statically that would need an infinite amount of tests to eliminate dynamically.

Re: Modern C++ Won't Save Us

#229

Post by gmueckl »

esrauch wrote: post #196
gmueckl wrote: post #185

Earlier quoted context omitted.

That is why use tools like valgrind to verify that you got it right.

When I worked on a mobile C++ project at Google, we went exceptionally out of our way to avoid memory issues. We ran under valgrind and multiple sanitizers (and continuously ran those with high coverage unit and integration tests). We ran fuzzers. We had strictly enforced style guides. We still shipped multiple use after frees and ub-tripping behavior. I also saw multiple issues in other major libraries that we were…

Writing memory safe programs in C++ is possible. Most coding styles and some problem domains don't lend themselves to it naturally, though. In my experience, restricted subsets used for embedded software vastly reduce the risk of introducing errors and make actual errors easier to spot and fix.

Re: Modern C++ Won't Save Us

#230

Post by gmueckl »

adrianN wrote: post #228
gmueckl wrote: post #227

Earlier quoted context omitted.

Changing programming language neither reduces the need for test coverage nor does it magically increase coverage.

A type system changes the need for test coverage because it eliminates whole classes of bugs statically that would need an infinite amount of tests to eliminate dynamically.

That leaves an infinite amount logic bugs to be tested for. Types cannot fix interface misuse at integration and system level. So no, this does not reduce the need for testing.
Post reply on HN