I was reading Wikipedia's C++0x article and there were many things
that irked me. This isn't a bash of C++0x, after all, some of the
stuff on there is really neat!, but there are many things,
unfortunately some of the neatest parts, that I really don't get.

Here's the article in case you want to reference something I say:
http://en.wikipedia.org/wiki/C%2B%2B0x

Concept syntax.
This is actually an example of being one of the neatest parts, but I
don't get it.

Templates syntax is like so:
>>>returnType template< class type >classNume(){};
Concept syntax is like so:
>>>auto concept name< typename type > {}
but wouldn't it be more consistent to write is like this:?
>>>Auto concept< typename type > conceptName {};

Aren't concepts awfully close to Java's Interfaces? Wouldn't calling
them something that's been established by another language be
helpful?


Lambda:

Geese, the syntax for these just looks bloody confusing! It doesn't
even look C++!
>>>[] ( type arg ) -> returnType { statement; return expr; }
This makes no sense to me as to why they'd do this instead of
>>>returnType []( type arg ) { ... }
And what's up with the []?

One thing that really bothers me about this is it makes for_each
syntax more obtuse to me. I've always wanted to use a for_each as if
it were a regular for loop, but...
>>>for_each(someList.begin(), someList.end(), [&](int x) { /// The func is
the third arg. Not what I want.
>>> ...
>>>}); // I don't want to have to OR ; here.

Looking at the earliest proposal of this (N1958), the syntax feels
much more sane to me. The ones past that seem useful, maybe, but
obfuscated. When I looked down the proposal, it used <> instead of [],
so I'm wondering if this is a factual goof of Wikipedia or if they're
going off something else.


Unified function syntax:
>>>template<typename LHS, typename RHS>
>>>[]AddingFunc(const LHS &lhs, const RHS &rhs) -> decltype(lhs+rhs) {return
lhs + rhs;}
Wow, I don't believe it. The compiler just can't figure out
decltype(lhs+rhs) until LHS and RHS are defined which is why the
normal syntax won't work, eh? It can't just read the rest of the line
first? But, then again, this is something I can easily get away with
not using (whereas the others are too neat to avoid!), so I won't
bother concocting a large argument for it.


Nullptr:
No real quarrel here, it's just that NULL is such a classic, I don't
know how the transition will be.


Strongly types enums:
Actually, I like this idea so much, I just wanted to mention it in my
monologue.


Explicit conversion operator:
Again, so awesome, I just wanted to mention it. I actually am using
the risky code this would make safe—not that I'm having any trouble,
though.

PS: Is it pronounced C++ zero X, C++Hex or what?


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On Aug 11, 3:00 am, "Hak...@gmail.com" <Hak...@gmail.com> wrote:

> Templates syntax is like so:>>>returnType template< class type >classNume(){};
>
> Concept syntax is like so:>>>auto concept name< typename type > {}
>
> but wouldn't it be more consistent to write is like this:?
>
> >>>Auto concept< typename type > conceptName {};

It depends. Personally, I see concepts as a kind of predicate (i.e.,
function) over types, so function-like syntax makes sense.

> Aren't concepts awfully close to Java's Interfaces? Wouldn't calling
> them something that's been established by another language be
> helpful?

Not really. Interfaces are run-time checked, concepts are compile-
time. If anything, concepts are more similar to what is called
"traits" in some other languages.

> Lambda:
>
> Geese, the syntax for these just looks bloody confusing! It doesn't
> even look C++!>>>[] ( type arg ) -> returnType { statement; return expr; }
>
> This makes no sense to me as to why they'd do this instead of>>>returnType []( type arg ) { ... }

Because you can omit the return type; also, see below.

> And what's up with the []?

I agree it's probably not the best lambda introducer out there, but
there weren't that many options. A new keyword would have to be
lengthy to avoid name collisions with existing code, and all obvious
candidates ("function", "lambda", "closure" etc) are likely to be
popular identifiers. And most of punctuation symbols are used already,
often in many different ways. And there are only so many combinations
that can be parsed unambiguously (and noone wants to repeat the mess
with >> and templates).

> One thing that really bothers me about this is it makes for_each
> syntax more obtuse to me. I've always wanted to use a for_each as if
> it were a regular for loop, but...>>>for_each(someList.begin(), someList.end(), [&](int x) { /// The func is
>
> the third arg. Not what I want.
>
> >>> ...
> >>>}); // I don't want to have to OR ; here.

I don't see anything wrong with such style (similar syntax has been
happily used in C# for several years now, without many complaints - or
maybe people have just got used to it), but for-loops in particular
have their own separate proposal, so you can just write:

for (int x : someList) { ... }

