15 replies to this topic

[Nils Pipenbrinck]

Hey folks.

I wonder if you guys already had a look at the C++0x proposal that will most likely made it into the C++ language.

Wikipedia has a nice summary of what we can expect: http://en.wikipedia.org/wiki/C%2B%2B0x

I have a lot of mixed feelings about the new features: Lots of them will make the code more readable and compact. However, they can also increase the complexity of C++ code up to a point where we may end up with unmaintainable code.

I think meta-programming based code is already on the edge of what a non meta-programming expert can understand (take a look at the boost libraries for example). If the new features are used in meta programming (oh boy - they will be used!) we'll end up with code that a "production coder" cannot understand anymore.

Also: How should new programmers learn the language with all these new features? It is already a nightmare if you start learning the language today.

How many month of daily study does it takes for a newbee to truly understand how the stl set implementation works for example? With all the new semantics the time it takes to master the language will go through the roof.

Comments?

[.oisyn]

I really like the new features. For production code, especially lambda's and closures (it's about time!), the foreach statement and static type inference (the new use of the auto keyword). Concepts will really help in the compiler error department and the self-documentation of code.

The meta programming features are very cool to play with, but in my experience don't end up so much in production code, although they will help creating a better implementation for standard library tools such as std::tr1::function. There will not be much people bothered with designing such functionality, so I think the increased complexity is not much of a problem.

Personally, I don't really care whether a language is easy to learn, but I don' think the learning curve of C++ is very steep either (it is very long though, and it gets steeper once you get in the outskirts of C++). Your comment is mostly focused on new people needing to learn the language. But you seem to imply that they need to learn the whole and complete language before they can begin programming. For actual production code you really only need to know the basis (like classes and const correctness and that sort of things). I could not care less if a job applicant doesn't know what variadic template arguments are, for example. You say: "How many month of daily study does it takes for a newbee to truly understand how the stl set implementation works for example?", but why does a newbie need to study how the std::set implementation works? It's not actually that important. The main thing that really makes stuff more complex is r-value references, but in essence you don't need to know about them to write actual correct code. You'll only need to know about it if performance is of utmost importance. Classes like std::set are predesigned to be as performant as possible (thereby making full use of r-value references) and obviously make full use of other the language features (such as initializer lists), which indeeds makes them less readable, but yet more usable. And in the end, isn't the latter what is most important for standard library code?

As for the things in the new specification that I'm missing or features that got dropped, I'd really liked to see modules and reflection. Especially other modern platforms like Java and .Net have a big advantage there. The current header system is totally outdated and prone to beginner errors, and reflection really helps to write more generic code. Also, they should have restricted overload resolution.

[Nils Pipenbrinck]

good points, oisyn.

For things that I would have welcomed in the language:

• Define that arithmetic right shift does a sign-extended shift. It's still implementation dependent as the comitee *still* cares about the theoretical fact that there may be non two's complement machines out there.
  
  
• Add new operators for bit-rotates on integers. This is usefull for integer code *and* gives the operator overload guys two new operators to play with.
  
  
• make integer square root, bit-scan/leading zero count and population-count part of the standard library. If these are standarized compiler-vendors can automatically replace them with intrinsics on all archtitectures. They do this with memcpy and similar primitive functions for years.

I need these integer things a lot, and as you can guess it annoys the heck out of me that I either write slow but portable code or have to rely on non-portable hacks. :-)

[monjardin]

.oisyn said:

...lambda's and closures (it's about time!)...

AMEN! Good riddance to typing out a functor just to do a simple operation in a for_each loop or alternatively using iterators in a regular for loop with begin/end function calls!

[Nils Pipenbrinck]

jep. That sucked hard. If C would have local functions it wouldn't be half as bad, but declaring functors or callback-functions has always sucked hard and never made the code more readable.

Declaring little lambdas where they are used is definately a improvement...

[Dia]

.oisyn said:

Also, they should have restricted overload resolution.

What kind of restrictions do you mean? What's wrong with the current overload resolution in your opinion?

[.oisyn]

The fact that ADL (argument dependent lookup) also considers namespaces of template arguments of a type.

 // some library
namespace a
{
    template<class T> void foo(T);
    template<class T> struct SomeContainer
    {
        void callFoo() { foo(*this); }
    };
}

// some user stuff
namespace b
{
    struct MyType { };
    template<class T> void foo(T);
}

int main()
{
    a::SomeContainer<b::MyType> c;
    c.callFoo();
}

This doesn't compile. The call to foo() in SomeContainer<>::callFoo() is ambiguous. Why? Because b::foo is considered as SomeContainer has a template argument that comes from the b namespace. The designer of the library obviously never intended this to happen.

See also http://www.open-std..../2006/n2103.pdf, which has some actual real-world scenario's. But alas, the proposal has been rejected.

[SmokingRope]

From a design standpoint I don't see how reflection could be put into C++ and still retain that same "system level" feel that it has always had. Reflection is a horribly verbose mechanism for inferring information about the source code at runtime.

I really enjoy occasional reflection based magic-tricks in languages like C# and java however the feature seems very managed to me. It would be like putting a garbage collector into the standard.

I have not spent nearly enough time reading the new standard but my favorites so far have been the auto keyword and r-value references.

[.oisyn]

SmokingRope said:

From a design standpoint I don't see how reflection could be put into C++ and still retain that same "system level" feel that it has always had. Reflection is a horribly verbose mechanism for inferring information about the source code at runtime.

I really enjoy occasional reflection based magic-tricks in languages like C# and java however the feature seems very managed to me.

