quote:Original post by Polymorphic OOP

You can still do that with a const member function! You should read up on const as you seem confused as to what a const member function implies. Your two examples aren''t really showing anything that represents somethign you can''t do with a const member function. I think you are interpreting "const member-function" as a member function that returns a reference to a const, which is not what a const member function is. Also, if that is what you meant then your second example would work anyways, so either way I don''t see at all what you are trying to say.

snip

Thanks, but I already understand what const does. And just in case you don''t believe me, I look at const at the end of a member function to be basically saying, "This function promises not to change the contents of this object," or "This object will remain the same before and after this function is called." It promises invariance. I simply overlooked the fact that the function itself doesn''t actually change any part of the object although the caller of the function could easily use it to change some part of the object.

quote:
adding those stupid const''s in is more time-consuming than safe and helpful.

Only if you don''t understand what const is for, or if you have bad programming discipline, which is something const helps with (it''s one of those ''for your own good'' things).

I''d rather have an incorrect program not compile than crap itself at run-time.

haha. Fruny, every time I see a post of yours, I think, "this guy knows his sh*t

quote:Original post by temp_ie_cant_thinkof_name
Imagine what we could accomplish if we didn''t argue over the const keyword.

const is a very important logical construct. Of course you never "need" it, just like you never "need" classes and never "need" templates. const is there because they make your code safer, more clear, more logical, and often times more efficient! Not only that but there are many things in the language you can''t do without using const. Sure, you could get away with never using the const keyword and make your own programs and be none-the-wiser -- though you''d be opening yourself up for error, making less clear code, and making it difficult for people who code properly to work with your code.

quote:Original post by temp_ie_cant_thinkof_name
The only place it actually is needed is in this case:

The example you gave doesn''t make any sense. It''s not even valid C++.

quote:Original post by temp_ie_cant_thinkof_name
And there are probably other stupid idiosyncrasies that only const can appease.

Don''t call it the use of const "stupid" simply because you don''t understand it.

quote:Original post by temp_ie_cant_thinkof_name
For everything else, eg thinks like:

Vector3 operator +(const Vector3&) const;

adding those stupid const''s in is more time-consuming than safe and helpful.

Typing that extra 5-letter word is hardly time-consuming, and contrary to what you''re saying, const makes your code MORE safe. In fact, that''s almost the entire point of const (though it does have other benificial aspects). It ensures that the object being passed won''t be altered, but perhaps even more importantly, it allows you to pass a reference to a const object that you or someone else, who actually uses const correctly, created. What you end up doing is making it so that someone who uses const properly can not use your functions, simply because you were too lazy to type the word "const" (or, more likely, because you don''t really understand const).

Of course, you could try and convince people who use your code to never use const, which probably wouldn''t get you anywhere, especially if their code is already written correctly with const. Telling someone not to use const is like saying "please make your code less safe than you have before because I don''t want to use this feature of the language."

Aside from all of this, const also means a lot more. Not only does it logically convey to a programmer that it doesn''t make sense to alter the object and prevent you from doing so, but it also allows you to work with built-in types as compile time values IE for array lengths, template parameters, etc. Try to do arithmetic metaprogramming without using const. As well, const instances can often times not even have actual runtime representations (with their names merely representing compile-time literals).

While in this thread, and perhaps in these forums in general, it may seem like const is a confusing language feature, it is because a lot of people on the boards are new to the language, especially if they are coming from a language like Java which has no direct const equivalent. If you understand const, then there is no reason why you shouldn''t use it unless you are stuck using someone elses code who doesn''t understand how to use const properly. Don''t expect to get a job programming in C++ with a team if you don''t know how to use const.

So, using const leads to more logical code, more clear code, safer code, potentially more efficient code, and allows you to do things that you can''t do without the use of const. Don''t be so quick to call a feature of the language "stupid" as you did throughout your previously reply.

quote:Original post by Polymorphic OOP

quote:Original post by temp_ie_cant_thinkof_name
Imagine what we could accomplish if we didn''t argue over the const keyword.

const is a very important logical construct. Of course you never "need" it, just like you never "need" classes and never "need" templates. const is there because they make your code safer, more clear, more logical, and often times more efficient! Not only that but there are many things in the language you can''t do without using const. Sure, you could get away with never using the const keyword and make your own programs and be none-the-wiser -- though you''d be opening yourself up for error, making less clear code, and making it difficult for people who code properly to work with your code.

quote:Original post by temp_ie_cant_thinkof_name
The only place it actually is needed is in this case:

The example you gave doesn''t make any sense. It''s not even valid C++.

quote:Original post by temp_ie_cant_thinkof_name
And there are probably other stupid idiosyncrasies that only const can appease.

Don''t call it the use of const "stupid" simply because you don''t understand it.

quote:Original post by temp_ie_cant_thinkof_name
For everything else, eg thinks like:

Vector3 operator +(const Vector3&) const;

adding those stupid const''s in is more time-consuming than safe and helpful.

Typing that extra 5-letter word is hardly time-consuming, and contrary to what you''re saying, const makes your code MORE safe. In fact, that''s almost the entire point of const (though it does have other benificial aspects). It ensures that the object being passed won''t be altered, but perhaps even more importantly, it allows you to pass a reference to a const object that you or someone else, who actually uses const correctly, created. What you end up doing is making it so that someone who uses const properly can not use your functions, simply because you were too lazy to type the word "const" (or, more likely, because you don''t really understand const).

Of course, you could try and convince people who use your code to never use const, which probably wouldn''t get you anywhere, especially if their code is already written correctly with const. Telling someone not to use const is like saying "please make your code less safe than you have before because I don''t want to use this feature of the language."

