C++ Concepts
in [C++]
|
Prev: C++/CLI limitations?
Next: SHA1
From: Gabriel Dos Reis on 6 Oct 2005 09:32 "dave_abrahams" <dave(a)boost-consulting.com> writes: | 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. Thas distinction has always been present in the model develped by Bjarne and me because it renders directly the Assignment requirement as is in the current standard library. As a matter of fact, we disucced that particular aspect at length in the paper "Specifying C++ concepts". | 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. I don't believe the specific example at hand is a compelling reason for that. And in general, the problem is that of *ambiguity*, no accidental match as people sometimes claim; and there are various ways to resolve ambiguity. -- Gabriel Dos Reis gdr(a)integrable-solutions.net [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Sergey P. Derevyago on 6 Oct 2005 11:14 kanze wrote: > 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). > AFAIKS they could get this right from the beginning; there is no excuse. In particular, in my own Java code I always separate Iterator next() and Object getVal() operations. > 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. > Not, unfortunately. The famous Alex Stepanov's statement You can't write a generic max() in Java that takes two arguments of some type and has a return value of that same type. Inheritance and interfaces don't help. And if they cannot implement max or swap or linear search, what chances do they have to implement really complex stuff? These are my litmus tests: if a language allows me to implement max and swap and linear search generically - then it has some potential. still holds: generics in Java discriminates against built-ins such as int or double. > 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. > -- 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: Niklas Matthies on 6 Oct 2005 17:46 On 2005-10-06 15:14, Sergey P. Derevyago wrote: > kanze wrote: >> Sergey P. Derevyago wrote: >> > kanze wrote: : >> >> And of course, the lack of type safety could hardly be called a >> >> feature; >> >> > [2] : >> With regards to [2], too, I've heard that it has been corrected >> in the most recent versions of Java. >> > Not, unfortunately. The famous Alex Stepanov's statement > > You can't write a generic max() in Java that takes two arguments of > some type and has a return value of that same type. Yes you can. Due to auto(un)boxing, the following compiles public class Test { public static <T extends Comparable<T>> T max(T a, T b) { return a.compareTo(b) > 0 ? a : b; } public static void main(String[] argv) { int max_int = max(42, 23); char max_char = max('a', 'b'); double max_double = max(23.0, 42.0); boolean max_boolean = max(true, false); String max_string = max("foo", "bar"); System.out.println(max_int); System.out.println(max_char); System.out.println(max_double); System.out.println(max_boolean); System.out.println(max_string); } } and prints 42 b 42.0 true foo -- Niklas Matthies [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: dave_abrahams on 6 Oct 2005 17:48 Sergey P. Derevyago wrote: > AFAIKS they could get this right from the beginning; there is no excuse. > In particular, in my own Java code I always separate Iterator next() and > Object getVal() operations. Not that one is needed, but certainly there is an excuse, even if you buy into the idea that it's a mistake to have two iterators delimit a range -- which I don't. Especially at the time the STL was designed, the desire to allow the highest performance dictated that pointers should be usable as iterators directly. The abstraction penalty that could be associated with stuffing pointers into some other class was unacceptable. There are other arguments for the STL iterator model, too. I'm not claiming it's ideal in every way (actually I favor both a more decomposed model -- cursors and property maps -- and a more bundled model -- ranges/sequences -- simultaneously). But it's important to recognize that every point in the design space has its trade-offs. > > With regards to [2], too, I've heard that it has been corrected > > in the most recent versions of Java. > > > Not, unfortunately. The famous Alex Stepanov's statement > > You can't write a generic max() in Java that takes two arguments of some type > and has a return value of that same type. Inheritance and interfaces don't > help. And if they cannot implement max or swap or linear search, what chances > do they have to implement really complex stuff? These are my litmus tests: if > a language allows me to implement max and swap and linear search generically - > then it has some potential. > > still holds: generics in Java discriminates against built-ins such as int or > double. Actually the problem may be deeper than just discriminating against built-ins. I'm a bit fuzzy on the details right now, but as explained to me, you can't implement any function such as max, swap, etc., that has covariant argument types, on top of a runtime polymorphic system, without compromising static type safety. -- 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: Sergey P. Derevyago on 7 Oct 2005 09:09
Niklas Matthies wrote: > > You can't write a generic max() in Java that takes two arguments of > > some type and has a return value of that same type. > > Yes you can. Due to auto(un)boxing, the following compiles > > public class Test > { > public static <T extends Comparable<T>> T max(T a, T b) > { > return a.compareTo(b) > 0 ? a : b; > } > > public static void main(String[] argv) > { > int max_int = max(42, 23); > char max_char = max('a', 'b'); > double max_double = max(23.0, 42.0); > boolean max_boolean = max(true, false); > String max_string = max("foo", "bar"); > IMHO auto(un)boxing is nothing more than a dirty hack. In particular, I see the performance and overloading problems (at least). Look, void f(Object o) {} // [1] void f(int i) {} // [2] f(max(1,2)); What f() will be called? -- 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! ] |