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

C++11 FAQ

stroustrup.com

Post reply on HN
Print view View original

71–80 of 121 posts

Re: C++11 FAQ

#71

Post by ytugiuyghvk »

weerd wrote: post #57
ytugiuyghvk wrote: post #42

Earlier quoted context omitted.

If you want to template on an r-value reference, the easiest way is probably to use a forwarding reference and disable the template if the template parameter deduces to a reference template ::value>> auto f(T&& x);

Is this C++14? Can you please explain the "class = ..." template parameter?

class = X is just an anonymous template type parameter with default value X, just like

    auto foo(int = 0);
declares a function with a int parameter with default value 0. In this case, it's just a conventional place to stick an expression in the declaration to trigger SFINAE. If you don't need SFINAE, you can also just place the condition in a static_assert in the definition

    template 
    auto foo(T&&) {
        static_assert(!is_reference::value, "call me with an r-value");
        ...
    }

Re: C++11 FAQ

#72

Post by gpderetta »

steveklabnik wrote: post #67
gpderetta wrote: post #52

Earlier quoted context omitted.

> ass-backwards closures that's very surprising. I would say that C++ lambda expressions have been an incredible success and probably the best thing to come out of C++11. For example, rust started with boxed closures, because that's what all the 'proper' languages do. They were forced to switch to distinctly-typed, unboxed closures with similar capture modifiers to be competitive with C++ [1].

Your link got eaten, but we don't have capture modifiers anymore. Captures are inferred, and you can override this with a keyword to take all captures by value instead. This still lets you get the same effect as C++, but we find that it's generally less verbose. It depends though!

> you can override this with a keyword to take all captures by value instead

that's what I meant by modifiers :). It is not unlike [&] and [=] I guess (except for the "tiny" detail that lifetimes are checked).

BTW, I'm not sure what the [1] reference in my comment was supposed to point to though.

Re: C++11 FAQ

#73

Post by StephanTLavavej »

weerd wrote: post #57
ytugiuyghvk wrote: post #42

Earlier quoted context omitted.

If you want to template on an r-value reference, the easiest way is probably to use a forwarding reference and disable the template if the template parameter deduces to a reference template ::value>> auto f(T&& x);

Is this C++14? Can you please explain the "class = ..." template parameter?

Yes, that's C++14.

First, "class = enable_if_t::value>" is just "class Dummy = enable_if_t::value>" that doesn't bother to name Dummy. It's providing a default template argument for a function template (this is a C++11 feature; in C++03, only class templates could have this).

Next, "enable_if_t::value>" is a C++14 library feature (enable_if_t is an alias template; the Core Language gained alias templates in C++11, the library gained these in C++14). It is a synonym for "typename enable_if::value>::type", which is more verbose (and what one had to type in C++11).