Aside from all of this, const also means a lot more. Not only does it logically convey to a programmer that it doesn''t make sense to alter the object and prevent you from doing so, but it also allows you to work with built-in types as compile time values IE for array lengths, template parameters, etc. Try to do arithmetic metaprogramming without using const. As well, const instances can often times not even have actual runtime representations (with their names merely representing compile-time literals).

While in this thread, and perhaps in these forums in general, it may seem like const is a confusing language feature, it is because a lot of people on the boards are new to the language, especially if they are coming from a language like Java which has no direct const equivalent. If you understand const, then there is no reason why you shouldn''t use it unless you are stuck using someone elses code who doesn''t understand how to use const properly. Don''t expect to get a job programming in C++ with a team if you don''t know how to use const.

So, using const leads to more logical code, more clear code, safer code, potentially more efficient code, and allows you to do things that you can''t do without the use of const. Don''t be so quick to call a feature of the language "stupid" as you did throughout your previously reply.

nice, nice. very well said polymorphic. I agree with everything, except one thing: Java does sort of have a const equivalent with the reserved word "final." final is most often used for making constants, but it can also be used like so:

public void foo(final Object A) { ... }

and like so:

final Object myObject;

OK, I''m not sure about that last one, but if you could do it, it would probably be the equivalent of

object const myPointer = ...;

rather than

const object myPointer = ...;

quote:Original post by temp_ie_cant_thinkof_name
I dare not ask how const makes safer code. That example I gave (I think) is valid c++, where did I go wrong...?

Let''s take a look at your code:

class MyInt{public:  MyInt& operator =(const MyInt &x)  {      m_x = x;  }private:  int m_x;};//in code...MyInt myIntObj;myIntObj = 3; //Compiler complains if parameter is not ''const''

first, you declare a MyInt called myIntObj, that''s fine. Where your code seems suspect is in the following line. when you say:

myIntObj = 3;

then you''re calling an assignment operator, but you don''t have an assignment operator that is a member of your class and also takes an int. The one you defined wouldn''t be called, because suppose it did: then it would try to implicitly convert the 3 into a MyInt, but to do that, you would need to define a constructor with this signature:

MyInt::MyInt(int a);

but you don''t have one.

quote:Original post by clearsnake
public void foo(final Object A) { ... }

and like so:

final Object myObject;

OK, I''m not sure about that last one, but if you could do it, it would probably be the equivalent of

object const myPointer = ...;

rather than

const object myPointer = ...;

I mean

object* const myPointer = ...;

and

const object* myPointer = ...;

quote:Original post by clearsnake
Java does sort of have a const equivalent with the reserved word "final."

Not fully, which is one of my personal gripes with the langauge. Java "final"ness is scope dependent, applying only to the scope of the final declaration. As much, there is no way of making const member functions. While final attempts to simulate some of what const does it is still very different, which is probably why they chose to name it final instead of const.

quote:Original post by clearsnake
I dare not ask how const makes safer code.

It makes it illegal to accidently alter the state of the object and makes it clear to anyone using the code not only that they can''t edit the value, but that they logically shouldn''t ever have to, as it simply would never make sense to.

quote:Original post by clearsnake
That example I gave (I think) is valid c++, where did I go wrong...?

It''s broken in quite a few ways.

For one, your assignment operator is defined to return a reference to your object type, but you never returned anything.

Second, assuming you actually wanted the assignment operator to take a const reference to your type m_x = x; doesn''t make sense. you probably meant m_x = x.m_x; The reason say that is I''m thinking in your example you may have wanted it to take a const reference to an int, not your object type.

Third, again, assuming you actually wanted the assignment operator to take a const reference to your type, you never made a constructor which takes an int, so still wouldn''t compile, and then if you made that constructor, then you''d also need to make a default constructor for it.

Fourth, even after you did all that, you actually wouldn''t need const for your example to work (as temporary non-built-in types can be non-const lvalues), though again, logically it would make sense for it to be const and if it wasn''t, then you''d be disallowing valid situations where you attempt to pass const objects!

Going back to point two, if you really meant it to take a const reference to an int, then that much would work, but it would actually make more sense to pass an int instead of a reference to const one, as passing just an int is on pretty much any system is going to be more efficient than passing the address of one (though your optimizer may just do that for you).

To settle the argument of const/non-const methods. A type that has a method which is returning a reference/pointer to a member should provide both constant and non constant version which you can do, you can overload just by constantness of a member function alone, like:

const T& operator*() const;T& operator*();

But in this case he''s writing a an iterator class, normally you should create a const_iterator class to go with it

template<typename val>class iterator {public:   typedef val                  value_type;   typedef AVLNode<value_type>  node_type;   typedef node_type*           link_type;   typedef ::ptrdiff_t		difference_type;   typedef value_type&		reference;   typedef value_type*		pointer;   //... more typedefs to conform to the iterator interface   iterator() {}   iterator(link_type __x): _node(__x) {}   //... more methodsprivate:   link_type _node;};template<typename val>class const_iterator {public:   typedef val                  value_type;   typedef AVLNode<value_type>  node_type;   typedef const node_type*     link_type;   typedef ::ptrdiff_t		difference_type;   typedef const value_type&	reference;   typedef const value_type*    pointer;   //... more typedefs to conform to the const_iterator interface   iterator() {}   iterator(link_type __x): _node(__x) {}   //... more methodsprivate:   link_type _node;};

See what i did there, they look like they are the same but there not if you look at the typedefs more closely in both classess.