'const' with return types.
ryan.tecco
Can someone tell me if:
class something {
int priv_member;
public:
const int get_private_member()
{ return priv_member; }
};
is allowed and, more importantly, makes sense. I want values that cannot
be modified once returned. Under 'g++', the complier does not complain,
but under an older version of SGI's 'CC' complier, I get a warning:
"type qualifier on return type is meaningless"
Is it meaningless (if so, how should I do what I propose) and if it's not,
am I seeing an artifact of an antique compiler?
Thanks in advance,
rt
____________
|ryan.tecco |
|734.604.9377|
|____________|
Victor Bazarov
>
> Can someone tell me if:
>
> class something {
> int priv_member;
> public:
> const int get_private_member()
> { return priv_member; }
You don't need const. You're returning the value of the private
member, not the member itself. You're COPYING the value. One
can't change the object by manipulating a copy of the object's
value...
>
> };
>
> is allowed and, more importantly, makes sense. I want values that
cannot
> be modified once returned. Under 'g++', the complier does not
complain,
> but under an older version of SGI's 'CC' complier, I get a warning:
>
> "type qualifier on return type is meaningless"
>
> Is it meaningless (if so, how should I do what I propose) and if it's
not,
> am I seeing an artifact of an antique compiler?
The value that is returned cannot be modified. It exists a fraction of
an instance just to be transferred from the function to an object that
receives it. What you're talking about is making the OBJECT THAT
RECEIVES
the value constant. So, why don't you?
something smth;
...
const int myint = smth.get_private_member(); // if you don't
// want myint changed
Of course, if you have more complex private member (not just 'int'),
you may need to return a reference to it (instead of a value). Then
it makes perfect sense (and the compiler is not going to complain)
to return a const reference:
class something {
std::string priv_member;
public:
const std::string& get_private_member() { return priv_member; }
};
Here, we return a const reference to indicate that we don't want
the object the reference refers to, changed. We're not returning
a value. You should get your ducks in a row, man. This is not
Java.
Another note: your "get_private_member" function is in violation
of one of fundamental principles of Object-Oriented Design: data
hiding. You may want to re-think your approach.
Good luck!
Victor
--
Please remove capital A's from my address when replying by mail
E. Robert Tisdale
> Can someone tell me if:
>
> class something {
> int priv_member;
> public:
> const int get_private_member(void) {
> return priv_member; }
> };
>
> is allowed
Yes, it is allowed.
> and, more importantly, makes sense.
No, it doesn't make any sense.
> I want values that cannot be modified once returned.
Does it really matter if the user writes
something s;
s.get_private_member() = 40;
and the temporary int returned by get_private_member() is overwritten?
The private data member s.priv_member isn't overwritten.
If, on the other hand, you had written
the private data member would be overwritten by
s.get_private_member() = 40;
You probably meant to write
int get_private_member(void) {
return priv_member; }
or
const int& get_private_member(void) {
return priv_member; }
Normally, you would return small objects like an int
by value and return a const reference to larger objects
but it really doesn't matter in this case
because the function is defined to be inline by default
and a good C++ compiler would optimize away any overhead.
> Under 'g++', the compiler does not complain
> but, under an older version of SGI's 'CC' compiler,
> I get a warning:
>
> "type qualifier on return type is meaningless"
>
> Is it meaningless?
> If so, how should I do what I propose?
> And, if it's not, am I seeing an artifact of an antique compiler?
No. I think it is a very nice and possibly very helpful warning.
Marco Manfredini
ryan.tecco <rte...@umich.edu> schrieb in im Newsbeitrag:
Pine.SOL.4.10.100071...@seawolf.gpcc.itd.umich.edu...
>
> Can someone tell me if:
>
> class something {
> int priv_member;
> public:
> { return priv_member; }
>
> };
>
> be modified once returned.
You can not modify what get_private_member returns, since it does not return
a reference (a place that can be modified). If you return a value, its
constness does not infect the variables you assign it to.
somthing s;
int i;
i=s.get_private_member(); i=3; // i is not made const
s.get_private_member()=3; // no way, no reference is returned.
returning a const value is meaningful if you use it immediately, for example
in a member expression:
struct bla {
useit();
};
struct foo {
const bla get_bla();
}
// now...
foo x;
x.get_bla().useit(); // < doesn't work, cause useit() isn't const.
Marco
Greg Comeau
E. Robert Tisdale <ed...@netwood.net> wrote:
>"ryan.tecco" wrote:
>> Can someone tell me if:
>> class something {
>> int priv_member;
>> public:
>> return priv_member; }
>> };
>>
>> is allowed
>
>Yes, it is allowed.
>
>
At least not for int/const int.
>> I want values that cannot be modified once returned.
>
>Does it really matter if the user writes
>
> something s;
> s.get_private_member() = 40;
>
>and the temporary int returned by get_private_member() is overwritten?
But that's not allowed anyway, because the int is not an lvalue,
so even w/o the const, a diagnostic would be generated.
>The private data member s.priv_member isn't overwritten.
>If, on the other hand, you had written
>
>
???
>the private data member would be overwritten by
>
> s.get_private_member() = 40;
>
>You probably meant to write
>
> int get_private_member(void) {
> return priv_member; }
>
>or
>
> const int& get_private_member(void) {
> return priv_member; }
>
>Normally, you would return small objects like an int
>by value and return a const reference to larger objects
>but it really doesn't matter in this case
>because the function is defined to be inline by default
>and a good C++ compiler would optimize away any overhead.
>
>> Under 'g++', the compiler does not complain
>> but, under an older version of SGI's 'CC' compiler,
>> I get a warning:
>>
>> "type qualifier on return type is meaningless"
>>
>> Is it meaningless?
>> If so, how should I do what I propose?
>> And, if it's not, am I seeing an artifact of an antique compiler?
>
>No. I think it is a very nice and possibly very helpful warning.
Comeau C++ gives a similar warning.
Anyway, as you note, this really only applies when the return
type is a builting type. If it's a reference, a pointer, or a class,
then it may may perfect sense to have the const (in which case,
no warning is necessary, and getting one in these cases would be
inappropriate).
- Greg
--
Comeau Computing / Comeau C/C++ 4.2.42 (4.2.44 expected soon)
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: com...@comeaucomputing.com / WEB: http://www.comeaucomputing.com
Mark Wilden
news:8kidr0$rs5$1...@bob.news.rcn.net...
> Another note: your "get_private_member" function is in violation
> of one of fundamental principles of Object-Oriented Design: data
> hiding. You may want to re-think your approach.
Eh? A class stores some data in a member variable, but isn't allowed to tell
anyone what it is?
Victor Bazarov
Of course, it is allowed to. I am not about to deny anybody the right
to
expose themselves. If you want to wrap your data in a class and pretend
it's object-oriented programming, who am I to interfere?
E. Robert Tisdale
> Victor Bazarov <vAba...@dAnai.com> wrote in message
> news:8kidr0$rs5$1...@bob.news.rcn.net...
>
> > Another note: your "get_private_member" function is in violation
> > of one of fundamental principles of Object-Oriented Design: data
> > hiding. You may want to re-think your approach.
>
> Eh? A class stores some data in a member variable,
> but isn't allowed to tell anyone what it is?
Vallon should note that Victor rarely gives bad advice
without immediate correction by some other subscriber;-)
E. Robert Tisdale
> Of course, it is allowed to.
> I am not about to deny anybody the right to expose themselves.
> If you want to wrap your data in a class
> and pretend it's object-oriented programming,
> who am I to interfere?
You're going to lose this one Victor.
Class library developers hide the data representation
so that they can change the representation later
if it is necessary or convenient to do so.
Access to private data members is restricted to member functions
so that the library developers don't need to change anything
except the member functions if the data representation changes.
Member functions may return a non const reference
to a private data member but class library users
should not convert the reference to a pointer
because the class library developer
may need to change the return type
if the data representation changes.
Mark Wilden
> "Mark Wilden" <ma...@pagm.com> wrote...
> >
> > A class stores some data in a member variable, but isn't allowed to tell
anyone what it is?
>
> expose themselves. If you want to wrap your data in a class and pretend
> it's object-oriented programming, who am I to interfere?
Are you saying the following isn't OOP?
class Employee {
// ...
public:
int getID() { return id; }
private:
int id;
};
What would be the point of storing the employee's ID if no one were allowed
to find out what it was?
(BTW, a more substantive response--i.e., the reasons for your
statement--would've saved time.)
Victor Bazarov
> Victor Bazarov <vAba...@dAnai.com> wrote in message
> news:8kihc6$lll$1...@bob.news.rcn.net...
> > "Mark Wilden" <ma...@pagm.com> wrote...
> > >
> > > A class stores some data in a member variable, but isn't allowed
to tell
> anyone what it is?
> >
> > Of course, it is allowed to. I am not about to deny anybody the
right to
> > expose themselves. If you want to wrap your data in a class and
pretend
> > it's object-oriented programming, who am I to interfere?
>
> Are you saying the following isn't OOP?
>
> class Employee {
> // ...
> public:
> int getID() { return id; }
> private:
> int id;
> };
>
> What would be the point of storing the employee's ID if no one were
allowed
> to find out what it was?
I am not sure there is a point of storing the ID. You tell me.
What *is* the point of storing the ID? Definitely not to return
it. You may need to IDentify a particular employee, or a department
where that employee works, or any other purpose. However, for that
you don't need to (a) know HOW the ID is stored (int/string/etc.)
and (b) retrieve the ID directly (by the way, stripping all the info
about it as *ID*). What the OOD suggests is to define a class empID
that you'd store in your Employee, and give to an authority figure
(an ID_Verifier of some sort). Whether you want it implemented as
int or anything else SHOULDN'T MATTER. How it is all done is a
different question. I am not really in the mood right now to design
a good OO system for identification of employees. It was just an
example. Data hiding principle is one of the bases of OOP and
the margins of this e-mail are too narrow to present to you the
justification of that. Sorry.
Check out news:comp.object. Don't post there right away, just lurk
for a while. See what books people suggest, see what problems people
solve. Take a look at James Coplien's "Advanced C++", you might even
find it useful reading.
> (BTW, a more substantive response--i.e., the reasons for your
> statement--would've saved time.)
Well, I shoud've suggested a course on OOD and OOP. BTW, taking
it BEFORE or DURING studying C++ would've saved time.
Mark Wilden
> I wrote:
> > What would be the point of storing the employee's ID if no one were
> allowed
> > to find out what it was?
>
> I am not sure there is a point of storing the ID. You tell me.
Read Date.
> What *is* the point of storing the ID? Definitely not to return
> it. You may need to IDentify a particular employee, or a department
> where that employee works, or any other purpose.
You may also need it to retrieve or update or delete the associated record
in a relational database. At any rate, if you don't understand that example,
there are plenty of others.
You seem to be saying that classes shouldn't return data that they store as
private members. Yet surely classes must be permitted to return _some_ data.
Why then the restriction on not returning that data which just happens to be
stored as private members? This is just an implementation detail, and
shouldn't affect the interface.
> Data hiding principle is one of the bases of OOP and
> the margins of this e-mail are too narrow to present to you the
> justification of that.
Data hiding is one thing; making it utterly inaccessible is another. :)
> Take a look at James Coplien's "Advanced C++", you might even find it
useful reading.
Coplien really isn't the best source for learning OOP. I would recommend
Meyer, Rumbaugh, Cox or (possibly) Booch before suggesting that a newbie
learn about C++ idioms.
> > (BTW, a more substantive response--i.e., the reasons for your
> > statement--would've saved time.)
>
> Well, I shoud've suggested a course on OOD and OOP. BTW, taking
> it BEFORE or DURING studying C++ would've saved time.
No, simply saying "OOD" and "OOP" wasn't exactly what I meant by giving the
reasons for your belief. However, if you prefer to argue from authority, a
citation from an OOP author you like stating that accessor functions violate
OOP should be easy to provide.
Victor Bazarov
> Victor Bazarov <vAba...@dAnai.com> wrote in message
> news:8kiodi$mkj$1...@bob.news.rcn.net...
> > I wrote:
> > > What would be the point of storing the employee's ID if no one
were
> > allowed
> > > to find out what it was?
> >
> > I am not sure there is a point of storing the ID. You tell me.
>
> Read Date.
Huh? Please dis-ambiguate the sentence.
>
> > What *is* the point of storing the ID? Definitely not to return
> > it. You may need to IDentify a particular employee, or a department
> > where that employee works, or any other purpose.
>
> You may also need it to retrieve or update or delete the associated
record
> in a relational database. At any rate, if you don't understand that
example,
> there are plenty of others.
At any rate, if YOU are not prepared to explain, there is no point to
continue the conversation, now is there? BTW, if instead of personal
insults you just gave another example, it would've saved time.
>
> You seem to be saying that classes shouldn't return data that they
store as
> private members. Yet surely classes must be permitted to return _some_
data.
Well, at some depth ALL DATA is stored as ones and zeroes that have to
be moved around and operated upon. That's not the point.
> Why then the restriction on not returning that data which just happens
to be
> stored as private members? This is just an implementation detail, and
> shouldn't affect the interface.
Whatever.
>
> > Data hiding principle is one of the bases of OOP and
> > the margins of this e-mail are too narrow to present to you the
> > justification of that.
>
> Data hiding is one thing; making it utterly inaccessible is another.
:)
Whatever.
>
> > Take a look at James Coplien's "Advanced C++", you might even find
it
> useful reading.
>
> Coplien really isn't the best source for learning OOP. I would
recommend
> Meyer, Rumbaugh, Cox or (possibly) Booch before suggesting that a
newbie
> learn about C++ idioms.
Actually, I don't agree. Meyer and others are waaaaaay too pure a
science
to be understood by a newbie whose first C++ program includes cout and
overloaded operator <<. The point is that we usually learn language
constructs without learning how to use them properly. Systematising (is
there such a word) of existing heap of knowledge is easier than building
a perfect theory that some time later has to have some realisation in
practice. That's not how humans learn. C++ first, C++ idioms second,
then *real* OOD (language-less), UML, etc. I am not going to discuss
with you (or anybody else) WHY it happens this way. It just does, and
we all can see it. While it may be necessary to explain a phenomenon,
it's much easier to simply use it. This is why Stroustrup is first,
Coplien is second, then Booch, Meyer, Cox, etc.
> > > (BTW, a more substantive response--i.e., the reasons for your
> > > statement--would've saved time.)
> >
> > Well, I shoud've suggested a course on OOD and OOP. BTW, taking
> > it BEFORE or DURING studying C++ would've saved time.
>
> No, simply saying "OOD" and "OOP" wasn't exactly what I meant by
giving the
> reasons for your belief. However, if you prefer to argue from
authority, a
> citation from an OOP author you like stating that accessor functions
violate
> OOP should be easy to provide.
I prefer not to discuss OOD and OOP here. This is not exactly the
place for it. If you're so inclined, accessor functions have been
discussed in comp.object more than once. Check out the archives. And
any interested party should visit comp.object at some point. Let's not
convert this LANGUAGE newsgroup into an arena of theoretical OOP
debates.
ryan.tecco
> you may need to return a reference to it (instead of a value). Then
> it makes perfect sense (and the compiler is not going to complain)
> to return a const reference:
Now the question: what about:
const T view_data() { return data; }
For something like a data structure, could be a built in type, could be a
larger structure. Do I want to return references to built-in types to make
provisions for the cases where more complex types might be used?
rt
Victor Bazarov
That's probably not a bad idea... Actually, it depends. If you
return a reference to an object (member) in your class, then it
may be true. However, in many cases you return something completely
unrelated, then you have to construct a temporary by returning an
object instead of a reference. Compare:
template<typename T> class X
{
T t;
public:
const T& giveTheT() const { return t; }
};
and
template<typename T> class X
{
T t;
public:
template<typename U> U giveTheTAsU() const { return U(t); }
};
In the second example, type U is unrelated to X. Conversion is
performed, a temporary is returned.
Of course, the example cannot cover all possible cases and scenarios.
It's just an example.
Mark Wilden
> > Read Date.
>
> Huh? Please dis-ambiguate the sentence.
C.J. Date is probably the most preeminent database authority in the world.
> At any rate, if YOU are not prepared to explain, there is no point to
> continue the conversation, now is there?
Actually, I answered your question (why store the ID). You appeared not to
understand the ID example. I was stating a fact, not trying to be insulting.
> > Why then the restriction on not returning that data which just happens
> to be
> > stored as private members? This is just an implementation detail, and
> > shouldn't affect the interface.
>
> Whatever.
OK, I made an effort...:)
Andrey Tarasevich
"ryan.tecco" <rte...@umich.edu> wrote in message
news:Pine.SOL.4.10.100071...@seawolf.gpcc.itd.umich.edu...
>
> Can someone tell me if:
>
> class something {
> int priv_member;
> public:
> const int get_private_member()
> { return priv_member; }
>
> };
>
> is allowed and, more importantly, makes sense. I want values that cannot
> be modified once returned. Under 'g++', the complier does not complain,
> but under an older version of SGI's 'CC' complier, I get a warning:
>
> "type qualifier on return type is meaningless"
>
> Is it meaningless (if so, how should I do what I propose) and if it's not,
> am I seeing an artifact of an antique compiler?
> ...
A value returned by a function is a rvalue, unless it is a reference.
The notion of being (or not being) const-qualified is not applicable to
rvalues of non-class types ('int' in your case). A rvalue cannot be modified
just because it is a rvlaue. That's it. It doesn't make any difference
whether you const-qualify it or not. That's what your compiler is trying to
tell you.
Best regards,
Andrey Tarasevich,
Brainbench C Programming MVP
Andrey Tarasevich
"Victor Bazarov" <vAba...@dAnai.com> wrote in message
news:8kidr0$rs5$1...@bob.news.rcn.net...
> ...
> Another note: your "get_private_member" function is in violation
> of one of fundamental principles of Object-Oriented Design: data
> hiding. You may want to re-think your approach.
> ...
Wrong. The only case when OOD principles are really violated is when
public member function returns a non-const-qualified reference () to a
private/protected subobject.
Even a pair of public Get/Set methods for a private field is not a
violation of OOD principles.
Ron Natalie
"ryan.tecco" wrote:
>
> Can someone tell me if:
>
> class something {
> int priv_member;
> public:
> const int get_private_member()
> { return priv_member; }
>
> };
>
> is allowed and, more importantly, makes sense. I want values that cannot
> be modified once returned. Under 'g++', the complier does not complain,
> but under an older version of SGI's 'CC' complier, I get a warning:
>
> "type qualifier on return type is meaningless"
>
> Is it meaningless (if so, how should I do what I propose) and if it's not,
> am I seeing an artifact of an antique compiler?
It is complaing about the const on the int return. It is meaningless as you
can't change the temporary return value. If you meant the function to be const
(i.e. callable on const something objects) you wan the decl to look like:
int get_private_member() const { ...
E. Robert Tisdale
> Now the question: what about:
>
> const T something::view_data(void) const { return data; }
>
> For something like a data structure,
> could be a built in type, could be a larger structure.
> Do I want to return references to built-in types to make provisions
> for the cases where more complex types might be used?
Usually, you will want to return a const reference
const T& something::view_data(void) const { return data; }
for large objects
whether you have control over the definition of type T or not.
You should probably avoid returning a non const reference
T& something::change_data(void) { return data; }
unless you have control over the definition of type T.
That's really all that Victor is complaining about.
Stephen Cleary
I'm going to jump in with both feet here... :)
If you have a class interface that returns a reference OR a const
reference, then you are essentially forcing that class to hold a value
of that type. IF this is a(n unchangeable) part of your OOD, then
that's OK. OTOH, if it's an implementation detail, do *not* return a
reference (even a const reference).
For example, a pair type (such as boost::compressed_pair or std::pair)
is defined by design to hold one value of each type, so it can return
references to that data. OTOH, a "point" type which can return its
value in either rectangular or polar coordinates should *not* return
references to that data, because the implementation may be either.
Now let's step back from the OOD issue and address returning of
references from a language standpoint:
In general, I am against return of references (I used to support them)
ever since Darin Adler converted me with the argument:
<begin Darin Adler's example>
// You write (in library code)
struct CatalogEntry
{
...
const string & name() const;
};
struct Catalog
{
...
void remove(const string & name)
{
... // destroy CatalogEntry associated with name
cout << "Catalog Entry " << name << " was removed" << endl;
}
};
// Now consider (in user code):
void remove_entry_by_name(Catalog & c, CatalogEntry & e)
{ c.remove(e.name()); }
<end Darin Adler's example>
The obvious problem is a dangling reference (that is difficult to
catch, and may cause a visible error only sporadically).
So, the simple policy that I follow now is, for class "properties"
(that are enforced by design), I always provide by-value access:
T prop_name() const;
but (because I am an efficiency freak), I provide a tag class
("prop_byref") that lets the property accessor know it's OK to return
by reference:
const T & prop_name(prop_byref) const;
for use *only* when you *know* the danging-reference problem
illustrated above cannot occur.
And that's my two bytes about how return-of-references:
1) May or may not go against OOD (depends on design), and
2) Are dangerous, but not obviously
-Steve
Chris Kuan
>"Victor Bazarov" <vAba...@dAnai.com> wrote in message
>news:8kidr0$rs5$1...@bob.news.rcn.net...
>> ...
>> Another note: your "get_private_member" function is in violation
>> of one of fundamental principles of Object-Oriented Design: data
>> hiding. You may want to re-think your approach.
>> ...
>
> Wrong. The only case when OOD principles are really violated is when
>public member function returns a non-const-qualified reference () to a
>private/protected subobject.
> Even a pair of public Get/Set methods for a private field is not a
>violation of OOD principles.
I think Victor was more worried about the name than anything else.
--
Chris Kuan, CSC Technology Services, formerly BHP Information Technology
Concatenate for email: mr gazpacho @ hotmail . com
"Law is a repository for the aimlessly clever" - Tim Freedman
Vallons
I think that Victor was just worried.
Mark Wilden
news:396d4aa1$0$1497$2486...@news.freeway.net...
> In general, I am against return of references (I used to support them)
> ever since Darin Adler converted me with the argument:
> <begin Darin Adler's example>
> // You write (in library code)
> struct CatalogEntry
> {
> ...
> const string & name() const;
> };
>
> struct Catalog
> {
> ...
> void remove(const string & name)
> {
> ... // destroy CatalogEntry associated with name
> cout << "Catalog Entry " << name << " was removed" << endl;
> }
> };
>
> // Now consider (in user code):
> void remove_entry_by_name(Catalog & c, CatalogEntry & e)
> { c.remove(e.name()); }
> <end Darin Adler's example>
That's an interesting example, and clearly that code is incorrect--name()
must return a copy.
However, I don't believe this has anything to do with OOD; I regard
returning a const reference rather than a copy as an implementation detail,
for efficiency's sake. In particular, having name() return a reference at
first, then changing that to return a reference when it becomes needed (i.e.
after remove() is defined to take a name parameter), or, alternately,
changing remove so that _it_ takes a copy instead of a reference, doesn't
change the interface to the callers. A change that doesn't change the
interface is an implementation detail, not a design issue.
Stephen Cleary
wrote:
> A change that doesn't change the
>interface is an implementation detail, not a design issue.
The point I was trying to make is that it does change the interface,
in a very subtle way. When returning references, a reference bound to
the return value is not valid after object deletion; when returning
values, a reference bound to the return value is valid after object
deletion.
In the "big picture" OOD, of course it wouldn't matter: the object has
a property of a certain type and that's it. When specifying the class
interface, however, this becomes an issue. Note that the STL
overlooked this for iterators -- see LWG Issue #198 "Validity of
pointers and references unspecified after iterator destruction" at:
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html
-Steve
Mark Wilden
> On Thu, 13 Jul 2000 09:10:43 -0700, "Mark Wilden" <ma...@pagm.com>
> wrote:
>
> > A change that doesn't change the
> >interface is an implementation detail, not a design issue.
>
> The point I was trying to make is that it does change the interface,
> in a very subtle way.
You're right, of course. If you have code that can access the reference
after deletion, then the code is wrong, and must be fixed. I suppose that's
an interface issue.
I was thinking in terms of compile-time interface, however. If you do add a
method like your remove(), then you can change from references to copies
without changing any other code. In that sense, the interface remains the
same.
However, I did allude to the fundamental flaw of the example: the fact that
remove() takes a reference instead of a copy. It's not the fact that name()
returns a reference that's a problem: it's that remove() takes a reference
that's very likely to be into the very object it's about to delete. remove()
is wrong, not name().
Still, that in itself points out a danger in using references instead of
copies, which was your (valuable) point.