www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - C++0x news

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Executive summary: C++0x will in all likelihood be C++11, export finally 
gets the axe (thank God), exception specifications get deprecated, 
noexcept gets added... well pretty much what D does :o).

Andrei

-------- Original Message --------
Subject: 	[herb_sutter] Trip report: March 2010 ISO C++ Meeting
Date: 	Sat, 13 Mar 2010 19:55:04 +0000
From: 	Herb Sutter <hsutter microsoft.com>
Reply-To: 	herb_sutter-owner yahoogroups.com
To: 	herb_sutter yahoogroups.com <herb_sutter yahoogroups.com>



Here's the link to the full blog post:
http://herbsutter.wordpress.com/2010/03/13/trip-report-march-2010-iso-
-standards-meeting/ 

<http://herbsutter.wordpress.com/2010/03/13/trip-report-march-2010-iso-c-standards-meeting/>

I've pasted the post below, but depending on the vagaries of Yahoo
Groups and the email format you selected, quotes and graphics and such
may not format correctly. Enjoy.

Herb

Trip Report: March 2010 ISO C++ Standards
Meeting<http://herbsutter.wordpress.com/2010/03/13/trip-report-march-2010-iso-
-standards-meeting/ 

<http://herbsutter.wordpress.com/2010/03/13/trip-report-march-2010-iso-c-standards-meeting/>>

March 13, 2010 by Herb
Sutter<http://herbsutter.wordpress.com/author/herbsutter/
<http://herbsutter.wordpress.com/author/herbsutter/>>

[Note: I usually post trip reports after the public post-meeting mailing
goes live a few weeks after the meeting, so that I can provide links to
minutes and papers. This time, I wanted to post the report right away to
share the news. If you're interested in the post-meeting papers,
including the official minutes, watch the 2010 papers
page<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/>> which is
where they will appear in a few weeks.]

The ISO C++ committee met in Pittsburgh, PA, USA on March 8-13, 2010,
hosted by the CERT Software Engineering
Institute<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2956.pdf
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2956.pdf>> at
Carnegie Mellon University<http://www.cmu.edu/index.shtml
<http://www.cmu.edu/index.shtml>>. As usual, about 50 experts attended,
and we had eight official national body delegations from Canada,
Finland, France, Netherlands, Spain, Switzerland, United Kingdom, and
United States.

[IMG_0396]The meeting just concluded a few minutes ago (yes, the
meetings run through Saturday afternoon). Here are some highlights of
what happened today, which was another landmark in the progression of
the C++0x standard.

Approved Final Committee Draft (FCD) for C++0x

The biggest news is that this afternoon we voted in the final remaining
feature changes to C++0x, and to much applause then unanimously approved
the text for international ballot as a Final Committee Draft (FCD). FCD
means that, assuming no surprises, we intend to do only bug fixes and
editorial corrections for the next year or so, and then ballot a final
standard. If we can do that, assuming all goes well, C++0x could
officially be published as soon as next year as ISO C++ 2011, and we can
stop with the "x-is-hex" jokes and just start calling it C++11.

This is a big milestone, and it was achieved thanks to removing a couple
of controversial features last summer and a whole lot of work by the ISO
C++ committee members over the past six months in particular. That work
includes countless hours spent between our full face-to-face meetings at
face-to-face ad-hoc meetings to swat library bugs, teleconferences on
resolving core language questions, and triple-digit person-hours
invested in four teleconferences during December-February purely about C
and C++ compatibility that have greatly helped to identify and attempt
to resolve minor areas of divergence between the C++0x draft standard
and the C1x draft standard (as both are now in progress; C1x is
targeting completion and publication in 2012).

All in all, your committee members have put in an enormous amount of
effort to bring this in, and the draft is in far better shape for this
meeting than anyone could have expected last summer. For comparison, in
my and several others' opinions, it's in better shape than the FCD of
the C++98 standard.

Since we're closing down this round of standardization, we didn't make
many exciting technical changes. Here are two technical highlights of
the meeting that are likely of general interest, finally adopting
changes we've contemplated before.

Removed Export Template

As I reported after the last meeting
(here<http://herbsutter.wordpress.com/2009/10/23/deprecating-export-con
idered-for-iso-c0x/ 

<http://herbsutter.wordpress.com/2009/10/23/deprecating-export-consi
ered-for-iso-c0x/>> 

and
here<http://herbsutter.wordpress.com/2009/11/11/trip-report-october-2009-iso-
-standards-meeting/ 

<http://herbsutter.wordpress.com/2009/11/11/trip-report-october-2009-iso-c-st
ndards-meeting/>>), 