> Looking at the earliest proposal of this (N1958), the syntax feels
> much more sane to me. The ones past that seem useful, maybe, but
> obfuscated. When I looked down the proposal, it used <> instead of [],
> so I'm wondering if this is a factual goof of Wikipedia or if they're
> going off something else.

It was <> in earlier proposals, but the meaning of these symbols is
overloaded many times already (comparison, bit shift, templates).
Also, it might be that they've found a syntactic ambiguity when
combining that proposal with the existing grammar. I believe there was
an explanation given in the proposal draft where it was changed - if
you're really curious, you can just check the Committee submissions
archive, and find it.

> Unified function syntax:>>>template<typename LHS, typename RHS>
> >>>[]AddingFunc(const LHS &lhs, const RHS &rhs) -> decltype(lhs+rhs) {return
>
> lhs + rhs;}
> Wow, I don't believe it. The compiler just can't figure out
> decltype(lhs+rhs) until LHS and RHS are defined which is why the
> normal syntax won't work, eh?

The compiler can do it, but, as a rule, in C++ declaration is only
visible from the point it was made, not before it. Imagine, in the
example above, that "lhs" and "rhs" are also globals. A C++ developer
can reasonably expect that using decltype() with normal function
declaration syntax would reference those global variables, and not the
function arguments.

Besides, it's really a good chance to clean up the messy function
declaration syntax that C++ has inherited from C - it really doesn't
play well with complex nested types (recall a signature for a function
returning an array of pointers to functions taking a void() function).

> Nullptr:
> No real quarrel here, it's just that NULL is such a classic, I don't
> know how the transition will be.

nullptr, not being an integral constant, is vastly superior to NULL
(which, by the way, is often frowned upon in pure C++ code), so I'd
imagine that most people jump ship as soon as possible. It really is
something that's long overdue.

> PS: Is it pronounced C++ zero X, C++Hex or what?

Hopefully, it will be pronounced C++09.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Pavel Minaev wrote:
> On Aug 11, 3:00 am, "Hak...@gmail.com" <Hak...@gmail.com> wrote:

[...]

>> Unified function syntax:>>>template<typename LHS, typename RHS>
>>>>> []AddingFunc(const LHS &lhs, const RHS &rhs) -> decltype(lhs+rhs) {return
>> lhs + rhs;}
>> Wow, I don't believe it. The compiler just can't figure out
>> decltype(lhs+rhs) until LHS and RHS are defined which is why the
>> normal syntax won't work, eh?

C++-0x has already addressed the issue with the function syntax. The
"unified function syntax" is an extension to this existing change. The
current "fixed" syntax uses 'auto':

auto AddingFunc(const LHS & lhs, const RHS & rhs) -> decltype (lhs+rhs);

>
> The compiler can do it, but, as a rule, in C++ declaration is only
> visible from the point it was made, not before it. Imagine, in the
> example above, that "lhs" and "rhs" are also globals. A C++ developer
> can reasonably expect that using decltype() with normal function
> declaration syntax would reference those global variables, and not the
> function arguments.
>

Well, the situation today is that the compiler does not do it. Consider
an out of line member definition:

typedef int I;

struct A
{
typedef float I;
I foo ();
};


// The following fails today - need to have 'A::I' for the return type
I A::foo ()
{
}

// New syntax
auto A::foo () -> I // 'I' is looked up in A first
{
}


> Besides, it's really a good chance to clean up the messy function
> declaration syntax that C++ has inherited from C - it really doesn't
> play well with complex nested types (recall a signature for a function
> returning an array of pointers to functions taking a void() function).

The "cleaning" up step has already taken place:

auto foo(int i) -> int


To say that I dislike the new unified syntax would be an understatement,
and I think it just adds unnecessary "complexity". I think it's more
important to have a descriptive syntax that has a clear meaning, rather
than having to manually distinguish the same set of tokens depending on
the context.

IMHO, the examples that use unified syntax are only "just" legible by
using appropriate white space:

[]foo() -> void { delete [] m_x; } []operator[](size_type i) const ->
const_reference { int a [10]; []bar(int) -> int ; bar (10); }

How many functions? Any lambdas?

auto foo() -> void { delete [] m_x; } auto operator[](size_type i) const
-> const_reference { int a [10]; auto bar(int) -> int ; bar (10); }

How many functions now?


Already a common coding standard rule exists to ensure that white space
can't cause reader confusion:

if (i) // 'if' statement without { }
++j;
++k;


The use of [] is required for a 'lambda' as a place holder is necessary
for the capture list. However a lambda is, well, a "lambda". It is not
a function, it has different semantics to a function and so it is better
that it does not look like a function. We already have problems where
readers can be confused between object and function declarations - why
are we so keen to add to this problem?

A a(b); // Function 'a' or object 'a'?


