C++0x/11 discussion thread

[FeZedra]

I'm not sure if this is the right section, but I thought I'd give it a go. Also, I'm not sure if this has been posted before as I've been inactive from this forum for about 2 years.

So, what do you think about C++11? I think it's very good (as of my current knowledge of it). I have started doing an alternative 2D Client of an old game I used to play, with a group of hackers over the interwebz since 1-2 year(s) ago and it's still alive. It uses almost everything from C++11, here is the github repo: http://tinyurl.com/7ly266m (Uses OpenGL 1 or 2 for rendering - also supports iPhone using OpenGL ES).

Let me know your opinion!

[Cubbi]

what do you think about C++11?

I've gone over pretty much every line of it, and was very impressed by the amount of tiny changes to every nook and cranny of the language and the library. So many fixes to tiny inconsistencies spotted by the compiler writers and the programmers over the years, so many improvements and helpful changes. And of course, all the big stuff, merging the TR1 into the mainline language standard, merging more stuff from boost, the new memory model (done right, thanks to Java's mistakes) the moves, etc. It's a huge improvement.

Granted, it still had a few silly typos (mostly fixed in n3337), and several DRs were raised right after publication due to overlooked poor wording, and some much wished-for stuff didn't make it.

[rapidcoder]

the new memory model (done right, thanks to Java's mistakes) the moves

What mistakes?

As for the OP question:

C++11 concentrates on:

1. Fixing minor annoyances:
- unions with classes containaing constructors
- extern templates,
- fixing >> WTF with templates
- sizeof for fields

2. Copying stuff from other languages:
- strongly typed enums (close, but still not as powerful as in Java)
- override and final (Object Pascal, Java, C#, Scala)
- calling constructors from constructors (Java)
- range based for (Java, C#, Python,... well, almost every other language)
- long long int (C)
- lambdas (for me they took second place in the contest for the most ugly syntax for lambdas, first prize goes to PHP)
- new meaning of auto (a very, very limited kind of type inference; Haskell, ML and Scala got much better)

3. New features (nice):
- r-value references, move constructors
- new initialization syntax (which will be very likely a new source of WTFs)
- constexpr

4. Library extensions:
- thread support (better late then never, just on time when modern languages start to dismiss threads for actors / STM / implicit parallelism)
- 4 kinds of smart pointers, yay
- regex support
- 1000 classes for generating random numbers (WTF?)
- some metaprogramming facilities

5. New WTFs:
- literal operator

6. Excluded features:
- concepts (this one was really ugly, compared to how similar feature works in other mainstream languages)
- modules (have to live with header files and slow compile times for the next 10 years)

[Cubbi]

@rapidcoder the ones fixed by JSR 133

[ResidentBiscuit]

From what I've read, there isn't a thing in there that sounds bad or out of place. For some reason, I mostly excited about the built in regex support, but that's probably just me haha.

[FeZedra]

@The java thing, I've never used java before, but I heard it doesn't even have real lambdas yet...

[Cubbi]

Oh, right, as far as excitement:

I've been using boost for many years, so hashes, arrays, smart pointers, threads, random number generators, regular expressions, bind/function/mem_fn, reference wrappers, enable_if and all the type traits, exception pointers, error categories, tuples, static_assert, ranged for, etc were all old and familiar stuff.

Plus I use C, so the missing C stuff like fixed-size integers or the C99 math (ltgamma, hypot, fpclassify, etc), was kind of a 'duh' (okay adding all the fenv stuff to C++ wasn't that much of a 'duh', since so few vendors support it, I really hope it gets on more people's radar now)

I'm mostly appreciating the little tweaks and touch-ups, like fstream constructor taking a string, or sqrt(int) no longer being ambiguous, or the return of the iota and copy_if, or the new rules for cin >> i

Of the actually new (non-boost, non-C) features, I guess I am mostly excited about
1. the new memory model (I think the sweetest part is the explicit dependency control (kill_dependency/carries_dependency), although that's kinda useless to me as I am not in OS development anymore)
3. the rvalue revolution (moving, emplacing, and forwarding)
4. the constexpr revolution (it's been kinda off the radar so far, but we have a whole new programming language here)
5. Variadic templates (this changed the look of metaprogramming so much)
6. Unicode support (shame on GCC for not supporting it, even Microsoft did it, two years ago)
7. Stateful allocators (I use them for *everything* at work)
8. Standardized alignment control (which C promptly snatched, too)
9. Standardized atomic operations (those endless #ifdefs can go)
10. auto/decltype/declval and type aliases

I have mixed feelings about

1. closures/lambda-expressions -- boost has nicer syntax and features, but it took three generations of backwards-incompatible libraries to get there. On the other hand, boost can't do implicit capture or function pointer conversion since it's just a library.

2. chrono library and time I/O manipulators - they are not working together. chrono desperately needs chrono_io, and they all need a calendar library. Granted, there finally *is* a way to parse dates in C++, but I keep using boost for all my date/time needs.

3. Mark-sweep garbage collection interface. I know some people use it in C++, but it's so much counter to many good things about the language, there probably won't be enough demand to implement it.

[3hM2Nwbp]

@The java thing, I've never used java before, but I heard it doesn't even have real lambdas yet...

The closest thing that Java has includes more boilerplate code than you can shake a stick at. It also creates a class for every "closure" that you make, not to mention the class for the closure type as well...so...

and speaking of WTF's, isn't it about time to remove type-erasure from Java's generics system - or at least feature a way to disable it?

public class Test
{


  private static interface DoSometing
  {
    void doSomething();
  }

  void doIt(DoSomething something)
  {
    something.doSomething();
  }

  public static void main(String... _)
  {
    new Test().doIt(
      new DoSomething()
      {
        @Override
        public void doSomething()
        {
           System.out.println("I'm doing something!");
        }
      }
    );
  }
}

On track: I'm most excited about finally getting standard threading support! Add in standard networking and support for standard compression algorithms and then I won't have any reason to use Java anymore.

[o1vk4iN6]

Why not just use boost ? It isn't standard but that's where it seems a lot of what is being added comes from, type traits, threading, regex and possibly networking (future?).

[rapidcoder]

The closest thing that Java has includes more boilerplate code than you can shake a stick at. It also creates a class for every "closure" that you make, not to mention the class for the closure type as well...so...

Java 8 will have full fledged lambdas, very similar in design to these from Scala. Anyway, why wait for it, if I can use lambdas from Scala, Clojure or Groovy *right now*? They've been available for several years now and with much nicer syntax than what they introduced in C++.

Anyway, lambdas in a language without GC is a big misunderstanding. They might be useful in *some* cases, but lack of GC kills most of applications they are used in functional languages.

and speaking of WTF's, isn't it about time to remove type-erasure from Java's generics system - or at least feature a way to disable it?

Agreed, but this is usually not a big problem for anyone coding in Java. Just include the missing type information manually (Java) or let the compiler provide it for you (Scala). There are some corner cases, but, well, no language is perfect. At least generics are part of a type system and the compiler can reason about generic types, contrary to a macroprocessor hack they are in C++.

Mark-sweep garbage collection interface. I know some people use it in C++, but it's so much counter to many good things about the language, there probably won't be enough demand to implement it.

Agreed. You can't implement an efficient GC for C++ even with that additional support from the compiler. It will still be orders of magnitude slower than Java's. It is just wasting time trying to do that.

[ResidentBiscuit]

Anyway, lambdas in a language without GC is a big misunderstanding. They might be useful in *some* cases, but lack of GC kills most of applications they are used in functional languages.

There are garbage collectors for c++ you can use, if you really want to.

[rapidcoder]

There are garbage collectors for c++ you can use, if you really want to.

All are crap, slow, unresponsive and even don't guarantee reclamation of all garbage, therefore almost noone uses them. The only valid use case is if you have a leaking library without source code and somehow you have to avoid the leaks.

[ResidentBiscuit]

@rapidcoder,

Yea I have no experience with them, just read somewhere that Strousup mentioned them, and claimed they were "very good".