"is_reference::value" is a C++11 type trait, that is true when T is X& or X&&, and false otherwise. (It's implemented with partial specializations, and a "static const bool value = true;" data member - actually constexpr these days, but no difference there. This is type traits 101.)

enable_if is a library helper for SFINAE. (Not necessarily C++11 Expression SFINAE; here, just C++03 classic SFINAE is being used.) Basically, enable_if::type is void. enable_if::type doesn't exist. This works with the Core Language's SFINAE rules to make function templates vanish from the overload set (if you don't know what SFINAE is, look it up; it's a little complicated, but it exists for good reasons, and it goes back to C++98).

So, this is how one writes a function template that vanishes under certain criteria. This is often desirable compared to doing different things for different types (that can often be done with "tag dispatch") or emitting compiler errors for certain types (that's a static_assert).

Re: C++11 FAQ

#74

Post by GFK_of_xmaspast »

gpderetta wrote: post #58
GFK_of_xmaspast wrote: post #43

Earlier quoted context omitted.

Perl was doing just fine until they fell in the perl6 hole and stagnated. Scala's getting its data science niche, and lisp has a lot more problems than just being multi-paradigm.

> Perl was doing just fine until they fell in the perl6 hole and stagnate i.e. backward compatibility is king. Paraphrasing Stroustrup, there are two kinds of languages, those that are full of old cruft and those that are too green to have been proven in the field.

The perl6 problem wasn't 'backward compatibility', the perl6 problem was 'this thing doesn't exist at all but it's sucking up all the momentum.'

Re: C++11 FAQ

#75

Post by kevinnk »

cmrdporcupine wrote: post #37
dragontamer wrote: post #33

Earlier quoted context omitted.

> Arguably the std::move stuff and the semantics around it have added uncomfortable complexity to the language Compared to using std::auto? Nah man. std::move is far easier to understand than trying to shove both concepts down operator=. std::unique is simply easier to use than std::auto by any real measurement.

My perhaps naive uneducated opinion: they should have added syntactic sugar for it instead of making it look like a function. A new operator perhaps.

How does adding an operator help? There are two main advantage of having move semantics in the language and at least one of them relies on the fact that moves are implicit; you can write code that will move objects if supported and copy/destroy if not (for example, when returning an object or using an intermediate value in an expression). Adding an operator erases that advantage.

The other advantage is that you can force only move semantics which allows enforcing things like ownership. Adding an operator doesn't destroy this advantage, but it is a bit silly since you're just adding line noise for something that really should be implicit anyway.

Unless you just literally don't like the spelling of "std::move" which seems pretty lame since it should be relatively rare anyway.

Re: C++11 FAQ

#76

Post by cousin_it »

JoeAltmaier wrote: post #26
cmrdporcupine wrote: post #23

Earlier quoted context omitted.

Arguably the std::move stuff and the semantics around it have added uncomfortable complexity to the language, even if it might have been necessary. Other than that I think other advances in C++11 and beyond have made for a quite nicer language to work in. I love C++11 and use it every day, but I think putting references in the language was an 'original sin'. They should have stuck with C's model: it's either a value…

Surely references have intrinsic value to the programmer? They're a pointer that can't be moved or rebased. Other languages have only references, and in C++ you can use that convention and not have any extra confusion.

References are crazy. There's no simple guideline to use them safely. Check this out:

    const string& s = max("a", "b");
    cout
Standard types and functions, const references, no warnings, everything by the book. But it crashes.

There's a similar can of worms related to slicing (treating Derived* as Base* is silently unsafe because arrays and copy constructors exist). C++ is scary.

Re: C++11 FAQ

#77

Post by cbsmith »

huhtenberg wrote: post #3

I've been programming for money for over 20 years and I grew up professionally writing C and then half-migrating to C++, because the latter very naturally captured lots of C patterns and allowed for more succinct expression of the same. It was lean, expressive and elegant . Just needed a bit of Lisp-y closures and it would've been perfect. And then things got completely out of hand. Elegance was nuked from the high o…

The mistake is looking at C++ as just an enhanced C (understandable given the name, the marketing, etc.). It's kind of like when they marketed Windows as a DOS upgrade...

In reality, C++ is an entirely different language that provides partial C compatibility (in fairness, it is more compatible than just about any other language out there) in order to improve adoption and minimize the impedance mismatch with systems interfaces (which, at least back in the day, were predominantly C, and largely still are).

If we called "C++" "NotC", and then wrapped all the C compatibility features (type coercion, malloc()/free(), C strings, etc.) with a "unsafe mode" flag, it'd all make much more sense.

Re: C++11 FAQ

#78

Post by cbsmith »

deong wrote: post #62
spoondan wrote: post #22

Earlier quoted context omitted.

This is perhaps one of the more unexpected opinions on C++ I've encountered. When I picked up C++ with Turbo C++ 3.0 in the early '90s, it was already widely regarded as an over-complex behemoth. Donald Knuth said of it in 1993, "Whenever the C++ language designers had two competing ideas as to how they should solve some problem, they said 'OK, we'll do them both'. So the language is too baroque for my taste." The la…

The thing is that something like computing primes with template instantiations was always a little weird and came with problems around sensible build processes. The rules were...well...complicated, but not that complicated. You had ADL rules that were weird, but basically, you could view a lot of the template hackery as a weird thing that you could understand without too much trouble, but probably didn't need to. Tha…

> C++ has always been complex, but I defy anyone to read "Effective Modern C++" from cover to cover without clutching their pearls in horror.

Actually, Effective Modern C++ was pretty awesome. A good guide through all the complexity.

Re: C++11 FAQ

#79

Post by VodkaHaze »

kitd wrote: post #44
huhtenberg wrote: post #3

I've been programming for money for over 20 years and I grew up professionally writing C and then half-migrating to C++, because the latter very naturally captured lots of C patterns and allowed for more succinct expression of the same. It was lean, expressive and elegant . Just needed a bit of Lisp-y closures and it would've been perfect. And then things got completely out of hand. Elegance was nuked from the high o…

I returned to C++ 3 years ago, having previously used it in the mid-1990s. I tend to agree with you, but I found that it was necessary to forget my old C mindset (pretty easy since it was 20 years old) and start learning modern C++ idioms from scratch. Eg, back in the days, I could fling raw pointers around with abandon. Now they need to be handled with care, and there are many tools and patterns available for you no…

> fling raw pointers around with abandon.

Jitters in seat

Re: C++11 FAQ

#80

Post by cbsmith »

huhtenberg wrote: post #46
spoondan wrote: post #22

Earlier quoted context omitted.

This is perhaps one of the more unexpected opinions on C++ I've encountered. When I picked up C++ with Turbo C++ 3.0 in the early '90s, it was already widely regarded as an over-complex behemoth. Donald Knuth said of it in 1993, "Whenever the C++ language designers had two competing ideas as to how they should solve some problem, they said 'OK, we'll do them both'. So the language is too baroque for my taste." The la…

I started with C++ around '92, but you are right, C++ was already complex back then, but it was still manageable, you could, sort of, hold its larger picture entirely in your head and still had some elegance to it.

Honestly, back in '92 the language seemed easy, but the practice was hideously complex and error prone. Most people still couldn't even figure out how to do exceptions properly. I would argue that today, the language is more complex, but the practice is comparatively simpler (still complex as a ll get out, but compared to '92...).
Post reply on HN