the committee considered the question of whether to deprecate, remove,
or leave in the "export template" feature.

For context, the only reason we're even considering this is because
Edison Design Group (EDG), the only company to ever implement export, is
recommending export be removed or deprecated. Recall that back in the
1990s the committee originally voted the feature in over EDG's
objections in the first place, then in the late 1990s and early 2000s
EDG graciously and gallantly went on to invest enormous effort to
implement the feature in order to conform to the standard, and so the
committee was loath to punish them again by now removing the feature on
them. However, given the passage of time, EDG reports that their
experience in the field has been that nearly no one actually uses the
feature, and that it would be right (and okay with EDG) to deprecate or
remove it.

At our previous meeting, the general sentiment was in favor of
deprecation only. However, at this meeting EDG reported that they would
prefer the feature to be removed rather than just deprecated, because a
deprecated feature is still part of the standard and required for
conformance. By removing it from C++0x, it removes the maintenance
burden of being forced to support export indefinitely to maintain full
standards conformance (though of course EDG will continue to support it
as an extension in their compiler front end for however long seems right
based on their own customers' demand).

The committee agreed, and today voted to remove export entirely from
C++0x. The "export" keyword is still reserved for future use, but has no
defined meaning in the C++0x standard.

Deprecated Exception Specifications, Added noexcept

As also considered at our previous meeting, this week we went ahead and
deprecated throw-specifications (e.g., throw(), throw( Base, Derived1
)). For rationale, see the two background references referred to in the
proposal, one of which is an article by me:

* H. Sutter. "A Pragmatic Look at Exception
Specifications"<http://www.gotw.ca/publications/mill22.htm
<http://www.gotw.ca/publications/mill22.htm>>
* Boost. "Boost Exception Specification
Rationale"<http://www.boost.org/development/requirements.html#Exc
ption-specification 

<http://www.boost.org/development/requirements.html#Exception-specification>>

As noted in the second reference, "A non-inline function is the one
place a 'throws nothing' [i.e., throw()] exception-specification may
have some benefit with some compilers." Because this would have some
utility, there is a replacement for empty exception-specifications...
the noexcept keyword, which has the basic use syntax "void f() noexcept
{...}". It optionally takes a compile-time constant true/false
expression that if true means the noexcept is in force, which helps
libraries to write efficient overloads. This feature will be written
about for years to come, but that's the basic idea.

Here's the concise summary from the core working group report by Steve
Adamczyk (of EDG fame and longtime core working group chair):

We discussed two things related to exception specifications: noexcept
(N3050), and deprecating exception specifications (N3051). There was
some spirited discussion of what happens when you violate a promise not
to throw. In the end, we decided that in such a circumstance terminate()
gets called, and it's unspecified whether any cleanup is done for local
variables between the throw point and the point of the violated
noexcept. It's believed that for efficient implementations of exception
handling a noexcept will not add any overhead and will not restrict
optimization opportunities.

The old-style exception specifications, including the throw() form, will
now be deprecated. The library specification needs to be updated to use
noexcept instead, and that won't happen at this meeting.

Note that the decision to call terminate() is not final and alternatives
will be considered at future meetings. There was general (but not
universal) agreement that the program should not be allowed to continue
executing if a noexcept is violated because in that case the program
will almost certainly be in a corrupt state, and so the consensus was in
favor of guaranteeing to call terminate() instead of allowing arbitrary
undefined behavior, but it's possible that a comfortable middle ground
between those two options may yet be found.

Looking Forward

We wrapped up with a
presentation<http://www.facebook.com/photo.php?pid=3554907&id=835813469
<http://www.facebook.com/photo.php?pid=3554907&id=835813469>> of the
scheduled dates and locations for the next few ISO C++ standards
committee meetings (meeting information link included where available):

* August 2-7, 2010: Rapperswil,
Switzerland<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3016.pdf 

<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3016.pdf>>
* November 8-13, 2010: Batavia, Illinois,
USA<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3015.pdf
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3015.pdf>>
* March 21-26, 2011: Madrid, Spain

Finally, here's a copy of summary slide I presented, which will also be
in the post-meeting mailing. Here's to C++11 (we hope)!

[Pittsburgh slide.jpg]

[Non-text portions of this message have been removed]

__._,_.___
Reply to sender <mailto:hsutter microsoft.com?subject=Trip report: March
2010 ISO C++ Meeting> | Reply to group
<mailto:herb_sutter yahoogroups.com?subject=Trip report: March 2010 ISO
C++ Meeting> | Reply via web post
<http://groups.yahoo.com/group/herb_sutter/post;_ylc=X3oDMTJvdmdyajlsBF9TAzk3MzU5NzE0BGdycElkAzE0NTE2MTAEZ3Jwc3BJZAMxNzA1MDA2Nzg4BG1zZ0lkAzE5OARzZWMDZnRyBHNsawNycGx5BHN0aW1lAzEyNjg1MTA3OTE-?act=r
ply&messageNum=198> 

| Start a New Topic
<http://groups.yahoo.com/group/herb_sutter/post;_ylc=X3oDMTJlOW5kbG1xBF9TAzk3MzU5NzE0BGdycElkAzE0NTE2MTAEZ3Jwc3BJZAMxNzA1MDA2Nzg4BHNlYwNmdHIEc2xrA250cGMEc3Rpb
UDMTI2ODUxMDc5MQ--> 


Messages in this topic
<http://groups.yahoo.com/group/herb_sutter/message/198;_ylc=X3oDMTMyMnM3ZHZrBF9TAzk3MzU5NzE0BGdycElkAzE0NTE2MTAEZ3Jwc3BJZAMxNzA1MDA2Nzg4BG1zZ0lkAzE5OARzZWMDZnRyBHNsawN2dHBjBHN0aW1lAzEyNjg1M
A3OTEEdHBjSWQDMTk4> 

(1)
Recent Activity:

      * New Members
 
<http://groups.yahoo.com/group/herb_sutter/members;_ylc=X3oDMTJmYThjbjQ1BF9TAzk3MzU5NzE0BGdycElkAzE0NTE2MTAEZ3Jwc3BJZAMxNzA1MDA2Nzg4BHNlYwN2dGwEc2xrA3ZtYnJzBHN0aW1lAzEyNjg1MTA3OTE-?o=6>
        2

Visit Your Group
<http://groups.yahoo.com/group/herb_sutter;_ylc=X3oDMTJlMTFzc2dzBF9TAzk3MzU5NzE0BGdycElkAzE0NTE2MTAEZ3Jwc3BJZAMxNzA1MDA2Nzg4BHNlYwN2dGwEc2xrA3ZnaHAEc3Rpb
UDMTI2ODUxMDc5MQ--> 


To unsubscribe, send an empty email to
mailto:herb_sutter-unsubscribe yahoogroups.com.
Yahoo! Groups
<http://groups.yahoo.com/;_ylc=X3oDMTJkYjByZnU0BF9TAzk3MzU5NzE0BGdycElkAzE0NTE2MTAEZ3Jwc3BJZAMxNzA1MDA2Nzg4BHNlYwNmdHIEc2xrA2dmcARzd
ltZQMxMjY4NTEwNzkx> 


Switch to: Text-Only
<mailto:herb_sutter-traditional yahoogroups.com?subject=Change Delivery
Format: Traditional>, Daily Digest
<mailto:herb_sutter-digest yahoogroups.com?subject=Email Delivery:
Digest> • Unsubscribe
<mailto:herb_sutter-unsubscribe yahoogroups.com?subject=Unsubscribe> •
Terms of Use <http://docs.yahoo.com/info/terms/>
.

__,_._,___
Mar 13 2010
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:

 Executive summary: C++0x will in all likelihood be C++11, export finally 
 gets the axe (thank God),


Yay!


 exception specifications get deprecated, 


Yay!


 noexcept gets added... well pretty much what D does :o).


