on Mon Apr 23 2007, Emerson <emerson.clarke-AT-gmail.com> wrote:

> Doug Gregor wrote:
>> There's nothing to "buy" with parametric polymorphism. It's a way of
>> expressing polymorphism, and it has various pros and cons relative to
>> subtype polymorphism, which is used by object-oriented languages, or F-
>> bounded polymorphism, which is used by the generics features of Java
>> and C#.
>
> I understand the idea behind the expression, i was really just trying
> to say that i don't equate templating with polymorphism in an OO
> sense.

Nor should you; it's different.  That said, the term "polymorphism"
wasn't invented for OO, so the idea of "parametric polymorphism"
shouldn't be judged in terms of "dynamic polymorphism" as some sort of
fundamental truth.

> Templates give you types which can be composed in many
> different ways, but this is far from the concept of OO polymorphism
> where derived types share a relationship.  Without notions like
> concepts in the C++0x standard templates dont really share any
> relationship with other templates.

Concepts as a notion exist in the C++98 standard.  They're just
realized as a language feature in C++0x.

Also, they don't establish relationships among templates, but among
types, such as int and long (each is Integral) and int* and
std::list<int>::iterator (each is a ForwardIterator).

> They can't be used as interfaces,

Depends what you mean by "used as interfaces"

> and they can't be passed as polymorhpic arguments (in the OO sense)
> except in other templates.

No, not templates (e.g. std::vector), but that's probably not what you
meant.  Class template specializations (e.g. std::vector<int>)
certainly can be passed as polymorphic arguments.

> There is a distinct boundary between templates and OO,
> it can be difficult to see and even harder to cross.

Not really; see Andrei Alexandrescu's "Modern C++ Design."  It's all
about applying templates to classic OO design patterns.

> It addresses many of the problems with the STL/Boost metaphor

I doubt you mean "metaphor" (metaphor for what?).  You probably meant
"paradigm," right?

Anyway, I wish you would stop using the "STL/Boost whatever" phrase.

STL has one main paradigm which predates Boost by many years.  Boost
is a collection of libraries with many paradigms, but of course since
STL is part of the standard library it's advantageous to use its
paradigms whenever possible.  The STL paradigm in no way belongs to
Boost.  Boost doesn't deserve credit for it, and also isn't hamstrung
by it.

> and the use of type traits.  Specifically, most STL and Boost
> templates use typedefs like value_type to get around the fact that
> the types are unknown.  Personally, i dont much like that.  I find
> it too opaque, which is why if you look in the Reason::Structure
> namespace of the framework which i wrote you will find that most
> collections return actual types

I don't see how your framework could be less opaque, especially when
the language used to describe it is so vague.  In what sense can
collections "return actual types?"  Generally, one can only return
objects, which themselves have type.

> which are always known i.e. Iterand<int> for any collection working
> with "int" and likewise iterators are always of some type

STL iterators are always "of some type" as well.  Every object in C++
has a type.

> and can be passed and constrained as arguments i.e.  Iterator<int>

That's a well-known approach (see boost/tr1::function).  It has some
advantages, but also has costs.  Buying wholesale into the use of
dynamic polymorphism will make some code prohibitively expensive.  The
brilliance of the STL is in the fact that it generalizes the domain of
sequence processing *without loss of efficiency*.

> But remember that concepts are fixing problems that exist with the STL/
> Boost metaphor.

What's your point?

> They will be very useful to other metaphors too so
> long as they are not constructed in a STL/Boost specific way.  When
> looking at examples like the "foreach" loop, things start to get a
> little bit too specific, especially if "foreach" is defined in terms
> of concepts which support begin() and end().  Thats blurring the lines
> between language and library...

Too late.  See std::typeinfo

> It can be quite difficult to conceptualise how the operator
> overloading used in STL/Boost is both a blessing and a curse.  Its a
> blessing becuase operators provide a way to effectively expression
> "anonymous" interfaces in C++.

As I mentioned earlier, operators have absolutely nothing to do with
it.  They're merely a different syntax for function calls.

> All types support operators,

Really? Hmm...

     struct x {};
     typedef void y;

> but you dont have to explicitly say that a type inherits from
> interfaces like "LessThanComparable", "GreaterThanComparable",
> "EqualsComparable".

What's your point?

> The curse is that in exchange for that magic

What magic?

> you have to trade all your knowledge of the type that you are
> working with and you can no longer easily integrate your templates
> with OO programming models.

Sorry, you lost me here.

> In the Reason framework i tried very hard to find an alternative which
> gave me better association with OO priciples, yet still had the
> anonymous power of the STL/Boost metaphor.
> The solution can be seen
> in the classes Template<Kind>, Type<Kind> and in interfaces like
> Comparable<Kind> and Disposable<Kind>.  In Reason there is no
> requirement for type traits, becuase types are transparent, likewise
> the code is simpler and more easily understood.