Yet it isn't. As long as you don't want to actually compile classes and such, you could easily implement reflection with some compiler support. There are already third party C++ reflection libraries out there (which usually build a database by parsing the code, SEAL for example), but without actual language support it's difficult to enable stuff like attributed identifiers.

It would be very nice to be able to build a generic serializer that inspects the objects by means of reflection, rather than depending on having a custom serialization implementation for every type which is very error prone (an added member will not automatically get serialized)

Quote

It would be like putting a garbage collector into the standard.

C++ doesn't exclude garbage collection, mind you. An implementation with garbage collection can be 100% compliant. And more importantly, the C++0x standard actually has some wording to be able to support GC in some standard way. See http://www.open-std....2008/n2586.html for details.

[SmokingRope]

I found this more current copy of the gc standard, there may be even more recent revised copies too.

I think reflection support using a similar structure as the garbage collector would be very cool. I still think that putting a full reflection implementation into the standard would be too heavy.

Looking at your wording again i'm not sure we can conclude one way or the other about whether you would prefer reflection support or an implementation. :lol:

[.oisyn]

SmokingRope said:

I found this more current copy of the gc standard, there may be even more recent revised copies too.

I know, but that one hasn't been worked into the specification yet, so in theory it may still be rejected

Quote

I think reflection support using a similar structure as the garbage collector would be very cool. I still think that putting a full reflection implementation into the standard would be too heavy.

Looking at your wording again i'm not sure we can conclude one way or the other about whether you would prefer reflection support or an implementation.

What I want is extending the type_info class to include some more meta information, such as size and alignment of the type, and which base classes and datamembers it has (at which offsets). What would furthermore be nice is to be able attach attributes to types/members, to instantiate a type, and to query which methods it has and to be able to call them (using something like std::vector<boost::any> as a means to pass along parameters)

[SmokingRope]

.oisyn said:

query which methods it has and to be able to call them (using something like std::vector<boost::any> as a means to pass along parameters)

I was thinking arguments could be passed via the old elipses '...' or the new variadic template parameters.

Do you have any thoughts about the 'not-quite-functions' including operator overloads, casts, and global operators. Do these objects all deserve full meta-information? Another would be template instantiations, will all template instantiations have full meta information and would information about template arguments be necesarry? Template member functions? Global functions? (I've never looked closely at what java and C# does in some of these areas and perhaps this isn't really as challenging as I initially thought).

Would you expect any new language syntax to be necesarry or can it be implemented entirely within the stl?

[.oisyn]

SmokingRope said:

I was thinking arguments could be passed via the old elipses '...'

No, passing non-trivial objects through elipses results in undefined behaviour. The implementation wouldn't be able to call the appropriate copy contructors and destructors, not to mention client code isn't able to manually fill in the parameter list at runtime (for script bindings for example)

Quote

or the new variadic template parameters.

Also not an option, you're talking to an interface, and such methods can't be made virtual. You could of course call a nonvirtual helper function which uses variadic templates, which in turn converts it to an array of boost::any or something and calls the virtual function.

Quote

Do you have any thoughts about the 'not-quite-functions' including operator overloads, casts, and global operators.

Why are these "not-quite-functions"? There are no different from ordinary functions, and you can already call them using a function-style syntax. The only difference is that some syntactic sugar exists to call them indirectly (a + b, rather than operator+(a, )

Quote

Another would be template instantiations, will all template instantiations have full meta information

For types, yes. All template instantiantions are seperate types. They each already have a different type_info structure. For methods I'd say no, calling such a method would be tedious as it might not have been instantiated yet.

Quote

and would information about template arguments be necesarry?

Above paragraph implies a "no".

Quote

I've never looked closely at what java and C# does in some of these areas and perhaps this isn't really as challenging as I initially thought.

Generics are somewhat different than templates. Especially the Java implementation is really no more than syntactic sugar. There were already Java compiler implementations that supported generics which compiled to regular Java pre-5 bytecode. It basically works by placing the appropriate casts where types are contravariant. A Vector<String> is basically just a Vector<Object>, and the Vector implementation can never call methods that are specific to String because it has to work with every class type (and therefore T behaves as if it were an Object inside the implementation, or whichever subclass or interface you define in the generic type contraints).

The .Net implementation is somewhat more elaborate as you can also use value-types as generic arguments, and the VM will basically recompile the bytecode.

Quote

Would you expect any new language syntax to be necesarry or can it be implemented entirely within the stl?

Well, unless you want to support something like attributes like Java and .Net do, you obviously have to change the language, but other than that it could be completely implemented in the standard library by simply extending the type_info structure with the appropriate members. Which is what 3rd party solution are already doing, but that requires an extra pass over the code and you'll get in trouble with non-standard extensions.

[SmokingRope]

.oisyn said:

Why are these "not-quite-functions"? There are no different from ordinary functions, and you can already call them using a function-style syntax. The only difference is that some syntactic sugar exists to call them indirectly (a + b, rather than operator+(a, b))

In the case of member operator overloads and casts it could be trivial to access them by their function-style names. It does seem to offer some opportunity for an alternative syntax to be introduced for example typeid(MyClass).Method("+") or some such.

For global operator overloads, do the functions become associated to the type of their first parameter or are they treated to exist within the global scope?

It does not appear that the type_info library could be used to access anything else in the global scope. Of course if this is not supported it will limit the reflection api's ability to invoke any functions in C-style applications.

[.oisyn]

What are you getting at? You're asking questions as if I'm the one designing a C++ reflection library, which I am not nor are interested in doing so . Needless to say such a library would be possible as it in fact already is using 3rd party solutions, and I would love to have seen such a thing in the upcoming standard, but alas

[SmokingRope]

I didn't mean to grill you about it! :lol: I'm just speculating on something I too would be interested in seeing.