I predict that C++ will adopt a lot more of D stuff.
Mar 13 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hnh30m$1fv8$1 digitalmars.com...

 Andrei Alexandrescu wrote:

 Executive summary: C++0x will in all likelihood be C++11, export finally 
 gets the axe (thank God),


 Yay!


I had to look up what export templates were. It *seemed* like a good thing, 
but judging by these reactions it sounds like there was some sort of 
critical flaw with them?


 exception specifications get deprecated,


 Yay!


I'm not real familiar with those, but it sounds like it was simply a C++ 
version of Java'a checked exceptions? If so, I'm surprised they had even 
been considering them.


 noexcept gets added... well pretty much what D does :o).


 I predict that C++ will adopt a lot more of D stuff.


I predict that it still won't be nearly enough to make C++ nice to deal with 
compared to D ;)
Mar 13 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Nick Sabalausky:

 but judging by these reactions it sounds like there was some sort of 
 critical flaw with them?


It seems that implementing a whole Java VM requires less time than to implement
just that not very useful feature :-)



 I predict that it still won't be nearly enough to make C++ nice to deal with 
 compared to D ;)


The problem is that even if they can add most of the D things, they can't
remove other C++ things. And it's already the biggest ball of mud among
programming languages.

Bye,
bearophile
Mar 13 2010
parent "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:hnh4o4$1iue$1 digitalmars.com...

 Nick Sabalausky:

 I predict that it still won't be nearly enough to make C++ nice to deal 
 with
 compared to D ;)


 The problem is that even if they can add most of the D things, they can't 
 remove other C++ things. And it's already the biggest ball of mud among 
 programming languages.