Or, looking at it differently, types are erased behind an opaque
barrier of dynamic polymorphism, costing the ability to perform
important optimizations, resulting in much larger code when used on
fine-grained concepts
(http://groups.google.com/group/comp.lang.c++.moderated/msg/82674634c2a6b3a0?hl=en&),
and ultimately requiring error-prone and complicated type switching to
handle the binary method problem.

There are upsides and downsides to every approach.

> Comparable<Kind> provides a mapping between the anonymous operators
> and OO interfaces like those provided by the Object class.  By
> avoiding heavy reliance on the STL/Boost operator metaphor, i was
> able to avoid some of the associated traps.  Even the templates that
> exist in Reason are very OO.  They are fundamentally inheritable
> becuase they are closer to being classes than they are to being
> generics.

You're conflating two very different things.  Classes are classes;
templates are templates.  Function templates have nothing to do with
classes.  Class templates, when instantiated, produce classes.
There's no way in which one class template can be "closer to being a
class" than another.

> Too me, polymorphism is too closely linked with the notion of
> inheritance

Much too closely.

>> C++ is a multi-paradigm language, and one of those paradigms is object-
>> oriented programming.
>
> Ok.  I think i was just trying to say that generic programming is a
> relatively new focus for the language though.

8 years since standardization (not to mention a few years before that)
is not all that new.

> Templates initially im sure were merely an advanced macro mechanism
> for avoiding code duplication.

Bjarne Stroustrup would tell you otherwise.

> And by the way, just becuase generic programming is popular with a
> subset of C++ users does not make it necessarily important.

True.  Generic programming is important because of what it can do.

> There has always been a tendancy for programmers to gravitate
> towards what is new and exciting, and even sometimes complicated.
> Im not sure i really understand the psychology, but non the less, it
> is a phenomenon.  And it goes without saying that sometimes creating
> simpler things is actually far more difficult than creating complex
> things.

This sounds a bit patronizing.  Do you suppose it's possible that this
happens just as often with OO as with GP?

> True generics, in an asbtract algorithmic sense is a software
> development holy grail.

See STL.  Have you ever read or listened to Stepanov's discussion of
his work?

> However i havnt found many examples where all my code needs to be
> generic.  Im sure there are examples where generic libraries truly
> benefit from being generic, but i think there are a lot of generic
> libraries which are only generic becuase the authors are stuck on
> the STL/Boost metaphor and cant get off it (see the comment above
> about carpenters and nails).

And I'm sure very little code "is OO" the authors are "stuck on the OO
metaphor and can't get off of it."

Do you think OO is a fundamentally good and proper paradigm, and thus
should be the basis for all programming without particular scrutiny,
while other paradigms are probably overused and require special
justification?

> This is probably partly due to knowledge, once you know a certain
> way of working it becomes easier for you, but also partly due to the
> fact that the STL/Boost metaphor is actually hard to break out of
> once you start using it because it does not easily blend back in
> with the more OO principles of C++.

There are no "OO principles of C++."  If you read D&E, you can find
exactly the principles upon which C++ was designed, and none of them
(IIRC) have anything to do with OO. In fact, if you talk to proponents
of some other languages they'll disparage C++ by claiming that it
"isn't truly an object-oriented language".

Furthermore, I challenge your claim (which you have so far made
repeatedly and without any justification) that generic programming
doesn't blend well with OO.

> Its kindof a shame to see a language like C++ diverge into class based
> programming and generic programming.  We should be trying to merge
> them back together i think, and hopefully concepts will go a long way
> towards doing this...

I don't see how.

> For me, the cost of abstraction in generic libraries like GIL (Generic
> Image Library) which i happened across the other day, outweigh the
> benefits.

I guess Adobe, which sponsored GIL's development, would strongly
disagree with you.  As I'm sure you can imagine, Adobe really needs
good image processing abstractions and the highest efficiency, so the
design of GIL was very intentionally chosen, and not just the product
of some sort of addiction to templates.

> I like to always see what im dealing with in my code, down to the
> point that i would rather use "char" than "typedef char byte"
> because abstractions make things harder to understand.

Then why do you use C++?  When you program in C++ you're operating at
a higher level of abstraction than you would if you were using 'C' or
assembly language.  Most people use C++ because it helps them express
complex ideas more simply, maintainably, and effectively than they
would be able to when working at a lower level of abstraction.

> Even Charles Symonyi (See NASA TV) would now agree that abstractions
> like the dreaded "hungarian" notation (which he helped to design)
> are no longer a good idea.

Except that hungarian notation isn't an abstraction.  It is, in fact,
the exact opposite: it breaks abstraction by binding a variable's
actual type into its name and thus exposing implementation details
where they don't belong.

> I think the efforts to make things like std::function and std::bind
> are admirable, but far from acceptable.  I still find it astonishing
> that C++ lets you do that kindof stuff, how many other languages out
> there have the same kindof loop holes and tricks ?

It's amazing that you're calling boost/tr1::function the product of
loopholes and tricks, considering that it seems to be, fundamentally,
exactly the same thing you're advocating with your "Reason" framework.

I also wonder what kind of loopholes and tricks you think are at play
with boost/tr1::bind.  C++ certainly has its share of tricky corners,
but AFAICT none of them are in play in the implementation of
that component.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

Don't Miss BoostCon 2007! ==> http://www.boostcon.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Mathias Gaunard wrote:
> On Apr 11, 4:41 pm, "Emerson" <emerson.cla...@gmail.com> wrote:
>
>> I just finished watching a Google tech talk presentation on concepts
>> in the upcoming C++0x standard and it left me wondering.
>
> Google is not really known for its modern usage of C++. To me it seems
> they use it "the old way".
>

That's "Google tech talk" as in "tech talk that's available on Google."
The talk is by Doug Gregor, who knows quite a bit about concepts.

--

 -- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Apr 11, 6:13 pm, "Douglas Gregor" <doug.gre...@gmail.com> wrote:
> I've worked with (and on) quite a few generic libraries, and I've
> found that the deeper I go into using the libraries, the more I need
> the flexibility that is there. I hypothesize that we haven't really
> seen the power of generic programming in this regard, because the
> current C++ template system has kept us from seeing all of the
> opportunities for reuse. Who would have thought that you could take a
> distributed-memory graph data structure from one library and use it
> for

. Oops, sorry: Who would have thought that you could take a
distributed-memory graph data structure from one library and plug it
into an independently-developed, sequential library for iterative
eigenvalue/eigenvector computations and have it "just work"? At the
theoretical level, it's been known that one can link the domains of
graph theory and linear algebra by viewing the edges in the graph as
elements in an adjacency matrix. The eigenvectors of that "matrix"
tell you something about connectivity in the graph. However, knowing
that at a theoretical level so rarely actually translates into being
able to link two *libraries*, each meant to support one of those
domains. However, since the library for eigenvalue/eigenvector
computations is a generic library, it was possible to realize this
theoretical link in software in a very elegant way.

Elegant, although this was done in pre-concept C++, so there were a
lot of template tricks to see through. With concepts, this link
becomes just another concept map, turning every model of the "Graph"
concept into a "Matrix", e.g.,

  template<Graph G> // if G is a Graph...
  concept_map Matrix<G> { // ... here is how to turn it into a Matrix
    typedef int value_type;

    int rows(G& g) { return g.num_vertices(); }
    int columns(G& g) { return g.num_vertices(): }

    int operator()(G& g, int row, int col) {
      // Turns the graph into a 0-1 adjacency matrix
      if (G.has_edge(row, col)) return 1;
      else return 0;
    }
  }

*This* is the essence of the generic programming style... mapping the
ideas from one library/domain (the Parallel Boost Graph Library, graph
theory, and the Graph concept) over to the ideas of another library/
domain (the Iterative Eigensolved Template Library, linear algebra,
and the Matrix concept), to get reuse across libraries and across
domains. With this concept map, I can now call any algorithm from the
linear algebra library that expects a Matrix, and give that algorithm
a Graph.

  Cheers,
  Doug

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Apr 12, 7:55 am, "Mathias Gaunard" <loufo...@gmail.com> wrote:

    [...]
> > I just finished watching a Google tech talk presentation on concepts
> > in the upcoming C++0x standard and it left me wondering.

> Google is not really known for its modern usage of C++. To me it seems
> they use it "the old way".

I wonder who did the tech talk.  I've never seen any of their
source code, to judge, but Google does employ some world class
C++ experts, including some of the top experts in generic
programming.  (Google is, of course, large enough that you can
probably find a little bit of everything somewhere in it.)

> >  The concepts
> > seem like a good idea, but it does concern me that such metaphore
> > specific notions are making it into the C++ language ahead of perhaps
> > more basic and useful features.

> Concepts, technically, aren't really needed. Similar functionality can
> already be achieved by the language as it is.
> The whole idea of concepts is to allow simpler code and simpler error
> messages.

I'm not sure that you can do everything, although most things
can be simulated.  Painfully, in some cases.

   [...]
> >  I think we should not forget that C++ was an object
> > oriented language well before generic programming came about

> That would be a very good thing to forget.
> The OO idiom in C++ is certainly not its good side.

The OO idiom in C++ works very well, thank you.  Better than in
some purported OO languages.  While it is certainly not the only
good side of C++, it's one of its good sides.

> Generations of developers thought C++ was an OO language, but they
> were simply coding in C with Classes. That's very far from the
> functionality modern C++ gives.

And many modern C++ programmers use OO techniques, very
effectively, when they are appropriate.  And other techniques,
when they aren't.

    [...]
> >  What about
> > closures and coroutines ?  Why do these ideas have to remain
> > "undefined" whilst we focus on much more esoteric problems.

> Closures can certainly be very well done in C++, thanks to
> overloading. It's called functors.

A closure is more than a functor.  A true closure affects the
lifetime of local variables, something I don't think that C++ is
likely to support anytime soon.

Co-routines, of course, are just very limited threading, and the
next version of C++ will almost certainly support threading.
(Many of us already use C++ in threaded code.)

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Emerson wrote:
> This is going to be a bit of a rant, but its only becuase im
> passionate about software and the state of the industry.  We seem to
> be ever more focused creating new and esoteric language features when
> we should be trying to find ways to combine all languages at some
> higher level and solve the fundamental problems of software
> development, algorithm reuse, and binary interoperability.
>
> I just finished watching a Google tech talk presentation on concepts
> in the upcoming C++0x standard and it left me wondering.  The concepts
> seem like a good idea, but it does concern me that such metaphore
> specific notions are making it into the C++ language ahead of perhaps
> more basic and useful features.
>
> The metaphore that i refer to is that off iterators.  Without
> iterators, STL would not be what it is.  Both STL and Boost are
> libraries which have been designed around a single idea, the use of C+
> + operators to provide non type specific generic algorithms and
> containers.  But it means that the algorithms and containers are
> restricted to things which behave like pointers.  C++ operators are
> convinient becuase they dont require you to specify types in the
> definition of your code and they support primitive types which you
> cannot do directly with interfaces, but it isnt very OO and no, i dont
> buy the notion of "parametric polymorphism".
>
> The boundary between the opaque and the visible for the user only
> occurs when they dereference an iterator, at this point the user must
> know the underlying type and the generic metaphore falls away to
> expose the details of the implementation.
>
> This is a clever workaround and it has allowed libraries like Boost
> and STL to flourish, but it is not the only way, and it has its
> drawbacks.  For instance, using the STL metaphore it is not possible
> to create a function which takes only an iterator of integers because
> there is no such thing as an iterator of integers, the underlying type
> is hidden.  Iterators deal only with operators, not with types or
> interfaces.  Its more like passing around macros, with all of the
> details being obscured.
>
> So the STL metaphore necessarily does not integrate well with the
> underlying C++ type system, and cannot be constrained by overloading
> or inheritance.  I think we should not forget that C++ was an object
> oriented language

And that was where I lost interest and stopped reading. The premise is
false. C++ was never an object oriented language. C++ was and is, a
language that provides support for OO programing alongside support for
several other paradigms.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Apr 12, 8:54 pm, "James Kanze" <james.ka...@gmail.com> wrote:

> A closure is more than a functor.  A true closure affects the
> lifetime of local variables, something I don't think that C++ is
> likely to support anytime soon.

It's simple: just use references.
In that case, though, the functor cannot be returned.

If you want both the ability to modify the local variables and the one
to return the functor, then of course the 'local' variable cannot live
on the stack, it must be on the freestore and either managed or
refcounted.

Another possibility would be an adapter that triggers 'conversion' of
the functor, from one that references the value to one that owns a
copy of it.


> Co-routines, of course, are just very limited threading

Not really. It's a different thing, which could advantageously replace
threading in some cases.
It's more like 'user-space' threading.


> and the
> next version of C++ will almost certainly support threading.

Yes, 'kernel-space' threading, with all the many thread-safety issues
it creates.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Francis Glassborow wrote:
> Emerson wrote:
>> snipped...
>> So the STL metaphore necessarily does not integrate well with the
>> underlying C++ type system, and cannot be constrained by overloading
>> or inheritance.  I think we should not forget that C++ was an object
>> oriented language
>
> And that was where I lost interest and stopped reading. The premise is
> false. C++ was never an object oriented language. C++ was and is, a
> language that provides support for OO programing alongside support for
> several other paradigms.

In general saying that something is 'x' does not preclude that it may
also be 'y' or 'z'. Now if one says that something is only 'x', whereas
it is also may be 'y' or 'z', that may be cause for a valid disagreement.

So I can not agree with your assertion that "C++ was never an object
oriented language" although I would of course agree with an assertion
that "C++ was never only an object oriented language".

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

> > I just finished watching a Google tech talk presentation on concepts
> > in the upcoming C++0x standard and it left me wondering.  The concepts
> > seem like a good idea, but it does concern me that such metaphore
> > specific notions are making it into the C++ language ahead of perhaps
> > more basic and useful features.
>
> Thanks for taking the time to watch the talk and air your concerns to
> the community.

Your welcome...

> There's nothing to "buy" with parametric polymorphism. It's a way of
> expressing polymorphism, and it has various pros and cons relative to
> subtype polymorphism, which is used by object-oriented languages, or F-
> bounded polymorphism, which is used by the generics features of Java
> and C#.

I understand the idea behind the expression, i was really just trying
to say that i don't equate templating with polymorphism in an OO
sense.  Templates give you types which can be composed in many
different ways, but this is far from the concept of OO polymorphism
where derived types share a relationship.  Without notions like
concepts in the C++0x standard templates dont really share any
relationship with other templates.  They can't be used as interfaces,
and they can't be passed as polymorhpic arguments (in the OO sense)
except in other templates.  There is a distinct boundary between
templates and OO, it can be difficult to see and even harder to cross.


> > The boundary between the opaque and the visible for the user only
> > occurs when they dereference an iterator, at this point the user must
> > know the underlying type and the generic metaphore falls away to
> > expose the details of the implementation.
>
> Not necessarily. When one dereferences an iterator whose type is
> unknown, you get back a value_type for that iterator. By default, you
> know nothing about that value_type, but the concept system allows you
> to place constraints on that value_type to say what it must be able to
> do. For example, you can say that it has a < operator allowing you to
> compare to values, or that it has + and = operators that allow you to
> add values and assign the result. For example, we could write a
> simplified binary search over arbitrary sequences like this:
> ...

Your example was very good, and i do like the concept system. It
addresses many of the problems with the STL/Boost metaphor and the use
of type traits.  Specifically, most STL and Boost templates use
typedefs like value_type to get around the fact that the types are
unknown.  Personally, i dont much like that.  I find it too opaque,
which is why if you look in the Reason::Structure namespace of the
framework which i wrote you will find that most collections return
actual types which are always known i.e. Iterand<int> for any
collection working with "int" and likewise iterators are always of
some type and can be passed and constrained as arguments i.e.
Iterator<int>

But remember that concepts are fixing problems that exist with the STL/
Boost metaphor.  They will be very useful to other metaphors too so
long as they are not constructed in a STL/Boost specific way.  When
looking at examples like the "foreach" loop, things start to get a
little bit too specific, especially if "foreach" is defined in terms
of concepts which support begin() and end().  Thats blurring the lines
between language and library...

It can be quite difficult to conceptualise how the operator
overloading used in STL/Boost is both a blessing and a curse.  Its a
blessing becuase operators provide a way to effectively expression
"anonymous" interfaces in C++.  All types support operators, but you
dont have to explicitly say that a type inherits from interfaces like
"LessThanComparable", "GreaterThanComparable", "EqualsComparable".
The curse is that in exchange for that magic you have to trade all
your knowledge of the type that you are working with and you can no
longer easily integrate your templates with OO programming models.  So
what you end up with is some very complicated and opaque code, with
lots of workarounds and messy business like type traits to try to
compensate.

You will note that the interfaces like "LessThanComparable" which i
mentioned above match pretty closely the kindof examples that are used
in the Google tech talk about concepts.  In a way its kindof pointing
to the fact that the STL/Boost metaphor has a flaw, and that in the
end we really need a way of expressing and verifying those constraints
and ideas in an "interface" like way.

In the Reason framework i tried very hard to find an alternative which
gave me better association with OO priciples, yet still had the
anonymous power of the STL/Boost metaphor.  The solution can be seen
in the classes Template<Kind>, Type<Kind> and in interfaces like
Comparable<Kind> and Disposable<Kind>.  In Reason there is no
requirement for type traits, becuase types are transparent, likewise
the code is simpler and more easily understood.  Comparable<Kind>
provides a mapping between the anonymous operators and OO interfaces
like those provided by the Object class.  By avoiding heavy reliance
on the STL/Boost operator metaphor, i was able to avoid some of the
associated traps.  Even the templates that exist in Reason are very
OO.  They are fundamentally inheritable becuase they are closer to
being classes than they are to being generics.

> > This is a clever workaround and it has allowed libraries like Boost
> > and STL to flourish, but it is not the only way, and it has its
> > drawbacks.  For instance, using the STL metaphore it is not possible
> > to create a function which takes only an iterator of integers because
> > there is no such thing as an iterator of integers, the underlying type
> > is hidden.
>
> This is possible. If you truly want to accept an InputIterator
> sequence for which the value_type is 'int', you can do so:
>
>   template<InputIterator Iter>
>   requires SameType<Iter::value_type, int>
>   void foo(Iter first, Iter last);

Yes, its possible with concepts, which i think is great.  But
unfortunately were all going to have to wait a while to get our hands
on that... :)


> Although in general one would probably want to take any Integral type,
> since C++ has so many to choose from:
>
>   template<InputIterator Iter>
>   requires Integral<Iter::value_type>
>   void foo(Iter first, Iter last);

How deep does the concept go here ?  Is an integral type just a type
which supports + and - or does it enforce rules of associativity and
other mathematical properties.  If it does then that is very exciting
indeed.  I think there was mention of this in the tech talk...

Ive used similar ideas to resolve dispitutes between polymorphic types
before, but in an OO only way.  There are rare cases when you have a
singly rooted object heirarchy but need to make sure that if A is
compared to B then it is always done in such a way that B.Compare(A)
is called instead of A.Compare(B).  This can be useful when sorting
lists of multiple types of items, a little like a priority queue.
Being able to enforce such requirements with concepts would be very
cool.


> >  Iterators deal only with operators, not with types or
> > interfaces.  Its more like passing around macros, with all of the
> > details being obscured.
>
> It is the essence of polymorphism to state which details are important
> to satisfy the contract between a polymorphic function and its inputs,
> then leave the rest of the details obscured. When writing an abstract
> base class, we do exactly the same thing:
>
>   class Drawable {
>   public:
>     virtual void draw() = 0;
>     virtual ~Drawable() { }
>   };
>
>   void draw_something(Drawable* d) {
>     // we know that *d derives from Drawable, but we know nothing else
> about it
>   }

I didnt quite follow that, were you implying that becuase STL/Boost
style iterators drop the unimportant details they are polymorphic ?

Too me, polymorphism is too closely linked with the notion of
inheritance and type. Without type there is a disconnect, its not so
much polymorphism as it is just anonymous abstraction.


> > So the STL metaphore necessarily does not integrate well with the
> > underlying C++ type system, and cannot be constrained by overloading
> > or inheritance.
>
> You're right that the STL metaphor does not integrate well with the
> underlying C++ type system *in today's template system*. Concepts
> rectify this problem, by allowing templates to interact with types in
> a natural way. Concept-based overloading, for example, allows one to
> overload templates based on their concept constraints, i.e., based on
> the properties of types. In the talk, the advance() example showed a
> simple case of concept-based overloading, where overloads of advance()
> differ based only on the kind of iterator passed to advance(). Because
> a template can only be used if the types it is given meet the concept
> constraints, constrained templates integrate tightly with the C++ type
> system: that's how we get full type-checking of templates, better
> error messages, etc.

Yes, i agree, thats a fantastic feature.  And im very pleased to hear
that template overloading based on polymorphic (OO) type is also
supported through the same mechanism.

> >  I think we should not forget that C++ was an object
> > oriented language well before generic programming came about and
> > perhaps some of the ideas which generic programming brings with it are
> > better suited to functional languages.
>
> C++ is a multi-paradigm language, and one of those paradigms is object-
> oriented programming.

Ok.  I think i was just trying to say that generic programming is a
relatively new focus for the language though.  Templates initially im
sure were merely an advanced macro mechanism for avoiding code
duplication.

And by the way, just becuase generic programming is popular with a
subset of C++ users does not make it necessarily important.  There has
always been a tendancy for programmers to gravitate towards what is
new and exciting, and even sometimes complicated.  Im not sure i
really understand the psychology, but non the less, it is a
phenomenon.  And it goes without saying that sometimes creating
simpler things is actually far more difficult than creating complex
things.