There are at least 3 types main readers of source code: human, compiler
and, code comprehension tools/editors. Reusing tokens to provide
different semantics complicates the job of each reader, and in the
latter case, if your "emacs" C++ mode displays a function as a lambda or
vice versa then this just makes the job of the human reader even harder!

'auto ... ->' has fixed the problem - Lets leave it at that!


>> PS: Is it pronounced C++ zero X, C++Hex or what?
>
> Hopefully, it will be pronounced C++09.


At this point, I think that is very unlikely. However, a lot of
compiler vendors are working on these features now - so even without a
standard people will be able to write code using C++-0B syntax! :)


Cheers,

Richard


--
Richard Corden

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On Aug 11, 5:28 am, Pavel Minaev <int...@gmail.com> wrote:
> > And what's up with the []?
>
> I agree it's probably not the best lambda introducer out there, but
> there weren't that many options. A new keyword would have to be
> lengthy to avoid name collisions with existing code, and all obvious
> candidates ("function", "lambda", "closure" etc) are likely to be
> popular identifiers. And most of punctuation symbols are used already,
> often in many different ways. And there are only so many combinations
> that can be parsed unambiguously (and noone wants to repeat the mess
> with >> and templates).

Right. Introducing a new keyword might not be the answer, but I don't
feel tricky symbols are the answer either. I've heard of recycling old
keywords in cases like this, so why not recycle the inline keyword? It
has no current purpose being in the context, so it's hard to mistake,
and it kind of makes sense, doesn't it? You're inserting a function,
literally, in the line!

> I don't see anything wrong with such style (similar syntax has been
> happily used in C# for several years now, without many complaints - or
> maybe people have just got used to it), but for-loops in particular
> have their own separate proposal, so you can just write:
>
> for (int x : someList) { ... }

If that would work on an STL object? Good. I'm sold.

> > Unified function syntax:>>>template<typename LHS, typename RHS>
> > >>>[]AddingFunc(const LHS &lhs, const RHS &rhs) -> decltype(lhs+rhs) {return
>
> > lhs + rhs;}
> > Wow, I don't believe it. The compiler just can't figure out
> > decltype(lhs+rhs) until LHS and RHS are defined which is why the
> > normal syntax won't work, eh?
>
> The compiler can do it, but, as a rule, in C++ declaration is only
> visible from the point it was made, not before it. Imagine, in the
> example above, that "lhs" and "rhs" are also globals. A C++ developer
> can reasonably expect that using decltype() with normal function
> declaration syntax would reference those global variables, and not the
> function arguments.
>
> Besides, it's really a good chance to clean up the messy function
> declaration syntax that C++ has inherited from C - it really doesn't
> play well with complex nested types (recall a signature for a function
> returning an array of pointers to functions taking a void() function).

Isn't that the point of the auto keyword? It sounds right down the
alley of its mission statement. Wikipedia even says "[the type] is
easily known to the compiler, but is not easy for the user to
determine upon inspection." I'm still new to a lot of this, so I'm not
sure I get it, even if I understand the words.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On Aug 10, 7:00 pm, "Hak...@gmail.com" <Hak...@gmail.com> wrote:
> I was reading Wikipedia's C++0x article and there were many things
> that irked me. This isn't a bash of C++0x, after all, some of the
> stuff on there is really neat!, but there are many things,
> unfortunately some of the neatest parts, that I really don't get.
>
> Here's the article in case you want to reference something I say:http://en.wikipedia.org/wiki/C%2B%2B0x
>

I, too, think they are making some great changes/additions to the
languages. I just wish they would not use such ugly, ugly syntax just
to avoid adding keywords and breaking existing code. Although I
realize that breaking existing code is a serious issue, it seems the
alternative is making the language much harder for novices to learn.
It can also be hard to read (though easier than Perl!). Many of my
coworkers are finding C++ much harder to learn than languages such as
Ada which have (in my opinion) much less symbology and more
"words." (Please don't take that as an endorsement of Ada, et. al.,
over C++. It is not meant to be, and such arguments are tiresome.)

REH


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On Aug 10, 4:00 pm, "Hak...@gmail.com" <Hak...@gmail.com> wrote:
> Concept syntax is like so:>>>auto concept name< typename type > {}
>
> but wouldn't it be more consistent to write is like this:?
>
> >>>Auto concept< typename type > conceptName {};
>
> Aren't concepts awfully close to Java's Interfaces? Wouldn't calling
> them something that's been established by another language be
> helpful?

Concepts aren't close enough to interfaces to benefit from the
analogy. Calling concepts "interfaces" might give the reader some idea
of what concepts do, but the analogy breaks down in most non-trivial
uses of concepts and would do more harm than good. There is a short
discussion of the differences between Generic Programming (as
supported by concepts) and Object-Oriented Programming (as supported
by Java interfaces), with pointers to much more information, here:


http://www.generic-programming.org/f...ed-programming

- Doug


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]