Exactly!
Mar 13 2010
prev sibling parent Jonathan M Davis <jmdavisProg gmail.com> writes:
Nick Sabalausky wrote:


 "Walter Bright" <newshound1 digitalmars.com> wrote in message
 news:hnh30m$1fv8$1 digitalmars.com...

 Andrei Alexandrescu wrote:

 Executive summary: C++0x will in all likelihood be C++11, export finally
 gets the axe (thank God),


 Yay!


 
 I had to look up what export templates were. It *seemed* like a good
 thing, but judging by these reactions it sounds like there was some sort
 of critical flaw with them?
 


Herb Sutter did a great article on it:

http://www.drdobbs.com/cpp/184401563
http://www.drdobbs.com/cpp/184401584

Basically what it comes down to is that they don't really work and that 
trying to make them work breaks things. On top of that, they're really hard 
to implement, and I believe that only one group has done it (and as 
Bearophile pointed out, it took them long to implement template exports than 
it did for them to implement the entire java specification).

- Jonathan M Davis
Mar 13 2010
prev sibling next sibling parent BCS <none anon.com> writes:
Hello Walter,


 I predict that C++ will adopt a lot more of D stuff.
 


Imitation is the sincerest form of flattery?

-- 
... <IXOYE><
Mar 13 2010
prev sibling parent reply Herb Sutter <herb.sutter gmail.com> writes:
Walter Bright Wrote:

 Andrei Alexandrescu wrote:

 well pretty much what D does :o).


 
 I predict that C++ will adopt a lot more of D stuff.


FWIW, I (we?) had no idea that D did those things, so call it parallel
intelligent design rather than adoption. :-) Seriously, one of these days I'm
actually going to have to look more than briefly at D.

Herb
Mar 14 2010
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Herb Sutter wrote:

 Walter Bright Wrote:

 Andrei Alexandrescu wrote:

 well pretty much what D does :o).


 I predict that C++ will adopt a lot more of D stuff.


 
 FWIW, I (we?) had no idea that D did those things, so call it
 parallel intelligent design rather than adoption. :-) Seriously, one
 of these days I'm actually going to have to look more than briefly at
 D.


Hi Herb! It's hard to find anything truly original in language design, 
somebody somewhere always did something sorta like it first somewhere 
else. Most of D's features are inspired by features from a long list of 
languages, some alive, some dead.

It's like I read somewhere that nobody writes original music. It's all 
bits and pieces of other music in the brain of the composer that he 
heard somewhere else and just forgot where.

The magic is in the selection of which bits to include, and how they all 
fit together.

Here's a comparison I did of C++0x proposed features and D a while back. 
It's out of date and incomplete, but it's a reasonable overview:

http://www.digitalmars.com/d/2.0/cpp0x.html

I suppose I need to revisit it now that C++0x is nearing completion.
Mar 14 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:


 Here's a comparison I did of C++0x proposed features and D a while back. 
 It's out of date and incomplete, but it's a reasonable overview:
 http://www.digitalmars.com/d/2.0/cpp0x.html
 I suppose I need to revisit it now that C++0x is nearing completion.


