Re: Only if such differences exist

Post #75,468 by JimWeirich 1/18/03 10:33:25 PM Reply	Re: Only if such differences exist Todd: more often, programmers throw const around here and there without really understanding what its doing. As des said - its not well understood and generally misused. Really. I've not run into much problems with const, which is, after all, an ANSI C construct and is well entrenched in the ANSI C libraries. I'd be surprised if most C programmers had trouble, otherwise they would constantly run afoul of the standard library. The problem in C++ is its interaction with overloading, which can be subtl. In fact, the problem Todd is having is more with overloading than with const. BTW ... I like the Alan Perlis quote. Programming should be fun. -- -- Jim Weirich jweirich@one.net [link\|http://w3.one.net/~jweirich\|http://w3.one.net/~jweirich] --------------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
Post #75,554 by tuberculosis 1/19/03 5:34:48 PM 8/21/07 6:28:10 AM Reply	const functions are the problem. And as you point out - overloading on const (which is pretty lame). The biggest problem is mixing cost references (I hate references - they suck - use pointers) with objects that aren't exactly const correct (nearly all of them). People forget to declare methods const - even if they are, and suddenly you're casting away const to get around it. Especially in foreign libraries you don't control the source to. If C++ were a powertool, OSHA would have made Stroustrup take it off the market. I think that it's extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customer got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don't think we are. I think we're responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don't become missionaries. Don't feel as if you're Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don't feel as if the key to successful computing is only in your hands. What's in your hands, I think and hope, is intelligence: the ability to see the machine as more than when you were first led up to it, that you can make it more. --Alan Perlis Edited by tuberculosis Aug. 21, 2007, 06:28:10 AM EDT Expand All History
Post #75,930 by Simon_Jester 1/21/03 1:53:21 PM Reply	Well, it doesnt' appear to be overloaded on const in fact I'm not sure you can overload on const (I think I tried to at one point). One function was taking a bool in the sig (defaulted to true) and the other a char *. I think (but am not sure) that the problem was that the function itself was const (on one sig) and in the other it wasn't, but I'd have to prototype to verify. BTW: I do agree with your other statements however. Beware programmers that overly use const, as it becomes a REAL pain to get around them later.
Post #75,948 by JimWeirich 1/21/03 3:47:40 PM Reply	Re: Well, it doesnt' appear to be overloaded on const Beware programmers that overly use const, as it becomes a REAL pain to get around them later. There are two ways to work with const ... 1) Never use const ... 2) Always use const where appropriate ... In both cases you run into problems with libraries that did it the other way. I tend to fall into category 2. -- -- Jim Weirich jweirich@one.net [link\|http://w3.one.net/~jweirich\|http://w3.one.net/~jweirich] --------------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
Post #75,963 by tuberculosis 1/21/03 4:13:33 PM 8/21/07 6:37:06 AM Reply	No, thats exactly the problem It works like this: class List { public: void addItem(int i) { /* do add / } void addItem(int i) const { throw new ConstListException(); } } List list = new List(); const List* clist = list; list.addItem(i); // fine - adds an item clist.addItem(i); // throws an exception because const version is invoked IOW, if you define a member function and you don't make it const, then you can't call it using a const ref to the object. If you define a member function and make it const, you can call it with both a const and non-const ref to the object. If you define both a non-const and const version of the same function, the const version is called when you have a const ref to the object and the non-const version is called with non-const refs. As developers aren't particularly good judges on what is const and what isn't const, this "feature" has turned out to be a PITA. ------ There is a different approach that was employed in ObjectiveC. The collection classes (which is usually the issue anyhow - do you return a new copy or a reference to private data?) are defined at two levels. NSArray, NSDictionary, and NSSet have read-only semantics. No mutators are defined in these classes. So they are effective immutable. NSMutableArray is a subclass of NSArray and adds mutator methods (those that you wouldn't declare const). Same with NSDictionary and NSSet, mutable subclasses exist. Suppose I have a class Artist with an array of Paintings. @interface Artist { NSMutableArray* _paintings; } -(void)addPainting:(Painting)p { [_paintings addObject: p]; } -(void)removePainting:(Painting)p { [_paintings removeObject: p; } -(NSArray*)paintings { return _paintings; } @end Notice that when asked for the list of paintings, I say I return the superclass type NSArray. Its private data, but if you try to send it a mutator method, the compiler will warn you that this is not cool (but it'll still do it). Thus, I get out of copying the collection and still keep it from being modified. (They could downcast - but downcasting is evil and thus they deserve what they get for that). Simple two level design idea. C++'s const mechanism tries to do the same thing, but its more confusing to use and I think it fails because its confusing. I think that it's extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customer got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don't think we are. I think we're responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don't become missionaries. Don't feel as if you're Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don't feel as if the key to successful computing is only in your hands. What's in your hands, I think and hope, is intelligence: the ability to see the machine as more than when you were first led up to it, that you can make it more. --Alan Perlis Edited by tuberculosis Aug. 21, 2007, 06:37:06 AM EDT Expand All History
Post #75,992 by Arkadiy 1/21/03 5:42:24 PM Reply	This is what bugs me in Scott's problem... >>>>>>>>>>>>> If you define a member function and make it const, you can call it with both a const and non-const ref to the object. <<<<<<<<<<<< He has a const member function. There is really no conversion involved in calling const function on non-const reference. What the hell does compiler want from the poor guy? One more thing. In this code: \nclass OtherClass\n{\npublic:\n\n\tbool Address(const char address);\n\n\tinline std::string Address(bool bUseDot = true) const ;\n};\n\n\nvoid tryThis()\n{\n OtherClass m_addr;\n\tstd::string m_server_address = m_addr.Address(false/replace here*/);\n}\n\n If I replace "false" in tryThis() with "true", it compiles fine. Could GCC be trying to interpret "false" as NULL? Dumb, I know. -- We have only 2 things to worry about: That things will never get back to normal, and that they already have.
Post #76,023 by Arkadiy 1/21/03 9:43:01 PM Reply	I was pissed enough at the problem I hacked gcc code to report on what conversions take place. Here is the code I used for testing: \nclass OtherClass\n{\npublic:\n\n bool Address(const char address);\n\n inline const char Address(bool bUseDot = true) const ;\n};\n\n\nvoid tryThis()\n{\n OtherClass m_addr;\n const char m_server_address = m_addr.Address(false);\n}\n Works just as badly as the original. Here is the debug output: \ng++ -c test.cpp\ntest.cpp: In function `void tryThis()':\ntest.cpp:25: warning: from "OtherClass" "&m_addr"to "const OtherClass" using\ntest.cpp:25: warning: qual_conv\ntest.cpp:25: warning: identity_conv\ntest.cpp:25: warning: &m_addr\n\ntest.cpp:25: warning: from "bool" "false"to "bool" using\ntest.cpp:25: warning: identity_conv\ntest.cpp:25: warning: false\n\ntest.cpp:25: warning: from "OtherClass" "&m_addr"to "OtherClass" using\ntest.cpp:25: warning: identity_conv\ntest.cpp:25: warning: &m_addr\n\ntest.cpp:25: warning: from "bool" "false"to "const char" using\ntest.cpp:25: warning: std_conv\ntest.cpp:25: warning: identity_conv\ntest.cpp:25: warning: false\n\ntest.cpp:25: choosing `const char* OtherClass::Address(bool) const' over `bool\n OtherClass::Address(const char)'\ntest.cpp:25: because worst conversion for the former is better than worst\n conversion for the latter\n\nCompilation exited abnormally with code 1 at Tue Jan 21 21:31:05\n So, it takes 2 conversions to go from false to (const char ) Here are relevant paragraphs from [link\|http://www.comnets.rwth-aachen.de/doc/c++std/conv.html\|C++ standard:] >>>>>>>>>>>>>>>>>>>>>>> 1 Standard conversions are implicit conversions defined for built-in types. The full set of such conversions is enumerated in this clause. A standard conversion sequence is a sequence of standard conversions in the following order: --Zero or one conversion from the following set: lvalue-to-rvalue con- version, array-to-pointer conversion, and function-to-pointer con- version. --Zero or one conversion from the following set: integral promotions, floating point promotion, integral conversions, floating point con- versions, floating-integral conversions, pointer conversions, pointer to member conversions, and boolean conversions. --Zero or one qualification conversion. [Note: a standard conversion sequence can be empty, i.e., it can con- sist of no conversions. ] A standard conversion sequence will be applied to an expression if necessary to convert it to a required des- tination type. ........ 4 An rvalue of type bool can be converted to an rvalue of type int, with false becoming zero and true becoming one. ......... 1 An integral constant expression (_expr.const_) rvalue of integer type that evaluates to zero (called a null pointer constant) can be con- verted to a pointer type. The result is a value (called the null pointer value of that type) distinguishable from every pointer to an object or function. Two null pointer values of the same type shall compare equal. The conversion of a null pointer constant to a pointer to cv-qualified type is a single conversion, and not the sequence of a pointer conversion followed by a qualification conversion (_conv.qual_). <<<<<<<<<<<<<<<<<<< So, GCC is right. And I have to concede: C++ is a sick language. However, the correct conversion should still be picked by comparing length of path for 2 possibilities. The text that Scott saw on screen was a "pedantic warning" - something less than a regular warning. It should never fail the compilation. I'll try to find out why the exit code is 1 after that "pedwarn". -- We have only 2 things to worry about: That things will never get back to normal, and that they already have.
Post #76,031 by admin 1/21/03 10:37:18 PM Reply	I was pissed enough that I: Switched to 2.95.4 with stlport, which works "wonderfully" (read: sufficiently crummy version of wonderful as defined by the C++ spec) as compared to 3.2.1. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #76,038 by Arkadiy 1/21/03 11:23:30 PM Reply	Solution `-fpermissive' Downgrade messages about nonconformant code from errors to warnings. By default, G++ effectively sets `-pedantic-errors' without `-pedantic'; this option reverses that. This behavior and this option are superseded by `-pedantic', which works as it does for GNU C. I think GCC is no less fucked than C++ standard. But at least you can make it swallow the code. -- We have only 2 things to worry about: That things will never get back to normal, and that they already have.
Post #76,039 by admin 1/21/03 11:24:50 PM Reply	ROFL But at least you can make it swallow the code. gcc: the compiler that swallows, not spits. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #76,119 by a6l6e6x 1/22/03 11:08:55 AM Reply	Re: "..you can make it swallow the code." Beautiful! Alex "No man's life, liberty, or property are safe while the legislature is in session."\t-- Mark Twain

Welcome to IWETHEY!