I do however accept the point that there are things which can be done
in generic programming which cant be done in functional languages, and
so it has its niche.  In fact i think its a little bit of a shame that
the C++0x standard is not more far reaching.  The concepts which are
flirted with in generic programming are actually quite close to the
ideas of domain specific languages, lisp, and intentional
programming.  True generics, in an asbtract algorithmic sense is a
software development holy grail.


> > Not that i have anything against generic programming.  Its very
> > useful, so long as you remember not to be the carpenter and treat
> > every problem as a nail.
>
> :)

See above :)


> > How many generic libraries actually need to
> > be generic beyond the 5 combinations of types that they actually use,
> > as opposed to collections which are truly generic.
>
> I've worked with (and on) quite a few generic libraries, and I've
> found that the deeper I go into using the libraries, the more I need
> the flexibility that is there. I hypothesize that we haven't really
> seen the power of generic programming in this regard, because the
> current C++ template system has kept us from seeing all of the
> opportunities for reuse. Who would have thought that you could take a
> distributed-memory graph data structure from one library and use it
> for

Agreed.

However i havnt found many examples where all my code needs to be
generic.  Im sure there are examples where generic libraries truly
benefit from being generic, but i think there are a lot of generic
libraries which are only generic becuase the authors are stuck on the
STL/Boost metaphor and cant get off it (see the comment above about
carpenters and nails).  This is probably partly due to knowledge, once
you know a certain way of working it becomes easier for you, but also
partly due to the fact that the STL/Boost metaphor is actually hard to
break out of once you start using it because it does not easily blend
back in with the more OO principles of C++.

Its kindof a shame to see a language like C++ diverge into class based
programming and generic programming.  We should be trying to merge
them back together i think, and hopefully concepts will go a long way
towards doing this...

For me, the cost of abstraction in generic libraries like GIL (Generic
Image Library) which i happened across the other day, outweigh the
benefits.  I like to always see what im dealing with in my code, down
to the point that i would rather use "char" than "typedef char byte"
because abstractions make things harder to understand.  Even Charles
Symonyi (See NASA TV) would now agree that abstractions like the
dreaded "hungarian" notation (which he helped to design) are no longer
a good idea.

> > Generic code is unfortunately opaque, and whilst it can be amazingly
> > useful, there is a high price to pay in terms or readability and
> > debugability.
>
> I agree with you 100%, if we're talking about today's C++ templates.
> To implement a generic library with today's templates requires a huge
> number of template tricks, all of which obscure the code and hide the
> intent of generic programming.
> The point of concepts is that they make it possible to write very
> readable, very maintainable, and very powerful generic code, by taking
> the ideas of generic programming and making them directly expressible
> in C++(0x). For the sake of learning concepts, it's best to look at
> them as a convenient extension to today's templates; for the sake of
> comparison with other features, it's better to view concepts and
> constrained templates as something completely different from today's C+
> + templates.

Im totally sold on concepts and i am glad that you agree thats there
is a problem with todays templates...

> > And how about standardising the representation of function pointers so
> > that we can write better even handling and callbacks.  What about
> > closures and coroutines ?  Why do these ideas have to remain
> > "undefined" whilst we focus on much more esoteric problems.
>
> As Richard also noted, std::function is a generalized function
> pointer. You can check out the Boost.Function library athttp://www.boost.org/doc/html/function.htmlto see how it works. Or,
> if you have GCC 4.1or Dinkumware's complete C++ Standard Library with
> TR1, std::tr1::function is the same thing.
>
> std::bind (adapted from Boost.Bind,http://www.boost.org/libs/bind/bind.html)
> provides one way to do closures, and lambdas are under discussion as a
> language feature.

Theres a huge difference between using some of the amazingly clever
hacks and tricks in Boost to having native language support for things
like function pointers and coroutines though.  For a start the syntax
would be a lot simpler, and there would be no where near so many hoops
to jump through or caveats and special cases to avoid.

I think the efforts to make things like std::function and std::bind
are admirable, but far from acceptable.  I still find it astonishing
that C++ lets you do that kindof stuff, how many other languages out
there have the same kindof loop holes and tricks ?  Makes me think
that either the initial standards were very loose, or the language is
far too complicated, or perhaps people are just extremely ingenious ?
Maybe a bit of everything :)

Emerson


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Apr 23, 2:23 pm, Emerson <emerson.cla...@gmail.com> wrote:
> But remember that concepts are fixing problems that exist with the STL/
> Boost metaphor.

That's a very narrow view of what concepts "are". Concepts support the
Generic Programming paradigm.

> They will be very useful to other metaphors too so
> long as they are not constructed in a STL/Boost specific way.  When
> looking at examples like the "foreach" loop, things start to get a
> little bit too specific, especially if "foreach" is defined in terms
> of concepts which support begin() and end().  Thats blurring the lines
> between language and library...

Is that a bad thing? I dare say that it's common practice in the OO
world, too, with Python using iterator protocols in its foreach loop
and C# using library-defined interfaces.

> It can be quite difficult to conceptualise how the operator
> overloading used in STL/Boost is both a blessing and a curse.  Its a
> blessing becuase operators provide a way to effectively expression
> "anonymous" interfaces in C++.

With concepts, they're concepts and they have names.

> All types support operators, but you
> dont have to explicitly say that a type inherits from interfaces like
> "LessThanComparable", "GreaterThanComparable", "EqualsComparable".

With concepts, we say that the type "models" a concept. If you want to
be explicit about this relationship, write a concept map.

> The curse is that in exchange for that magic you have to trade all
> your knowledge of the type that you are working with and you can no
> longer easily integrate your templates with OO programming models.  So
> what you end up with is some very complicated and opaque code, with
> lots of workarounds and messy business like type traits to try to
> compensate.

We're still talking about pre-concept C++, aren't we? *sigh* This mess
goes away with concepts.

> You will note that the interfaces like "LessThanComparable" which i
> mentioned above match pretty closely the kindof examples that are used
> in the Google tech talk about concepts.  In a way its kindof pointing
> to the fact that the STL/Boost metaphor has a flaw, and that in the
> end we really need a way of expressing and verifying those constraints
> and ideas in an "interface" like way.

Concepts and interfaces have a common kernel: they both express
abstractions and are used to implement polymorphic algorithms.

> In the Reason framework i tried very hard to find an alternative which
> gave me better association with OO priciples, yet still had the
> anonymous power of the STL/Boost metaphor.  The solution can be seen
> in the classes Template<Kind>, Type<Kind> and in interfaces like
> Comparable<Kind> and Disposable<Kind>.  In Reason there is no
> requirement for type traits, becuase types are transparent, likewise
> the code is simpler and more easily understood.  Comparable<Kind>
> provides a mapping between the anonymous operators and OO interfaces
> like those provided by the Object class.  By avoiding heavy reliance
> on the STL/Boost operator metaphor, i was able to avoid some of the
> associated traps.  Even the templates that exist in Reason are very
> OO.  They are fundamentally inheritable becuase they are closer to
> being classes than they are to being generics.

Reason is an OO library that adheres to OO principles. STL is a
generic library that adheres to GP principles. Both have their
trade-offs.

> Yes, its possible with concepts, which i think is great.  But
> unfortunately were all going to have to wait a while to get our hands
> on that... :)

Well, you can try ConceptGCC now---but industrial-strength
implementations of concepts are still several years away.

> > Although in general one would probably want to take any Integral type,
> > since C++ has so many to choose from:
>
> >   template<InputIterator Iter>
> >   requires Integral<Iter::value_type>
> >   void foo(Iter first, Iter last);
>
> How deep does the concept go here ?  Is an integral type just a type
> which supports + and - or does it enforce rules of associativity and
> other mathematical properties.  If it does then that is very exciting
> indeed.  I think there was mention of this in the tech talk...

The concept can express these mathemetical properties, and the
compiler is free to use or enforce them.

> I didnt quite follow that, were you implying that becuase STL/Boost
> style iterators drop the unimportant details they are polymorphic ?

The essence of polymorphism is that one can ignore unimportant
details, such as the specific name/layout/members/etc. of a type.

> Too me, polymorphism is too closely linked with the notion of
> inheritance and type. Without type there is a disconnect, its not so
> much polymorphism as it is just anonymous abstraction.

This is a very narrow view of polymorphism that is completely
out of line with the idea of polymorphism in the programming languages
community. The Wikipedia page on type polymorphism seems to give a
reasonable definition:

  http://en.wikipedia.org/wiki/Polymorphism_(computer_science)

> Theres a huge difference between using some of the amazingly clever
> hacks and tricks in Boost to having native language support for things
> like function pointers and coroutines though.  For a start the syntax
> would be a lot simpler, and there would be no where near so many hoops
> to jump through or caveats and special cases to avoid.

Have you used std::function (or its Boost predecessor)? I find that
it's syntax is as clean as any language feature would be. A quick
example:

  int square(int x) { return x*x; }

  function<int(int)> f = square;
  std::cout << f(3) << std::endl; // prints "9"

> I think the efforts to make things like std::function and std::bind
> are admirable, but far from acceptable.  I still find it astonishing
> that C++ lets you do that kindof stuff, how many other languages out
> there have the same kindof loop holes and tricks ?  Makes me think
> that either the initial standards were very loose, or the language is
> far too complicated, or perhaps people are just extremely ingenious ?
> Maybe a bit of everything :)

Lots of languages are getting operator overloading and "generics"; C++
just has more powerful variants of these features, and that is
completely intentional. The philosophy C++ has been that with a
powerful core language, users can write libraries that in turn make
the language more powerful. Why wait 5 years for C++ to get a
generalized function pointer in the language when you can write the
function template in a day and get all of that functionality
immediately? Why wait forever for C++ to get a niche language feature
for your specific domain (say, quaternions) when you can build that
functionality into a domain-specific library for yourself?

You've said that you want the C++0x standard to be more far-reaching,
but I think you've missed the point of C++: C++0x provides a lot of
features that make it easier to build great libraries. It's these
libraries that make C++ more far-reaching, because programmers that
really understand their domain---whether it is mathemetics, or
physics, or network apps, or whatever---will always build better
library abstractions than any language designer could build language
features.

  - Doug

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

This is going to be a bit of a rant, but its only becuase im
passionate about software and the state of the industry.  We seem to
be ever more focused creating new and esoteric language features when
we should be trying to find ways to combine all languages at some
higher level and solve the fundamental problems of software
development, algorithm reuse, and binary interoperability.

I just finished watching a Google tech talk presentation on concepts
in the upcoming C++0x standard and it left me wondering.  The concepts
seem like a good idea, but it does concern me that such metaphore
specific notions are making it into the C++ language ahead of perhaps
more basic and useful features.

The metaphore that i refer to is that off iterators.  Without
iterators, STL would not be what it is.  Both STL and Boost are
libraries which have been designed around a single idea, the use of C+
+ operators to provide non type specific generic algorithms and
containers.  But it means that the algorithms and containers are
restricted to things which behave like pointers.  C++ operators are
convinient becuase they dont require you to specify types in the
definition of your code and they support primitive types which you
cannot do directly with interfaces, but it isnt very OO and no, i dont
buy the notion of "parametric polymorphism".

The boundary between the opaque and the visible for the user only
occurs when they dereference an iterator, at this point the user must
know the underlying type and the generic metaphore falls away to
expose the details of the implementation.

This is a clever workaround and it has allowed libraries like Boost
and STL to flourish, but it is not the only way, and it has its
drawbacks.  For instance, using the STL metaphore it is not possible
to create a function which takes only an iterator of integers because
there is no such thing as an iterator of integers, the underlying type
is hidden.  Iterators deal only with operators, not with types or
interfaces.  Its more like passing around macros, with all of the
details being obscured.

So the STL metaphore necessarily does not integrate well with the
underlying C++ type system, and cannot be constrained by overloading
or inheritance.  I think we should not forget that C++ was an object
oriented language well before generic programming came about and
perhaps some of the ideas which generic programming brings with it are
better suited to functional languages.

Not that i have anything against generic programming.  Its very
useful, so long as you remember not to be the carpenter and treat
every problem as a nail.  How many generic libraries actually need to
be generic beyond the 5 combinations of types that they actually use,
as opposed to collections which are truly generic.  I mean, since when
does a Socket class benefit form being generic ?  ...ive seen loads of
those.

Generic code is unfortunately opaque, and whilst it can be amazingly
useful, there is a high price to pay in terms or readability and
debugability.

So before we take library specific ideas like begin() and end() and
start building for loops and concept maps around them and adding
support for requirements in generic code, can we pause and considder
the alternatives ?

What about ensuring that C++ templates can be overloaded by interfaces
rather than just concrete types ?

template<typename Kind>
class Compare
{
public:
    int Compare(Kind left, Kind right) {return left-right;}
}

template<typename Kind>
class Compare<Comparable Kind>
{
public:
    int Compare(Kind left, Kind right) {return left.Compare(right);}
}

Thats a pretty useful feature when your doing generic programming that
does not use the STL or Boost metaphore and it integrates tightly with
the more OO aspects of C++, overloading and inheritance.

And how about standardising the representation of function pointers so
that we can write better even handling and callbacks.  What about
closures and coroutines ?  Why do these ideas have to remain
"undefined" whilst we focus on much more esoteric problems.

For every generic programming feature in the C++0x standard, i fear
there will be 10 far more imporant and far more fundamental non
generic features which will be missed.  And for all this we have to
wait till the end of the decade.  Whoopy do !

If your interested in some concrete examples of the alternative
generic programming metaphores which are out there, check out the
structure's namespace from the C++ framework that i recently released
called Reason.

http://reasoning.info/

