C++ Concepts
in [C++]
|
Prev: C++/CLI limitations?
Next: SHA1
From: Sergey P. Derevyago on 4 Oct 2005 14:52 kanze wrote: > They do weaken the argument by combining incrementation and > access in a single function; this is a definite mistake, [1] > and makes it very difficult to write mutating filtering iterators. > On the other hand, most of the time I've wanted to mutate, I've > been able to make do with a view of the collection, rather than > iterators. And of course, the lack of type safety could hardly > be called a feature; [2] > I did have one or two cases where it was > convenient, but in each case, a collection of a discriminant > union (missing in both languages) would have been an even better > solution. > IMHO even these two fundamental drawbacks clearly overweight the gains. -- With all respect, Sergey. http://ders.angen.net/ mailto : ders at skeptik.net [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: kibun on 4 Oct 2005 14:57 kanze wrote: > But the problem isn't there. Having a common base class doesn't > do any harm in itself; it may even be useful for supporting > things like reflection. The problem is elsewhere: given an orthogonally to this thread, is there any proposal for 'compile time reflection' stright into the core language ? I mean, 'traits' on steroid :) [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Joel Eidsath on 4 Oct 2005 14:53 >> I think >> that enforcing 2 may fool some people into thinking that all concept >> templates are truly generic. > >We're back to square 1. What do you mean? Give some examples, please. I was thinking of situations like vectors of auto_ptrs. "Assignable" doesn't guarantee much if operator= is overloaded in a strange way. >> More importantly, because of 2, I can't >> make existing template code more safe for code users by just adding a >> single concept to stop the user from doing something stupid. I have to >> add every concept that the template code uses. > >Why is that bad? I agree that you wind up with more correct code in the end, but it's more work translating old templates to concept templates. Just a little work could probably catch 90% of use errors, but programmers are forced to go the whole way to 100%. They may therefore forgo updating old code entirely. As I read more about concepts, I'm starting to get the impression that their main use is to provide better compilation error messages (I've used the STL a lot, and agree that's not simply a minor advantage). The other uses I had envisioned seem a little more esoteric now. I have the feeling that I'm missing something. Joel Eidsath [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: dave_abrahams on 5 Oct 2005 16:55 Joel Eidsath wrote: > >> I think > >> that enforcing 2 may fool some people into thinking that all concept > >> templates are truly generic. > > > >We're back to square 1. What do you mean? Give some examples, please. > > I was thinking of situations like vectors of auto_ptrs. "Assignable" > doesn't guarantee much if operator= is overloaded in a strange way. Well, for Assignable and auto_ptr in particular, you wouldn't get that problem -- at least not with the Indiana proposal -- because of the way auto_ptr's assignment operator takes its rhs by non-const reference. That would prevent it from implicitly matching the assignment signature in the Assignable concept. I'm not sure whether you'd get a similar effect under the Texas proposal, because their use of valid expressions for matching. Maybe Gaby or Bjarne can comment on that. But more generally, the problem you cite is why it's important that conformance to _some_ concepts be declared explicitly. I don't happen to believe that Assignable is one of those. > >> More importantly, because of 2, I can't > >> make existing template code more safe for code users by just adding a > >> single concept to stop the user from doing something stupid. I have to > >> add every concept that the template code uses. > > > >Why is that bad? > > I agree that you wind up with more correct code in the end, but it's > more work translating old templates to concept templates. Just a > little work could probably catch 90% of use errors, but programmers are > forced to go the whole way to 100%. They may therefore forgo updating > old code entirely. Could be. Just remember that a lot more code will be written in the future than has ever been written in the past. > As I read more about concepts, I'm starting to get the impression that > their main use is to provide better compilation error messages (I've > used the STL a lot, and agree that's not simply a minor advantage). > The other uses I had envisioned seem a little more esoteric now. I > have the feeling that I'm missing something. Maybe; maybe not. I suggest you download ConceptGCC, look at its tutorial, and get some experience with it. Things always look a lot clearer when you have a real implementation to play with :) Mac OS X Panther: http://www.osl.iu.edu/~dgregor/ConceptGCC/files/conceptgcc-ic2-gcc-4.0.1-macosx-10.3.9.tar.bz2 Mac OS X Tiger: http://www.osl.iu.edu/~dgregor/ConceptGCC/files/conceptgcc-ic2-gcc-4.0.1-macosx-10.4.2.tar.bz2 Cygwin (binary): http://www.osl.iu.edu/~dgregor/ConceptGCC/files/conceptgcc-ic2-gcc-4.0.1-cygwin.tar.bz2 Cygwin (source patch): http://www.osl.iu.edu/~dgregor/ConceptGCC/files/conceptgcc-ic2-gcc-4.0.1-cygwin.patch -- Dave Abrahams Boost Consulting http://www.boost-consulting.com [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: kanze on 5 Oct 2005 17:26
Sergey P. Derevyago wrote: > kanze wrote: >> They do weaken the argument by combining incrementation and >> access in a single function; this is a definite mistake, > [1] >> and makes it very difficult to write mutating filtering >> iterators. On the other hand, most of the time I've wanted >> to mutate, I've been able to make do with a view of the >> collection, rather than iterators. And of course, the lack >> of type safety could hardly be called a feature; > [2] >> I did have one or two cases where it was convenient, but in >> each case, a collection of a discriminant union (missing in >> both languages) would have been an even better solution. > IMHO even these two fundamental drawbacks clearly overweight > the gains. Well, it obviously depends on what you are doing. The first drawback is usually fairly simple to work around (unlike the fact that you need two iterators). The second is a basic problem with the language, not the library; globally, if I'm writing robust code, I definitly prefer C++, regardless of the library issues. But my statement only concerned the actual libraries. With regards to [2], too, I've heard that it has been corrected in the most recent versions of Java. Haven't had the occasion to try it and see, however. But it was an important consideration in practice -- it doesn't matter how well the library is designed if the language won't let it do the right thing. -- James Kanze GABI Software 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 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |