strobert
asked on
const method not being used
say I have:
template <class T>
class Foo
{
public:
T& operator * ();
const T& operator * () const;
};
int main()
{
Foo<int> fred;
int &ri1 = *fred;
const int &ri1 = *fred;
}
both lines call the non-const op *. I thought I remeber const methods were suposed to be called if they could be.
template <class T>
class Foo
{
public:
T& operator * ();
const T& operator * () const;
};
int main()
{
Foo<int> fred;
int &ri1 = *fred;
const int &ri1 = *fred;
}
both lines call the non-const op *. I thought I remeber const methods were suposed to be called if they could be.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
> is the abiltiy to overload by const spec'd anywhere?
Check out the latest version of the ANSI C++ draft standard at
http://www.cygnus.com/misc/wp/dec96pub/over.html
Basically, it sais that a member function is like a regular
function with one extra argument: a pointer to the object (this)
[There are many differences, but this view help to understand
overloading]. This means that you can overload by the constness
of the this argument.
> I would like the same itr class to be used for iterating on
> const vector's and non-const vector's. I was going to keep a
> state variable as to what the itr was contructed with (a
> Vector& or a const vector&) and in the T& op * throw an
> exception if we were itring on a const vector&...
Your solution sounds OK, just keep in mind that the error will
only be discovered at runtime instead if at compile time.
Another solution is to have two classes: iter and const_iter.
Instead of constructing an iterator by
iter i(a_vector);
You can add a member function to vector that returns an iterator
to the beginning (or end) of the vector:
class vector
{
public:
// ...
iter begin();
const_iter begin() const;
};
This way the user of vector will get the correct iterator class,
without having to worry about it.
> I have a vector class.
Why write your own vector instead of using STL?
You can get STL from
* http://www.ipmce.su/~fbp/stl/
And there are several short tutorials at:
* http://www.sgi.com/Technology/STL/stl_introduction.html
* http://www.objectplace.com/technology/articles/9508.shtml
* http://www.cs.brown.edu/people/jak/programming/stl-tutorial/
tutorial.html
* http://www.infosys.tuwien.ac.at/Research/Component/
tutorial/prwmain.htm
Check out the latest version of the ANSI C++ draft standard at
http://www.cygnus.com/misc/wp/dec96pub/over.html
Basically, it sais that a member function is like a regular
function with one extra argument: a pointer to the object (this)
[There are many differences, but this view help to understand
overloading]. This means that you can overload by the constness
of the this argument.
> I would like the same itr class to be used for iterating on
> const vector's and non-const vector's. I was going to keep a
> state variable as to what the itr was contructed with (a
> Vector& or a const vector&) and in the T& op * throw an
> exception if we were itring on a const vector&...
Your solution sounds OK, just keep in mind that the error will
only be discovered at runtime instead if at compile time.
Another solution is to have two classes: iter and const_iter.
Instead of constructing an iterator by
iter i(a_vector);
You can add a member function to vector that returns an iterator
to the beginning (or end) of the vector:
class vector
{
public:
// ...
iter begin();
const_iter begin() const;
};
This way the user of vector will get the correct iterator class,
without having to worry about it.
> I have a vector class.
Why write your own vector instead of using STL?
You can get STL from
* http://www.ipmce.su/~fbp/stl/
And there are several short tutorials at:
* http://www.sgi.com/Technology/STL/stl_introduction.html
* http://www.objectplace.com/technology/articles/9508.shtml
* http://www.cs.brown.edu/people/jak/programming/stl-tutorial/
tutorial.html
* http://www.infosys.tuwien.ac.at/Research/Component/
tutorial/prwmain.htm
ASKER
Run-time was fine with me (basically it is an assert like case so runtime is fine just like out of bounds on a bracket)
good thought with the begin...
I will probably either go with that or the two class (Itr and ConstItr) method.
Why I don't use the STL:
1) I actually have some philisophical disagreements with the way it does things.
2) wether I like it or not, I can't use it. My dev platform is VC++ under windows and the STL implementation Microsquish ships makes it almost unusable. Plus given the way the STL tends to abuse templates I wouldn't trust it under VC++ since there are a lot of broken things in VC++ templates.
good thought with the begin...
I will probably either go with that or the two class (Itr and ConstItr) method.
Why I don't use the STL:
1) I actually have some philisophical disagreements with the way it does things.
2) wether I like it or not, I can't use it. My dev platform is VC++ under windows and the STL implementation Microsquish ships makes it almost unusable. Plus given the way the STL tends to abuse templates I wouldn't trust it under VC++ since there are a lot of broken things in VC++ templates.
> I actually have some philisophical disagreements with the way
> [STL] does things.
They don't use inheritence - true. But that gains a lot of
efficiency since all the little functions (operator++ etc) are
inlined. I think that STL is an eficient and usuable solution
to a wide variety of problems (but maybe not yours ...)
> My dev platform is VC++ under windows and the STL
> implementation Microsquish ships makes it almost unusable
The STL from http://www.ipmce.su/~fbp/stl/ works well with VC++
4.0, 4.1 and 4.2 . They say it is "partially compatible" with 5.0 .
Good luck!
> [STL] does things.
They don't use inheritence - true. But that gains a lot of
efficiency since all the little functions (operator++ etc) are
inlined. I think that STL is an eficient and usuable solution
to a wide variety of problems (but maybe not yours ...)
> My dev platform is VC++ under windows and the STL
> implementation Microsquish ships makes it almost unusable
The STL from http://www.ipmce.su/~fbp/stl/ works well with VC++
4.0, 4.1 and 4.2 . They say it is "partially compatible" with 5.0 .
Good luck!
ASKER
Inheritance is one of the things, but yes it is understanable not to use it for speed. I think my biggest gripe is actually the naming conventions...maybe they will grow on me..
I'll give that stl version a look... I'll be impressed if it is still nice under VC++
thanks
I'll give that stl version a look... I'll be impressed if it is still nice under VC++
thanks
ASKER
Adjusted points to 150
> I'll give that stl version a look... I'll be impressed if it is
> still nice under VC++
I just found out that there is an STL version adapted for VC5
available from:
http://www.sirius.com/~ouchida/
> still nice under VC++
I just found out that there is an STL version adapted for VC5
available from:
http://www.sirius.com/~ouchida/
ASKER
also, reason why I wanted this...(if you want to try a solution to this add a comment and I'll up the points)
I have a vector class. I am creating an external iterating class
I would like the same itr class to be used for iterating on const vector's and non-const vector's. I was going to keep a state variable as to what the itr was contructed with (a Vector& or a const vector&) and in the T& op * throw an exception if we were itring on a const vector&...