It frustrates me that so much of the code that we write has to be
thrown away, but atleast i can take pride in the fact that the code i
write is readable and understandable.  It can always be ported to
another language when C++ eventually digs a hole so deep we cant climb
out :(

Emerson

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Apr 11, 3:41 pm, "Emerson" <emerson.cla...@gmail.com> wrote:

> What about ensuring that C++ templates can be overloaded by interfaces
> rather than just concrete types ?
>
> template<typename Kind>
> class Compare
> {
> public:
>     int Compare(Kind left, Kind right) {return left-right;}
>
> }
>
> template<typename Kind>
> class Compare<Comparable Kind>
> {
> public:
>     int Compare(Kind left, Kind right) {return left.Compare(right);}
>
> }

Absolutely!  And if you turn to the concepts proposal (n2193), section
14.5.4, paragraph 9, you'll find this is already proposed.  Though the
word 'Comparable' is in the wrong place; it should be

  template<Comparable Kind>
  class Compare<Kind>
  { /*...*/ };

> And how about standardising the representation of function pointers so
> that we can write better even handling and callbacks.

Yep.  That one's called std::function and is already in the working
draft [n2135], section 20.5.14.

>  What about
> closures and coroutines ?  Why do these ideas have to remain
> "undefined" whilst we focus on much more esoteric problems.

Closures are in the lambda proposal [n1968].  I'm not sure what
exactly you mean by coroutine in the concept of C++ -- I assume you
don't just mean a multithreading with yielding between separate
threads (which is likely to be included in C++09).

> For every generic programming feature in the C++0x standard, i fear
> there will be 10 far more imporant and far more fundamental non
> generic features which will be missed.  And for all this we have to
> wait till the end of the decade.  Whoopy do !

The end of the decade isn't that long -- it's only 995 days until
2009-12-31!

--
Richard Smith

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

on Wed Apr 11 2007, "Emerson" <emerson.clarke-AT-gmail.com> wrote:

> I just finished watching a Google tech talk presentation on concepts
> in the upcoming C++0x standard and it left me wondering.  The
> concepts seem like a good idea, but it does concern me that such
> metaphore specific notions are making it into the C++ language ahead
> of perhaps more basic and useful features.
>
> The metaphore that i refer to is that off iterators.

Concepts are by no means specific to the iterator "metaphor."

> Without iterators, STL would not be what it is.  Both STL and Boost
> are libraries which have been designed around a single idea, the use
> of C++ operators to provide non type specific generic algorithms and
> containers.

Hmm, C++ operators really have little to do with Generic Programming;
they just happen to be a convenient and expressive syntactic
construct.  One could just as easily have implemented the STL so that
everything used function call notation, and it wouldn't have changed
the fundamental concepts.  So, no, STL isn't designed around that
idea.

Boost (not one library, but a library collection) certainly has many
libraries that have Generic Programming at their core, but also has
several that are not at all oriented toward GP in the classic sense.

> But it means that the algorithms and containers are restricted to
> things which behave like pointers.

It means the algorithsm are restricted operating on things that are
*syntactically* pointer-like, but the behavior can be decidedly
un-pointer-like.

> C++ operators are convinient becuase they dont require you to
> specify types in the definition of your code

Huh?  Maybe when you say "operators" you really mean "templates."

> and they support primitive types

Certainly you can support primitive types with overloaded functions
just as well.

     template <class T>
     void some_algo(T x, T y)
     {
          foo(x + y);  // requires "+" be overloaded for T
                       // when T is user-defined
     }

     template <class T>
     void some_algo2(T x, T y)
     {
          foo(add(x,y));  // requires "add" be overloaded for T always.
     }

> which you cannot do directly with interfaces, but it isnt very OO

Well, you're not going to find a lot of sympathy here for the notion
that being "very OO" is always a good thing.  Classic OO is good for
some things, but there are a *lot* of jobs to which it is extremely
ill-suited.  Just for fun you might look up the "binary method
problem," which OO can't handle without resorting to runtime type
checking.

> and no, i dont buy the notion of "parametric polymorphism".

Care to say any more about that, or are you just hanging it out there
like a flag?

> The boundary between the opaque and the visible for the user only
> occurs when they dereference an iterator, at this point the user must
> know the underlying type and the generic metaphore falls away to
> expose the details of the implementation.

Huh? No part of that made sense to me.  Maybe you should try using a
specific example that shows what you mean.

> This is a clever workaround

For what problem?

> and it has allowed libraries like Boost and STL to flourish, but it
> is not the only way, and it has its drawbacks.  For instance, using
> the STL metaphore it is not possible to create a function which
> takes only an iterator of integers because there is no such thing as
> an iterator of integers,

If you mean an "iterator over integers," then of course there is such
a thing. int* is a perfect example.  And if your real complaint is
that there is no way for the author of that function to write it so
that its declaration limits the arguments to being iterators over
integers, then that's wrong too.  You can do it in an ugly way in C++
today; making such a specification a first-class idiom is one of the
main points of having language support for concepts in C++0x.

> the underlying type is hidden.

Underlying type of what?

> Iterators deal only with operators, not with types or interfaces.

Iterators certainly deal with types.  See value_type, reference,
pointer, ...

> Its more like passing around macros, with all of the details being
> obscured.

Huh?

> So the STL metaphore necessarily does not integrate well with the
> underlying C++ type system,

I disagree with that 200%.

> and cannot be constrained by overloading or inheritance.

It certainly can be.  That would be bad design and needlessly
limiting, but you can do it.

> I think we should not forget that C++ was an object oriented
> language well before generic programming came about

It was a multiparadigm language (and even had templates) well before
generic programming came about.

> and perhaps some of the ideas which generic programming brings with
> it are better suited to functional languages.

Stepanov tried the functional languages and they all failed to express
what he was trying to do.

> Not that i have anything against generic programming.  Its very
> useful, so long as you remember not to be the carpenter and treat
> every problem as a nail.  How many generic libraries actually need
> to be generic beyond the 5 combinations of types that they actually
> use,

Well, that's a "when did you stop beating your wife?" sort of
question, innit?

> as opposed to collections which are truly generic.  I mean, since
> when does a Socket class benefit form being generic ?  ...ive seen
> loads of those.

Maybe you should read the docs and rationale here:
http://asio.sourceforge.net/boost-asio-proposal-0.3.6/libs/asio/doc/
and if that doesn't answer your question, ask its author, Christopher
Kohlhoff.

>
> Generic code is unfortunately opaque,

Any coding idiom will look somewhat opaque to those unfamiliar with
it.  It's not an absolute.

> and whilst it can be amazingly useful, there is a high price to pay
> in terms or readability and debugability.

Generic code is no harder to debug than anything else.

> So before we take library specific ideas like begin() and end() and
> start building for loops and concept maps around them and adding
> support for requirements in generic code, can we pause and considder
> the alternatives ?
>
> What about ensuring that C++ templates can be overloaded by interfaces
> rather than just concrete types ?
>
> template<typename Kind>
> class Compare
> {
> public:
>     int Compare(Kind left, Kind right) {return left-right;}
> }
>
> template<typename Kind>
> class Compare<Comparable Kind>
> {
> public:
>     int Compare(Kind left, Kind right) {return left.Compare(right);}
> }

You can "already" do that in C++0x.  I don't see how it's an alternative to
adding support for requirements in generic code.  In fact it seems to
rely on that support.

> Thats a pretty useful feature when your doing generic programming that
> does not use the STL or Boost metaphore and it integrates tightly with
> the more OO aspects of C++, overloading and inheritance.

The STL already integrates pretty well with OO code; go ahead and do
the above when you get concept support; it should work just fine.

> And how about standardising the representation of function pointers

Not a chance; that's an issue for the platform vendors who specify
their standard ABIs.

> so that we can write better even handling and callbacks.

I don't see how that would help.

> What about closures and coroutines ?  Why do these ideas have to
> remain "undefined" whilst we focus on much more esoteric problems.

The glib non-answer is: where were your proposals and proof-of-concept
implementations for those features when some people on the committee
started working on concept support?

To answer a _little_ bit, C++0x will have support for concurrency and
probably for GC.  GC is a prerequisite for true closures so we're
making progress in that direction.  It's interesting that you're
asking about these features normally associated with functional
programming while suggesting that C++ should be "more OO" and GP
should be in the domain of functional languages.

> For every generic programming feature in the C++0x standard, i fear
> there will be 10 far more imporant and far more fundamental non
> generic features which will be missed.  And for all this we have to
> wait till the end of the decade.  Whoopy do !

Join the committee and do the hard work if you aren't happy with the
direction.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

Don't Miss BoostCon 2007! ==> http://www.boostcon.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Apr 11, 10:41 am, "Emerson" <emerson.cla...@gmail.com> wrote:
> I just finished watching a Google tech talk presentation on concepts
> in the upcoming C++0x standard and it left me wondering.  The concepts
> seem like a good idea, but it does concern me that such metaphore
> specific notions are making it into the C++ language ahead of perhaps
> more basic and useful features.

Thanks for taking the time to watch the talk and air your concerns to
the community.

> The metaphore that i refer to is that off iterators.  Without
> iterators, STL would not be what it is.  Both STL and Boost are
> libraries which have been designed around a single idea, the use of C+
> + operators to provide non type specific generic algorithms and
> containers.  But it means that the algorithms and containers are
> restricted to things which behave like pointers.  C++ operators are
> convinient becuase they dont require you to specify types in the
> definition of your code and they support primitive types which you
> cannot do directly with interfaces, but it isnt very OO and no, i dont
> buy the notion of "parametric polymorphism".

There's nothing to "buy" with parametric polymorphism. It's a way of
expressing polymorphism, and it has various pros and cons relative to
subtype polymorphism, which is used by object-oriented languages, or F-
bounded polymorphism, which is used by the generics features of Java
and C#.

> The boundary between the opaque and the visible for the user only
> occurs when they dereference an iterator, at this point the user must
> know the underlying type and the generic metaphore falls away to
> expose the details of the implementation.

Not necessarily. When one dereferences an iterator whose type is
unknown, you get back a value_type for that iterator. By default, you
know nothing about that value_type, but the concept system allows you
to place constraints on that value_type to say what it must be able to
do. For example, you can say that it has a < operator allowing you to
compare to values, or that it has + and = operators that allow you to
add values and assign the result. For example, we could write a
simplified binary search over arbitrary sequences like this:

  template<RandomAccessIterator Iter>
  requires LessThanComparable<Iter::value_type>
  bool binary_search(Iter first, Iter last, Iter::value_type const&
value) {
    Iter mid = first + (last - first) / 2;
    if (*first < *mid) {  // okay: we know that Iter::value_type, the
type returned when derferencing an iterator has a < operator
      // ...
    } else {
      // ...
    }
  }

> This is a clever workaround and it has allowed libraries like Boost
> and STL to flourish, but it is not the only way, and it has its
> drawbacks.  For instance, using the STL metaphore it is not possible
> to create a function which takes only an iterator of integers because
> there is no such thing as an iterator of integers, the underlying type
> is hidden.

This is possible. If you truly want to accept an InputIterator
sequence for which the value_type is 'int', you can do so:

  template<InputIterator Iter>
  requires SameType<Iter::value_type, int>
  void foo(Iter first, Iter last);

Although in general one would probably want to take any Integral type,
since C++ has so many to choose from:

  template<InputIterator Iter>
  requires Integral<Iter::value_type>
  void foo(Iter first, Iter last);

>  Iterators deal only with operators, not with types or
> interfaces.  Its more like passing around macros, with all of the
> details being obscured.

It is the essence of polymorphism to state which details are important
to satisfy the contract between a polymorphic function and its inputs,
then leave the rest of the details obscured. When writing an abstract
base class, we do exactly the same thing:

  class Drawable {
  public:
    virtual void draw() = 0;
    virtual ~Drawable() { }
  };

  void draw_something(Drawable* d) {
    // we know that *d derives from Drawable, but we know nothing else
about it
  }

> So the STL metaphore necessarily does not integrate well with the
> underlying C++ type system, and cannot be constrained by overloading
> or inheritance.

You're right that the STL metaphor does not integrate well with the
underlying C++ type system *in today's template system*. Concepts
rectify this problem, by allowing templates to interact with types in
a natural way. Concept-based overloading, for example, allows one to
overload templates based on their concept constraints, i.e., based on
the properties of types. In the talk, the advance() example showed a
simple case of concept-based overloading, where overloads of advance()
differ based only on the kind of iterator passed to advance(). Because
a template can only be used if the types it is given meet the concept
constraints, constrained templates integrate tightly with the C++ type
system: that's how we get full type-checking of templates, better
error messages, etc.

>  I think we should not forget that C++ was an object
> oriented language well before generic programming came about and
> perhaps some of the ideas which generic programming brings with it are
> better suited to functional languages.

C++ is a multi-paradigm language, and one of those paradigms is object-
oriented programming.

> Not that i have anything against generic programming.  Its very
> useful, so long as you remember not to be the carpenter and treat
> every problem as a nail.

:)

