|
|
|
| Which language is best? |
|
Matt Smith
Member #783
November 2000
|
Quote: or you'd end up with insanely complex flowchart
only when fully expanded. My prog has the graphic equivalent of code folding. And yes, at the bottom level you do have text, but then all good diagrams are correctly and clearly labelled |
|
Shawn Hargreaves
The Progenitor
April 2000
 |
Quote: No, it is not a problem. As I have shown in the example that uses 'std::map', which uses 'std::pair' and a host of other classes, the compiler knows exactly the outtermost error position and the exact type of error. But it doesn't know the outermost error position at all. It knows the outermost point of the template instantiation. In your example that is the same as the point of the error, but that isn't always the case. Quote:
Quote: Now that's not fair! If you're allowed to say it is common knowledge how operator < works in C++, then you have to grant me that it is also common knowledge how IComparable works in C#. Not really. Operator < works the same across all languages (except Lisp and its variants): it is an infix operator that accepts two arguments and returns true/false. Whereas IComparable could be coded in many different ways, with many different function names and maybe different return types. Huh? C++: bool operator < (T a, T b); C#: int IComparable<T>.CompareTo(T other); Perl: use overload '<' => 'MyCompare'; Python: def __cmp__(a, b): Ruby: def <(other) Out of five languages that immediately occured to me, I'm not seeing a huge amount of commonality. C# and Ruby have the compare as an instance method taking one argument, while in the other three it takes two arguments. C# and Python return an strcmp style integer encoding less, equal, or greater, while the other three return a boolean and use a different method for greater than comparisons. In fact the only two that work the same are C++ and Perl, but that's only because I left out all the other wacky Perl comparison operators that you'd probably want to overload as well. I think the only really safe generalization is that you have to know the correct way to overload operators in your language of choice, because each one is different! Quote:
Quote: And in what way is this different to the C++ guy who has to look up the documentation for operator <, and modify their class to implement it? First of all, you do not need to look up the documentation for operator <, because it is common knowledge. Sorry, but that's just a ridiclous thing to say. You know how to overload operator < in C++, sure. So do I, but not everyone does. Some people know how to overload IComparable in C#, too. I do, for instance, but you do not. It's just crazy to say that one is common knowledge while the other is not, unless you're going to add some qualification like "this is common knowledge among the set of expert C++ programmers who have encountered a need to provide custom operator overloads at some earlier point in their career". Quote:
Quote: All the primitive types already implement IComparable: they wouldn't be comparable, otherwise! I do not understand how primitives can implement an interface; primitives are not objects, they do not have a vtable, so how is it possible to implement IComparable?? You don't need a vtable to implement interfaces in C#. The compiler is clever, and the .NET type system is very clever. You're assuming it works like Java, which isn't at all the case. Quote: It is either that a) the compiler cheats and provides an intrinsic implementation of IComparable or b) primitive values are boxed into objects, thus loosing the advantage of using primitives in generics. No boxing, and no cheating. You just implement whatever interface you like and off you go. Quote: Furthermore, if you do a 'x < 3', is the IComparable interface invoked or not? Yes, but whether this is statically or dynamically resolved depends on the type of X, and whether the interface implementation is virtual or not. Very much like in C++, actually, where you might or might not choose to make operator < virtual. |
|
Evert
Member #794
November 2000
 |
Quote: Operator < works the same across all languages FORTRAN prior to FORTRAN '95? |
|
Thomas Fjellstrom
Member #476
June 2000
 |
Quote: First of all, you do not need to look up the documentation for operator <, because it is common knowledge. You totally decided to ignore what I said didn't you? I'll quote it here for you: (since you seem to be ignoring half or all of what most people are saying here, and stubbornly refusing to consider that you might possibly be wrong.) I said said: It sure as hell isn't common knowledge. I haven't yet found ONE good resource that lists all of the standard operator overload formats, and explains how and why to use them. NOT ONE.
-- |
|
Goalie Ca
Member #2,579
July 2002
 |
I'm dumb! i believe the operator exists just uses a different symbol... If (x .lt. 5) then x = 7 else x = 9 end if
------------- |
|
nonnus29
Member #2,606
August 2002
 |
In one of the scripting languages I use at work LT, LE, GT, GE, NE and EQ are all valid comparison operators in addition to < , > , =, etc... Everyone who's sick of the template error message argument, clap your hands.
Quote:
only when fully expanded. My prog has the graphic equivalent of code folding. And yes, at the bottom level you do have text, but then all good diagrams are correctly and clearly labelled Interesting.... |
|
_Dante
Member #7,398
June 2006
 |
Quote: Everyone who's sick of the template error message argument, clap your hands. ----------------------------- |
|
Goalie Ca
Member #2,579
July 2002
|
you mean like this... 1Volume.cpp:360: error: invalid initialization of non-const reference of type ‘rysci::Volume3D<boost::array<double, 3ul> >&’ from a temporary of type ‘rysci::Volume3D<boost::array<double, 3ul> >*’
2Volume.cpp: In copy constructor ‘rysci::Volume3D<T>::Volume3D(const rysci::Volume3D<T>&) [with T = boost::array<double, 3ul>]’:
3Volume.cpp:414: instantiated from here
4Volume.cpp:117: error: passing ‘const rysci::Volume3D<boost::array<double, 3ul> >’ as ‘this’ argument of ‘T& rysci::Volume3D<T>::operator[](const size_t&) [with T = boost::array<double, 3ul>]’ discards qualifiers
5Volume.cpp: In function ‘void rysci::IO::writeVtk(std::string, const rysci::Volume3D<T>&) [with T = boost::array<double, 3ul>]’:
6Volume.cpp:416: instantiated from here
7Volume.cpp:378: error: passing ‘const rysci::Volume3D<boost::array<double, 3ul> >’ as ‘this’ argument of ‘const rysci::VolAttribs<3ul>& rysci::Volume3D<T>::attribs() [with T = boost::array<double, 3ul>]’ discards qualifiers
8Volume.cpp:416: instantiated from here
9Volume.cpp:382: error: no matching function for call to ‘std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(double&)’
10/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:232: note: candidates are: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(typename _Alloc::size_type, _CharT, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
11/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:225: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
12/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:218: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, typename _Alloc::size_type, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
13/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:207: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&, typename _Alloc::size_type, typename _Alloc::size_type, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
14/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:196: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&, typename _Alloc::size_type, typename _Alloc::size_type) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
15/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:182: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
16/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:190: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
17/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.h:2045: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string() [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
18Volume.cpp:382: error: no matching function for call to ‘std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(double&)’
19/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:232: note: candidates are: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(typename _Alloc::size_type, _CharT, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
20/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:225: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
21/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:218: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, typename _Alloc::size_type, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
22/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:207: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&, typename _Alloc::size_type, typename _Alloc::size_type, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
23/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:196: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&, typename _Alloc::size_type, typename _Alloc::size_type) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
24/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:182: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
25/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:190: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
26/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.h:2045: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string() [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
27Volume.cpp:382: error: no matching function for call to ‘std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(double&)’
28/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:232: note: candidates are: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(typename _Alloc::size_type, _CharT, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
29/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:225: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
30/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:218: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, typename _Alloc::size_type, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
31/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:207: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&, typename _Alloc::size_type, typename _Alloc::size_type, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
32/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:196: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&, typename _Alloc::size_type, typename _Alloc::size_type) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
33/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:182: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
34/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:190: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
35/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.h:2045: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string() [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
36Volume.cpp:383: error: no matching function for call to ‘std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(double&)’
37/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:232: note: candidates are: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(typename _Alloc::size_type, _CharT, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
38/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:225: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
39/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:218: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, typename _Alloc::size_type, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
40/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:207: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&, typename _Alloc::size_type, typename _Alloc::size_type, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
41/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:196: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&, typename _Alloc::size_type, typename _Alloc::size_type) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
42/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:182: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
43/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:190: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
44/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.h:2045: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string() [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
45Volume.cpp:383: error: no matching function for call to ‘std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(double&)’
46/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:232: note: candidates are: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(typename _Alloc::size_type, _CharT, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
47/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:225: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
48/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:218: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, typename _Alloc::size_type, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
49/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:207: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&, typename _Alloc::size_type, typename _Alloc::size_type, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
50/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:196: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&, typename _Alloc::size_type, typename _Alloc::size_type) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
51/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:182: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
52/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:190: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
53/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.h:2045: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string() [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
54Volume.cpp:383: error: no matching function for call to ‘std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(double&)’
55/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:232: note: candidates are: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(typename _Alloc::size_type, _CharT, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
56/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:225: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
57/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:218: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, typename _Alloc::size_type, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
58/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:207: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&, typename _Alloc::size_type, typename _Alloc::size_type, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
59/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/basic_string.tcc:196: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&, typename _Alloc::size_type, typename _Alloc::size_type) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
60
61... goes on post too long...
------------- |
|
Evert
Member #794
November 2000
|
Quote: i believe the operator exists just uses a different symbol...
Ofcourse a comparison operator exists; the language would be pretty useless without it (I actually program in FORTRAN nearly everyday at work). However, it's not written <, so saying `Operator < works the same across all languages' is strictly false, sine FORTRAN 77 doesn't have a < operator. |
|
axilmar
Member #1,204
April 2001
|
Shawn Hargreaves said: But it doesn't know the outermost error position at all. It knows the outermost point of the template instantiation. In your example that is the same as the point of the error, but that isn't always the case. The top-level of a C++ program is not a template; therefore the compiler starts in non-template mode. At some point the compiler finds a template instantiation and tries to compile it; from that point on, the compiler knows exactly where the types are given and what is the outtermost point that a type was instantatiated, even if typedefs are used. Quote:
Huh? Thanks for the examples that show how broken most languages are. These languages all use operator < for comparison in expressions, but only some of them are consistent enough to use it in collections. Quote: Out of five languages that immediately occured to me, I'm not seeing a huge amount of commonality. C# and Ruby have the compare as an instance method taking one argument, while in the other three it takes two arguments. C# and Python return an strcmp style integer encoding less, equal, or greater, while the other three return a boolean and use a different method for greater than comparisons. In fact the only two that work the same are C++ and Perl, but that's only because I left out all the other wacky Perl comparison operators that you'd probably want to overload as well. I think the only really safe generalization is that you have to know the correct way to overload operators in your language of choice, because each one is different! My point was not about how languages handle operator overloading, but how all languages use operator < in expressions. Your cleverly talked about the operator overloading, but I talked about what operator < is and how it is used in expressions. All languages except LISP and those with reverse polish notation handle operator < like this (ok, and maybe a few others, but if you want to nitpick): <argument1> '<' <argument2> so it is pretty much common knowledge on how this operator is supposed to work. And it is a step in the right direction when a language allows an operator to be defined 'naturally', i.e. in the same manner that it used. Quote: Sorry, but that's just a ridiclous thing to say. You know how to overload operator < in C++, sure. So do I, but not everyone does. Some people know how to overload IComparable in C#, too. I do, for instance, but you do not. It's just crazy to say that one is common knowledge while the other is not, unless you're going to add some qualification like "this is common knowledge among the set of expert C++ programmers who have encountered a need to provide custom operator overloads at some earlier point in their career". Not as ridiculus as twisting one's argument, I am afraid. Quote: You don't need a vtable to implement interfaces in C#. The compiler is clever, and the .NET type system is very clever. You're assuming it works like Java, which isn't at all the case. I already told you the compiler cheats. Quote: No boxing, and no cheating. You just implement whatever interface you like and off you go. Of course it is not boxing, but it is cheating. Because the language does not treat classes uniformly. Of course in C# primitives are structs, but that is a completely artificial distinction (between structs and classes, that is). Of course that introduces another problem: what if I have a very useful struct that I want it to leave on the heap, for some reason? C# bites the bullet, doesn't it? the programmer has to make a wrapper class (as always, feel free to correct me - I am not a C# expert; C# has many hidden corners). Whereas in C++ the memory space a variable lives is decoupled from the actual functionality of the class...and that, my friend, is correct design. Quote: Yes, but whether this is statically or dynamically resolved depends on the type of X, and whether the interface implementation is virtual or not. Very much like in C++, actually, where you might or might not choose to make operator < virtual. If I make my own value class that implements IComparable with a side effect (for example, outputing a message in the console), do I get the message when I do a 'x < 3' or do I have to explicitely call 'CompareTo'? Thomas Fjellstrom said: You totally decided to ignore what I said didn't you? I'll quote it here for you: (since you seem to be ignoring half or all of what most people are saying here, and stubbornly refusing to consider that you might possibly be wrong.) As usual, it's me vs Allegro.cc...what's up with the sheep mentality anyway? Look, your comment is covered in some of my replies. Feel free to feel it is unjustified, but don't complain because in a topic with 9 pages I haven't replied to you. Has it occurred to you I maybe did not notice your message? and certainly I am not in a dialogue with half of what people are saying here. Quote: It sure as hell isn't common knowledge. I haven't yet found ONE good resource that lists all of the standard operator overload formats, and explains how and why to use them. NOT ONE. What exactly is it there you want to know? the C++ documentation is pretty clear on how operators are overloaded and there are plenty of articles to check online. And the Microsoft documentation has what you ask (i.e. the list of all operators, their format, if they are binary or unary, and their associativity). How is it the fault of the language that you can't easily find the documentation you ask? if somebody had bothered to write it, you wouldn't complain. But it is not a fault of the language in any way. Goalie Ca said:
you mean like this... Maybe the error is that you tried to instantiate an std::string from a double. Disclaimer for all the people that are interested in this discussion: I am not saying that C++ error reporting is perfect or even good. What I am saying is that the compiler creators did not bother implement decent error reporting and that it is not the language's fault that template error messages are not that good. The language, as it is, does not lack anything that makes it impossible to have error reporting as good as other languages created much later (C#, for example). |
|
Thomas Fjellstrom
Member #476
June 2000
|
Quote: And the Microsoft documentation has what you ask Because we all run windows and have an MSDN subscription. Quote: what's up with the sheep mentality anyway? Just because people agree doesn't mean they are sheep. Quote: the C++ documentation is pretty clear on how operators are overloaded and there are plenty of articles to check online. _The_ C++ documentation, the one that costs hundreds to thousands of dollars? And hey, if you have a link to a complete table of all the forms of operator overloads, as well as some examples to go with, that'd be great. I've searched many times in the past and not found one. -- |
|
_Dante
Member #7,398
June 2006
|
Sorry... couldn't help myself ----------------------------- |
|
Marcello
Member #1,860
January 2002
 |
Holy crap, you can overload ,? How does that work? Marcello |
|
Shawn Hargreaves
The Progenitor
April 2000
|
Quote: Holy crap, you can overload ,? How does that work? This is where the difference between the words "can" and "should" becomes really important :-) You can overload it to do anything you like. For instance I've seen this used as a container constructor: - Overload 'T, T' to return a vector<T> containing the two arguments Then you can write '1, 2, 3, 4' as shorthand for constructing a vector and filling it with data. Is this actually a good idea? I suspect not. |
|
Thomas Fjellstrom
Member #476
June 2000
|
Quote:
Sorry... couldn't help myself And how am I supposed to know that thats actually Standard C++? Does MS even support Standard C++? Not to mention that the page is virtually unreadable. I suspect they expect me to be using IE, which is certainly NOT the case. -- |
|
Zaphos
Member #1,468
August 2001
|
Quote: I am not saying that C++ error reporting is perfect or even good. What I am saying is that the compiler creators did not bother implement decent error reporting and that it is not the language's fault that template error messages are not that good. I don't have much to say about the specifics of the argument; I'm not entirely sold on it but I lack both expertise & interest. Interest, because really, as someone who is not a language developer but rather a language user, I find it hard to ignore the context in which the language is presented. The tools and features surrounding a language do matter. Shawn said something interesting in a similar thread, pointing out that even the language 'culture' affects the experience of using the language. As an end user, the quality of the language experience is not determined by just the core specification, but by all sorts of external factors surrounding the language. edits:
|
|
Marcello
Member #1,860
January 2002
|
Page loads fine in Firefox. Marcello |
|
_Dante
Member #7,398
June 2006
|
Quote: And how am I supposed to know that thats actually Standard C++? Does MS even support Standard C++? Much as it pains me to admit it, MSVC is probably one of the most compliant compilers around. Sadly, ARM is somewhat behind; I do embedded development, and one of the guys in my office is a C++ junky. I think he has the spec open in his browser with a lead weight resting on F5. Anyhow, he's always bitching about some missing feature or other. Some people use templates way too much. Quote: Not to mention that the page is virtually unreadable. I suspect they expect me to be using IE, which is certainly NOT the case. I'm using Firefox, and it looks just fine. Regardless, I was merely pointing out that documentation is both available and free, and really, doing it in jest. I'm up for a good debate as much as the next guy - probably more - provided it doesn't degrade into jumping down each other's throats over minutia like this. We're about one step away from, "Oh yeah? If you love C++ so much, why don't you marry it?" ----------------------------- |
|
Thomas Fjellstrom
Member #476
June 2000
|
Quote: minutia Might be minutia to you Since firefox started eating up 512MB+ ram, I've switched away. Quote: Regarding operator overloading, seems to me there are plenty of references around. Here are a few more. Thank you. Except none of those links, including the MSDN one comes close to what I asked for. I actually do know about all of the standard operators, just not the forms you need to use in specific instances when overloading them. Many operators have more than one overloaded form depending on the usage/context. Something like this would be very nice, I'd even print it out, laminate it and tack it to the wall/stick it to my monitor. Operator Form Usage + Type operator+(...) ....
-- |
|
Zaphos
Member #1,468
August 2001
|
Quote: Except none of those links, including the MSDN one comes close to what I asked for. The wikibooks one divides the operators into categories and gives usage examples for each category. They skip examples for the [] and () operators, but still explain the usage, and there's more discussion of those two in the c++ faq lite. So while the information might not come in exactly the form you want, it seems to be out there in a relatively extensive and friendly way such that you could put it in that form without excessive difficulty.
|
|
Carrus85
Member #2,633
August 2002
 |
If you want a good read on how operator overloads work (as well as other advanced topics), I'd recommend Bruce Eckel's Thinking in C++ books, both volumes. Great books, IMHO. I had a long post about how to do particular operator overloads from memory, but A) it was eaten by the Flying Spagetti Monster and B) it is probably faster and more easily readable to just direct you to a book that covers it all in depth.
|
|
23yrold3yrold
Member #1,134
March 2001
 |
Quote: Much as it pains me to admit it, MSVC is probably one of the most compliant compilers around. Wow, things have changed a lot. I still remember after I wrote those STL tutorials; almost every person that had errors compiling them was a VC++ user ... -- |
|
_Dante
Member #7,398
June 2006
|
Quote: Wow, things have changed a lot. I still remember after I wrote those STL tutorials; almost every person that had errors compiling them was a VC++ user ... They have. VC6 was definitely lacking, but VC7 apparently steps up to the plate. My template loving co-worker does all sorts of wild things and there never seems to be an issue until we pump them through armcpp. It's all down to economics, I guess. ----------------------------- |
|
axilmar
Member #1,204
April 2001
|
Quote: Because we all run windows and have an MSDN subscription. It is online. Quote: Just because people agree doesn't mean they are sheep. They agree, but what arguments they have? it seems like they agree because somebody famous said something, not because they have analysed the arguments and found them correct. Thomas Fjellstrom said: The C++ documentation, the one that costs hundreds to thousands of dollars? And hey, if you have a link to a complete table of all the forms of operator overloads, as well as some examples to go with, that'd be great. I've searched many times in the past and not found one. Sorry for saying this, but you remind me of Rantaplan, Lucky Luke's dog: in an area full of water and food, it almost died from starvation. I won't do your job, google is your friend. _Dante said: Sorry... couldn't help myself Now...you've spoilt it! the fun is gone!!! :-) Quote: And how am I supposed to know that thats actually Standard C++? Does MS even support Standard C++? Microsoft C++ compiler version 8.0 is 98.9% compliant with the latest C++ standard (from what I remember). They only left out the template export functionality, I think. But why are you supposing that Microsoft's C++ has proprietary extensions not explicitely mentioned? if you find something like that, please notify Microsoft...because for all their proprietary extensions, they have a "Microsoft specific" region in their help. Quote: Not to mention that the page is virtually unreadable. I suspect they expect me to be using IE, which is certainly NOT the case. Boy, you are a whiner, aren't you? I am using Firefox and the page looks ok. Zaphos said:
I don't have much to say about the specifics of the argument; I'm not entirely sold on it but I lack both expertise & interest. Interest, because really, as someone who is not a language developer but rather a language user, I find it hard to ignore the context in which the language is presented. The tools and features surrounding a language do matter. Shawn said something interesting in a similar thread, pointing out that even the language 'culture' affects the experience of using the language. As an end user, the quality of the language experience is not determined by just the core specification, but by all sorts of external factors surrounding the language. Exactly! you said it very nicely and I couldn't agree more with you. That's why I would like to see things in C++ fixed because if they do so, C++ will be the superior language. The right ingredients are there, but the soup needs fixing. |
|
Marcello
Member #1,860
January 2002
|
Quote: Exactly! you said it very nicely and I couldn't agree more with you. That's why I would like to see things in C++ fixed because if they do so, C++ will be the superior language. The right ingredients are there, but the soup needs fixing. So until they do, I'll use better languages. =P I would consider it blind faith to consider C++ the 'ultimate' language. Marcello |
|
|
|