In the past I didn't understand the section about Concepts of that page , now I
am understanding most of it, thanks to this very nice article that explains the
semantics and usefulness of concept maps:
http://www.devx.com/SpecialReports/Article/38864/1954?pf=true
This article has let me understand why concept maps are much more powerful (and
probably more useful) than D template Constraints.


General comment on the cpp0x.html page: C++/C++0x and Java are legacy languages
(but the most successful), so they can't be enough to design D. So I suggest to

solve some of the problems that need to be found D still...

Specific comments on that cpp0x.html page:


Concept maps: No (but could be done with proxy objects)<


I don't fully understand, I'd like to see a small example of this (it can be
added to that page too).



Axioms: Yes (as static asserts and function preconditions)<


This is a (too much) common example of axiom from Wikipedia:
http://en.wikipedia.org/wiki/Concepts_%28C%2B%2B%29#Axioms

concept Semigroup< typename Op, typename T> : CopyConstructible<T> {
  T operator()(Op, T, T);
 
  axiom Associativity(Op op, T x, T y, T z) {
    op(x, op(y, z)) == op(op(x, y), z);
  }
}

Function precoditions are currently used at run-time (a sufficiently smart
compiler can use some of them at compile time, but it's not easy). And static
asserts don't help a lot here.



All operations on constrained types must be specified in concept/constraint: No<


After reading that article on devx.com I think this can be a nice feature to
have in D too, because some times the lack of semantic analysis on
uninstantiated D templates unnerves me a little (while I think the other two
features like concept maps inheritance and the adaptors inside concept maps are
less important). But I am not sure how it can be implemented. If someone has
ideas I'd like to know them.


In D a template Constraints can contain the methods that must exist, as in a
C++0x Concept, I think this is the way to express it, using the methods inside
a __traits(compiles):


import std.stdio: writeln;

template IsPolygon(P) { // like a Concept
    enum bool IsPolygon = __traits(compiles, { int x = num_sides(P());
                                               auto d = side_len(P(), 0);
                                               typeof(d) r = 0;
                                               r += d;
                                             });
}

typeof(P.sides[0]) perimeter(P)(const ref P poly) if (IsPolygon!P) {
    typeof(return) sum = 0;
    foreach (i; 0 .. num_sides(poly))
        sum += side_len(poly, i);
    return sum;
}

// class Int { // problem!
struct Int {
    int x;
    void opOpAssign(string Op:"+=")(Int other) { this.x += other.x; }
    static Int opCall(int value) { Int i; i.x = value; return i; }
}

struct Triangle { Int[3] sides; }
int num_sides(const ref Triangle tri) { return Triangle.sides.length; }
typeof(Triangle.sides[0]) side_len(const ref Triangle tri, int index) { return
tri.sides[index]; }
static assert(IsPolygon!Triangle); // this makes sure Triangle is a polygon

void main() {
    Triangle t = Triangle([Int(10), Int(20), Int(30)]);
    auto p = perimeter(t);
    writeln(typeid(typeof(p)), " ", p);
}


There's no good way to let templates detect an operator missing in the concept,
like explained in that article.

A possible syntax can be to modify this:

typeof(P.sides[0]) perimeter(P)(const ref P poly) if (IsPolygon!P) {

Into a syntax that asks the compiler to perform the semantic tests even on the
uninstantiated template. Maybe something like:

typeof(P.sides[0]) perimeter(P)(const ref P poly) if
(__traits(satisfiesConcept, perimeter, IsPolygon)) {

Bye,
bearophile
Mar 15 2010
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
 typeof(P.sides[0]) perimeter(P)(const ref P poly) if
(__traits(satisfiesConcept, perimeter, IsPolygon)) {


That's silly because the if() is called only when the template is instantiated,
so this is a little better:

static assert(__traits(satisfiesConcept, perimeter, IsPolygon));

A problem left is that IsPolygon is not a list of things, currently it's a
nested piece of D code for __traits(compiles).

Bye,
bearophile
Mar 15 2010
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 03/15/2010 11:30 AM, bearophile wrote:

 Walter Bright:


 Here's a comparison I did of C++0x proposed features and D a while
 back. It's out of date and incomplete, but it's a reasonable
 overview: http://www.digitalmars.com/d/2.0/cpp0x.html I suppose I
 need to revisit it now that C++0x is nearing completion.


 In the past I didn't understand the section about Concepts of that
 page , now I am understanding most of it, thanks to this very nice
 article that explains the semantics and usefulness of concept maps:
 http://www.devx.com/SpecialReports/Article/38864/1954?pf=true This
 article has let me understand why concept maps are much more powerful
 (and probably more useful) than D template Constraints.


One man's trash may be another man's treasure, but I think it would be
unproductive to build from a feature that was analyzed at length and
then explicitly rejected by another language, at great cost. To effect
that, you'd have to understand the reasons that made concepts unsuitable
for C++0x and then work out ways to make concepts work for D.

Detecting mistaken use of concepts is practically very easy - just write 
a type that implements the concept vacuously and then instantiate the 
tested template against it in a unittest. I sometimes do that to test my 
range-based code.


Andrei
Mar 15 2010
prev sibling next sibling parent reply anton smith <nope donthave.com> writes:
bearophile Wrote:


 General comment on the cpp0x.html page: C++/C++0x and Java are legacy
languages (but the most successful), so they can't be enough to design D. So I

already solve some of the problems that need to be found D still...


Indeed, just observing C++/C++0x is a bit short-sighted. The C++ has never been
a great source of language innovation. Some other languages have learned from
the lessons with C++ and built something completely new. I'd also recommend all

really great (4.0 coming soon!) and even VB.Net nowadays comes with type
inference and lambdas. They certainly didn't get these ideas from C++03, C++98,
or C99.


features. Properties, delegates, strings in switches, extension methods etc.
Mar 15 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
anton smith wrote:

 bearophile Wrote:
 

 General comment on the cpp0x.html page: C++/C++0x and Java are legacy
languages (but the most
 successful), so they can't be enough to design D. So I suggest to try for few

 and Scala languages too, they probably already solve some of the problems that
need to be found
 D still...


 
 Indeed, just observing C++/C++0x is a bit short-sighted. The C++ has never
been a great source of
 language innovation.


No language other than D has implemented anywhere near the capability C++ has
with generic 
metaprogramming.




features.
 Properties, delegates, strings in switches, extension methods etc.
Mar 15 2010
parent BLS <windevguy hotmail.de> writes:
On 15/03/2010 22:26, Walter Bright wrote:

 anton smith wrote:

 bearophile Wrote:


 General comment on the cpp0x.html page: C++/C++0x and Java are legacy
 languages (but the most
 successful), so they can't be enough to design D. So I suggest to try

 and Scala languages too, they probably already solve some of the
 problems that need to be found
 D still...


 Indeed, just observing C++/C++0x is a bit short-sighted. The C++ has
 never been a great source of
 language innovation.


 No language other than D has implemented anywhere near the capability
 C++ has with generic metaprogramming.



 Probably 75% of D could have been invented by just improving C++ with

 Properties, delegates, strings in switches, extension methods etc.





that's true.


just wonder ..
Horse horse  = new Horse(); //really the end of wisdom ?

what the heck is that good for >
Horse horse = new Horse{);

Horse() horse; // should do the trick cause a horse is a horse is a 
horse of course

will finish the beer now and and have a sleep..
Mar 16 2010
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:


 you'd have to understand the reasons that made concepts unsuitable
 for C++0x and then work out ways to make concepts work for D.


I don't know exactly why they have refused Concepts, but to refuse them after
so many years of developments and discussions (and ConceptG++, many nice papers
written about their usage, etc) then they have good reasons. You are right,
better to not go there, even if it's seducing stuff.



 Detecting mistaken use of concepts is practically very easy - just write 
 a type that implements the concept vacuously and then instantiate the 
 tested template against it in a unittest. I sometimes do that to test my 
 range-based code.


Thank you for this interesting suggestion, I'll try it.
In the meantime I have found a Boost docs page about the same topic, I think
their 'archetype class' is the same thing you are saying me:
http://www.boost.org/doc/libs/1_42_0/libs/concept_check/concept_covering.htm

Bye,
bearophile
Mar 22 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 03/22/2010 02:09 PM, bearophile wrote:

 Andrei Alexandrescu:


 you'd have to understand the reasons that made concepts unsuitable
 for C++0x and then work out ways to make concepts work for D.


 I don't know exactly why they have refused Concepts, but to refuse
 them after so many years of developments and discussions (and
 ConceptG++, many nice papers written about their usage, etc) then
 they have good reasons. You are right, better to not go there, even
 if it's seducing stuff.


It's a long story. I think I'd summarize it by saying again: just like 
in chess, in PL design ignoring the whole for the beauty of the part is 
a capital mistake.


 Detecting mistaken use of concepts is practically very easy - just
 write a type that implements the concept vacuously and then
 instantiate the tested template against it in a unittest. I
 sometimes do that to test my range-based code.


 Thank you for this interesting suggestion, I'll try it. In the
 meantime I have found a Boost docs page about the same topic, I think
 their 'archetype class' is the same thing you are saying me:
 http://www.boost.org/doc/libs/1_42_0/libs/concept_check/concept_covering.htm


Yah, archetype-based checking was endorsed by Bjarne Stroustrup and 
myself (though my participation was negligible, so really I'm the only 
one claiming credit :o)). That proposal "lost" and concepts as 
ultimately proposed "won". If asked to speculate, I'd say that the other 
approach, if chosen, would have change the state of affairs dramatically.


Andrei
Mar 22 2010
prev sibling parent reply anton smith <nope donthave.com> writes:
Walter Bright Wrote:


 Hi Herb! It's hard to find anything truly original in language design, 
 somebody somewhere always did something sorta like it first somewhere 
 else. Most of D's features are inspired by features from a long list of 
 languages, some alive, some dead.


For some reason Oleg Kiselyov often finds original ideas in language design and
its usage.
Mar 15 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
anton smith wrote:

 Walter Bright Wrote:
 

 Hi Herb! It's hard to find anything truly original in language design, 
 somebody somewhere always did something sorta like it first somewhere 
 else. Most of D's features are inspired by features from a long list of 
 languages, some alive, some dead.


 
 For some reason Oleg Kiselyov often finds original ideas in language design
and its usage.


I don't know enough about Haskell to comment on that. But I do know that
there's 
a lot of grey area between an original idea and something similar that was done 
before. How different must it be before it is considered "original"?

That's one of the reasons the software patent system is busted.

There's a lot of patentable stuff in D (not just my ideas, but some ideas from 
others, too), but I've chosen not to attempt to patent them.
Mar 15 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hnm9ot$2og9$1 digitalmars.com...

 anton smith wrote:

 Walter Bright Wrote:


 Hi Herb! It's hard to find anything truly original in language design, 
 somebody somewhere always did something sorta like it first somewhere 
 else. Most of D's features are inspired by features from a long list of 
 languages, some alive, some dead.


 For some reason Oleg Kiselyov often finds original ideas in language 
 design and its usage.


 I don't know enough about Haskell to comment on that. But I do know that 
 there's a lot of grey area between an original idea and something similar 
 that was done before. How different must it be before it is considered 
 "original"?

 That's one of the reasons the software patent system is busted.

 There's a lot of patentable stuff in D (not just my ideas, but some ideas 
 from others, too), but I've chosen not to attempt to patent them.


To prove how bad the USPTO is, there was some guy that applied for a patent 
on a method of swinging on a swingset. It was approved. So under the current 
syetem, pretty much anything at all is patentable. A person could come up 
with patentable claim just by farting on a piece of paper.
Mar 15 2010
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Nick Sabalausky wrote:

 ...
 
 To prove how bad the USPTO is, there was some guy that applied for a patent 
 on a method of swinging on a swingset. It was approved. So under the current 
 syetem, pretty much anything at all is patentable. A person could come up 
 with patentable claim just by farting on a piece of paper. 


No, you can't, because (riffing on Apple) There's a Patent for That.
Mar 15 2010
prev sibling parent Brad Roberts <braddr puremagic.com> writes:
On 3/14/2010 7:05 PM, Herb Sutter wrote:

 Walter Bright Wrote:

 Andrei Alexandrescu wrote:

 well pretty much what D does :o).


 
 I predict that C++ will adopt a lot more of D stuff.


 
 FWIW, I (we?) had no idea that D did those things, so call it parallel
 intelligent design rather than adoption. :-) Seriously, one of these days I'm
 actually going to have to look more than briefly at D.
 
 Herb


I wonder what it'd take to get you, Walter, and Andrei in the same room for a
few hours..
Mar 14 2010
prev sibling parent =?windows-1252?Q?Pelle_M=E5nsson?= <pelle.mansson gmail.com> writes:
On 03/13/2010 09:53 PM, Andrei Alexandrescu wrote:

 Executive summary: C++0x will in all likelihood be C++11


Pretty sure you mean C++0xB.
Mar 14 2010