> How many generic libraries actually need to
> be generic beyond the 5 combinations of types that they actually use,
> as opposed to collections which are truly generic.

I've worked with (and on) quite a few generic libraries, and I've
found that the deeper I go into using the libraries, the more I need
the flexibility that is there. I hypothesize that we haven't really
seen the power of generic programming in this regard, because the
current C++ template system has kept us from seeing all of the
opportunities for reuse. Who would have thought that you could take a
distributed-memory graph data structure from one library and use it
for

> Generic code is unfortunately opaque, and whilst it can be amazingly
> useful, there is a high price to pay in terms or readability and
> debugability.

I agree with you 100%, if we're talking about today's C++ templates.
To implement a generic library with today's templates requires a huge
number of template tricks, all of which obscure the code and hide the
intent of generic programming.
The point of concepts is that they make it possible to write very
readable, very maintainable, and very powerful generic code, by taking
the ideas of generic programming and making them directly expressible
in C++(0x). For the sake of learning concepts, it's best to look at
them as a convenient extension to today's templates; for the sake of
comparison with other features, it's better to view concepts and
constrained templates as something completely different from today's C+
+ templates.

> What about ensuring that C++ templates can be overloaded by interfaces
> rather than just concrete types ?
>
> template<typename Kind>
> class Compare
> {
> public:
>     int Compare(Kind left, Kind right) {return left-right;}
>
> }
>
> template<typename Kind>
> class Compare<Comparable Kind>
> {
> public:
>     int Compare(Kind left, Kind right) {return left.Compare(right);}
>
> }

As Richard Smith points out, you can do this with concepts with a
minor change to the syntax of your code above. The same mechanisms
that make concept-based overloading work (e.g., for "advance") make it
possible to write different partial specializations with different
concept requirements.

> And how about standardising the representation of function pointers so
> that we can write better even handling and callbacks.  What about
> closures and coroutines ?  Why do these ideas have to remain
> "undefined" whilst we focus on much more esoteric problems.

As Richard also noted, std::function is a generalized function
pointer. You can check out the Boost.Function library at
http://www.boost.org/doc/html/function.html to see how it works. Or,
if you have GCC 4.1or Dinkumware's complete C++ Standard Library with
TR1, std::tr1::function is the same thing.

std::bind (adapted from Boost.Bind, http://www.boost.org/libs/bind/bind.html)
provides one way to do closures, and lambdas are under discussion as a
language feature.

  Cheers,
  Doug

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

* David Abrahams:
>
> Join the committee and do the hard work if you aren't happy with the
> direction.

For most people that simply isn't an option.  E.g., even though there is
(or at least was) an organization in Norway committed to paying the
cost, as far as I know we don't have a voting membership.  Of course it
would no problem for e.g. Bill Gates, with lots of spare time, a
substantial fortune, and living in the "right" country.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

David Abrahams wrote:
> on Wed Apr 11 2007, "Emerson" <emerson.clarke-AT-gmail.com> wrote:
>
>>and it has allowed libraries like Boost and STL to flourish, but it
>>is not the only way, and it has its drawbacks.  For instance, using
>>the STL metaphore it is not possible to create a function which
>>takes only an iterator of integers because there is no such thing as
>>an iterator of integers,
>
>
> If you mean an "iterator over integers," then of course there is such
> a thing. int* is a perfect example.

Oh, I had assumed the OP meant a "polymorphic iterator wrapper" for
iterators over integers, in the same way that function<int (int, int)>
is a "polymorphic function wrapper" for functions with the given
signature.

And, of course, you can implement such a iterator wrapper that gives
(say) vector<int>::iterator and int* the same type.  (Well, you nearly
can: there's the standard binary method issue with operator==, which can
  give problems when comparing const_iterators with non-const iterators.)

--
Richard Smith

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

on Wed Apr 11 2007, alfps-AT-start.no ("Alf P. Steinbach") wrote:

> * David Abrahams:
>>
>> Join the committee and do the hard work if you aren't happy with
>> the direction.
>
> For most people that simply isn't an option.

I don't believe it.

> E.g., even though there is (or at least was) an organization in
> Norway committed to paying the cost, as far as I know we don't have
> a voting membership.

Having a voting membership means almost nothing in terms of your
ability to participate and make a difference.  Even people who were
technically non-members have attended meetings and brought forward
proposals that have been accepted (me among them; I have since joined
and pay a yearly fee), and even non-members can vote in the "straw
polls" that count more than anything else in terms of actually moving
stuff through the process.  The voting part you pay for is supposed to
be (and usually is) a formality that near-unanimously acknowledges the
consensus that we've all already worked to form.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

Don't Miss BoostCon 2007! ==> http://www.boostcon.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Apr 11, 4:41 pm, "Emerson" <emerson.cla...@gmail.com> wrote:
> This is going to be a bit of a rant, but its only becuase im
> passionate about software and the state of the industry.  We seem to
> be ever more focused creating new and esoteric language features when
> we should be trying to find ways to combine all languages at some
> higher level and solve the fundamental problems of software
> development, algorithm reuse, and binary interoperability.

Actually, templates are certainly the most interesting and novative
aspect of C++.
The fact that it is given more work than other 'problems' is proof
that more people are simply more interested with it.


> I just finished watching a Google tech talk presentation on concepts
> in the upcoming C++0x standard and it left me wondering.

Google is not really known for its modern usage of C++. To me it seems
they use it "the old way".


>  The concepts
> seem like a good idea, but it does concern me that such metaphore
> specific notions are making it into the C++ language ahead of perhaps
> more basic and useful features.

Concepts, technically, aren't really needed. Similar functionality can
already be achieved by the language as it is.
The whole idea of concepts is to allow simpler code and simpler error
messages.


> The metaphore that i refer to is that off iterators.  Without
> iterators, STL would not be what it is.  Both STL and Boost are
> libraries which have been designed around a single idea, the use of C+
> + operators to provide non type specific generic algorithms and
> containers.

I certainly wouldn't say that. Especially for boost, which contains
various different things.
The aim STL, as it names says, is to provide templates for data
structures and related algorithms.
I don't see the relation with operators.

"non type specific" is a weird expression, and makes me thing you
misunderstand templates.
With templates, everything is type specific, it's just that it can be
generated for any type. It's not obfuscation.


>  But it means that the algorithms and containers are
> restricted to things which behave like pointers.

Huh? I fail to see the relation.
Are you talking about the fact that the iterator design is purposedly
modeled after pointers?
That's just a question of style, it could have used next(), etc.


>  C++ operators are
> convinient becuase they dont require you to specify types in the
> definition of your code

You always need to specify the type of the variable in C++.
(There will be type inference in C++0x though)


> and they support primitive types which you
> cannot do directly with interfaces, but it isnt very OO

Templates are just what they are, templates. A calibre of a class of
function, that you can instantiate with types or integers to generate
the given class or function.
They have no relation with OO. Which is a good thing, by the way. With
OO and subtyping polymorphism the real type of objects is not known
until runtime, while templates work at compile-time and can use
inference to instantiate themselves in the case of template functions.

> and no, i dont
> buy the notion of "parametric polymorphism".

It's not whether you buy it or not.
It's a notion that exists, and is heavily demonstrated by statically
typed functional languages such as ML.

Templates offer that kind of functionality for C++.


> The boundary between the opaque and the visible for the user only
> occurs when they dereference an iterator, at this point the user must
> know the underlying type and the generic metaphore falls away to
> expose the details of the implementation.

If you don't know the types of your variables, maybe you shouldn't use
them in the first place.
The type of your iterator contains all the necessary information to
know the type of the derefenced element.


> This is a clever workaround

It's not especially new or clever.


> and it has allowed libraries like Boost
> and STL to flourish, but it is not the only way, and it has its
> drawbacks.

The only drawback it that, since it happens at compile-time, it can't
be dynamic.


> For instance, using the STL metaphore it is not possible
> to create a function which takes only an iterator of integers because
> there is no such thing as an iterator of integers, the underlying type
> is hidden.

That's absolutely false.
The iterator type contains the information of the type it iterates.
While such an information wouldn't be in the type using an OO design,
it is with templates.

Writing such a function can be done with SFINAE, which becomes easy
using tools from boost :

template<typename It>
typename enable_if<
    is_same<It::value_type, int>,
void>::type
some_function(It it);


> Iterators deal only with operators, not with types or
> interfaces.  Its more like passing around macros, with all of the
> details being obscured.

There is nothing obscure.
All information is in the type.


> So the STL metaphore necessarily does not integrate well with the
> underlying C++ type system

It integrates very well. So well that people are still amazed by
things you can do with it.


> and cannot be constrained by overloading

They can, using SFINAE.


> or inheritance.

Templates apply on types. Inheritance is a special propriety of a
specific category of types.
They're of course not related.


>  I think we should not forget that C++ was an object
> oriented language well before generic programming came about

That would be a very good thing to forget.
The OO idiom in C++ is certainly not its good side.

Generations of developers thought C++ was an OO language, but they
were simply coding in C with Classes. That's very far from the
functionality modern C++ gives.


> and
> perhaps some of the ideas which generic programming brings with it are
> better suited to functional languages.

There is nothing especially functional in genericity.
And C++ can handle the functional idiom quite well.


> Generic code is unfortunately opaque, and whilst it can be amazingly
> useful, there is a high price to pay in terms or readability and
> debugability.

It's not more opaque and non generic code.
Actually, it is often clearer, since it is generic and not specific to
some kind of type.


> So before we take library specific ideas like begin() and end() and
> start building for loops and concept maps around them and adding
> support for requirements in generic code, can we pause and considder
> the alternatives ?

Looks like you don't understand concept maps.

>
> What about ensuring that C++ templates can be overloaded by interfaces
> rather than just concrete types ?
>
> template<typename Kind>
> class Compare
> {
> public:
>     int Compare(Kind left, Kind right) {return left-right;}
>
> }

Here, you could just write your comparison as left < right, and if
operator<(decltype(left), decltype(right)) is not found, you get a
compile-time error.

>
> template<typename Kind>
> class Compare<Comparable Kind>
> {
> public:
>     int Compare(Kind left, Kind right) {return left.Compare(right);}
>
> }
>
> Thats a pretty useful feature when your doing generic programming

That's concepts.
They're doable using library techniques as of today, and are being
included in the next standard to be simpler.


> that
> does not use the STL or Boost metaphore

It *is* the STL metaphore.
For example, to instantiate std::set with a type, that type must
satisfy the requirement of comparable.


> and it integrates tightly with
> the more OO aspects of C++, overloading and inheritance.

I fail to see the OO integration.


> And how about standardising the representation of function pointers so
> that we can write better even handling and callbacks.

I don't see how standardizing the representation of function pointers
would help for callbacks.


>  What about
> closures and coroutines ?  Why do these ideas have to remain
> "undefined" whilst we focus on much more esoteric problems.

Closures can certainly be very well done in C++, thanks to
overloading. It's called functors.

This is already highly used by the STL, by the way. Be it to indicate
how comparison is to be done or what code to apply with an algorithm
(for_each, transform, etc.)

Functors are usually used through templates, but you can also use them
through subtyping polymorphism, in case you need a single type (to
store the thing, eventually). Of course, the later introduces some
overhead.
For that there is an utility in boost and TR1 to unify all functors
with the same signature to a single type, it's called boost::function.

It could be implemented like this, but actually it uses other tricks
for efficiency.
Here is how for a function taking no argument. For other cases, the
template will have to be "overloaded". Usage of variadic templates (a
new C++0x feature) could also be considered.

template<typename R>
struct base
{
    virtual R operator()() = 0;
};

template<typename R, typename F>
struct derived : base<R>
{
    derived(const F& f)
    {
        f_ = f;
    }

    R operator()()
    {
        return f_();
    }

    F f_;
};

template<typename R>
class function
{
public:

    template<typename F>
    function(const F& f)
    {
        p_ = new derived<R, F>(f);
    }

    ~function()
    {
        delete p_;
    }

    R operator()()
    {
        return (*p_)();
    }

    /* additional stuff */

private:
    base<R>* p_;
};

Notice how templates and inheritance can be used together to create
that kind of generic, yet runtime-oriented, component.


> For every generic programming feature in the C++0x standard, i fear
> there will be 10 far more imporant and far more fundamental non
> generic features which will be missed.  And for all this we have to
> wait till the end of the decade.  Whoopy do !

Templates are one of the key features of C++, more important than
subtyping polymorphism, which can simply be done by hand with function
pointers anyway.

The only point where templates don't integrate well is with
virtuality, because that would mean the vtable can't be generated
until link-time. That's kinda problematic given the translation model
of C++.
That's too bad actually, that would allow very interesting things.


> If your interested in some concrete examples of the alternative
> generic programming metaphores which are out there, check out the
> structure's namespace from the C++ framework that i recently released
> called Reason.
>
> http://reasoning.info/

When reading your work it seems your definition of OO varies.
I was assuming you meant subtyping polymorphism, but actually
sometimes it seems you're just talking about the idea of object based
programming, grouping state data in objects and attaching member
functions to them.
So basically, your reproach that STL is not OO is based on the fact
that to advance an iterator, you have to do ++it and not it.next() ?


> It frustrates me that so much of the code that we write has to be
> thrown away, but atleast i can take pride in the fact that the code i
> write is readable and understandable.  It can always be ported to
> another language when C++ eventually digs a hole so deep we cant climb
> out :(

That's not gonna happen, only C++ has this awesome feature called
templates. ;)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Apr 11, 11:31 pm, a...@start.no ("Alf P. Steinbach") wrote:
> * David Abrahams:

> > Join the committee and do the hard work if you aren't happy with the
> > direction.

> For most people that simply isn't an option.  E.g., even though there is
> (or at least was) an organization in Norway committed to paying the
> cost, as far as I know we don't have a voting membership.  Of course it
> would no problem for e.g. Bill Gates, with lots of spare time, a
> substantial fortune, and living in the "right" country.

There are generally ways; there is no rule in ISO that forbids
national bodies from accrediting technical experts who are not
of their nationality, or who don't live in the country.  When
DIN faced a similar problem (financial support dried up), BSN
actually offered to accredit all of the DIN members.  And ANSI
will accredit anyone who pays the dues, and whose employer is
not a member.  (The last time I looked, the ANSI dues weren't
that bad.  For a professional consultant, anyway---I'm sure that
they would have caused serious hardship for a student.)

So if Norway doesn't have a voting membership, and for whatever
reasons doesn't want to get one, shop around.  Obviously, most
national bodies probably don't want just anyone.  But given the
level of expertise you show in the newsgroups, I rather think
you should have no trouble finding a national body to sponser
you.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

on Thu Apr 12 2007, "Mathias Gaunard" <loufoque-AT-gmail.com> wrote:

>> I just finished watching a Google tech talk presentation on concepts
>> in the upcoming C++0x standard and it left me wondering.
>
> Google is not really known for its modern usage of C++. To me it seems
> they use it "the old way".

The talk
(http://video.google.com/videoplay?docid=-1790714981047186825) was by
Doug Gregor, one of the main people behind concept support for C++0x.
I strongly recommend you check it out.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

Don't Miss BoostCon 2007! ==> http://www.boostcon.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

on Thu Apr 12 2007, "James Kanze" <james.kanze-AT-gmail.com> wrote:

> So if Norway doesn't have a voting membership, and for whatever
> reasons doesn't want to get one, shop around.  Obviously, most
> national bodies probably don't want just anyone.  But given the
> level of expertise you show in the newsgroups, I rather think
> you should have no trouble finding a national body to sponser
> you.

All true.  But as I wrote, having a vote is of little real consequence
most of the time.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

Don't Miss BoostCon 2007! ==> http://www.boostcon.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

> Absolutely!  And if you turn to the concepts proposal (n2193), section
> 14.5.4, paragraph 9, you'll find this is already proposed.  Though the
> word 'Comparable' is in the wrong place; it should be
>
>   template<Comparable Kind>
>   class Compare<Kind>
>   { /*...*/ };

Cool, thats great news.  So any derived instance of Comparable will
resolve to that instance of the template class in the same way that a
function would resolve ?


> > And how about standardising the representation of function pointers so
> > that we can write better even handling and callbacks.
>
> Yep.  That one's called std::function and is already in the working
> draft [n2135], section 20.5.14.

Ok, and thats not a hacky Boost style generic programming trick, its a
real binary "thunk" layout, i.e.

struct FunctionPointer
{
   void * This;
   void (Function*) (void)
}

Which will be stable across all compilers and platforms ?

So we can have lists of function pointers and compare them, and the
notion of a member function vs a static function will be more
transparent ?


> >  What about
> > closures and coroutines ?  Why do these ideas have to remain
> > "undefined" whilst we focus on much more esoteric problems.
>
> Closures are in the lambda proposal [n1968].  I'm not sure what
> exactly you mean by coroutine in the concept of C++ -- I assume you
> don't just mean a multithreading with yielding between separate
> threads (which is likely to be included in C++09).

Yea, you can do coroutines with threads.  But no, i just meant the
yield style syntax that you see in C#, or the long jump functions that
you get in C (yuk).    Closures are a little different, in the ECMA
script sense they are anonymous functions which can reference the
local variables fromt he context where they are created.  I think D
has support for these, but its a little bit tricky without a vm/memory
management.


>
> > For every generic programming feature in the C++0x standard, i fear
> > there will be 10 far more imporant and far more fundamental non
> > generic features which will be missed.  And for all this we have to
> > wait till the end of the decade.  Whoopy do !
>
> The end of the decade isn't that long -- it's only 995 days until
> 2009-12-31!

Heh.

Thanks for your the informative comments.

Emerson

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]