By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,385 Members | 1,737 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,385 IT Pros & Developers. It's quick & easy.

Is this the 'prefered' way to use a vector

P: n/a
Hi,

I am going to use quite a few vectors and I want to make sure I am using it
properly.

//
struct MYSTRUCT
{
....
}

std::vector< MYSTRUCT > m_vMyStruct;
//
// ...
//
MYSTRUCT * GetItem( unsigned nItem )const
{
return ( nItem >=
m_vMyStruct.size()?NULL:((MYSTRUCT*)&(m_vMyStruct->begin()+nItem)));
}
//
// ...
//
// and can I also have
const MYSTRUCT * GetItem( unsigned nItem )const
{
return ( nItem >= m_vMyStruct.size()?NULL:((const
MYSTRUCT*)&(m_vMyStruct->begin()+nItem)));
}
//

can I declare both const and non-const functions?
Is there a better way to get/use a vector value?

many thanks

Simon
Dec 10 '05 #1
Share this Question
Share on Google+
33 Replies


P: n/a
Simon wrote:
Hi,

I am going to use quite a few vectors and I want to make sure I am using it
properly.

//
struct MYSTRUCT
{
...
}
Don't use all caps for a struct:

struct myStruct;

std::vector< MYSTRUCT > m_vMyStruct;
std::vector<myStruct> vec;

MYSTRUCT * GetItem( unsigned nItem )const
you can only use const at the end of a function declaration is this
were a member function - which it does not appear to be.
{
return ( nItem >=
m_vMyStruct.size()?NULL:((MYSTRUCT*)&(m_vMyStruct->begin()+nItem)));
}
Congrats. You've just recreated the wheel. Get rid of your function
and just use:
vec[nItem];
// and can I also have
const MYSTRUCT * GetItem( unsigned nItem )const
{
return ( nItem >= m_vMyStruct.size()?NULL:((const
MYSTRUCT*)&(m_vMyStruct->begin()+nItem)));
}
You've reinvented the wheel - again. Get rid of your function and just
use:
vec[nItem];
It's already overloaded for const and non-const versions.
can I declare both const and non-const functions?
No, unless these are members functions - which they are not.
Is there a better way to get/use a vector value?


As I showed you. You need to get yourself a decent book on using the
standard library. Try Josuttis' The C++ Standard Library.

Best regards,

Tom.

Dec 10 '05 #2

P: n/a

Simon wrote:
Hi,

I am going to use quite a few vectors and I want to make sure I am using it
properly.

//
struct MYSTRUCT
{
...
}
missing semicolon at the end of struct.

std::vector< MYSTRUCT > m_vMyStruct;
//
// ...
//
MYSTRUCT * GetItem( unsigned nItem )const
{
"const" method qualifier can only be used for member functions. Did you
want GetItem as member function of some class?
return ( nItem >=
m_vMyStruct.size()?NULL:((MYSTRUCT*)&(m_vMyStruct->begin()+nItem)));
}
// // ...
//
// and can I also have
const MYSTRUCT * GetItem( unsigned nItem )const
{
return ( nItem >= m_vMyStruct.size()?NULL:((const
MYSTRUCT*)&(m_vMyStruct->begin()+nItem)));
}
//

can I declare both const and non-const functions?


You mean to say functions with _return types_ as const and non-const.
No. functions cannot be overloaded on the basis of return type alone.
But they can be overloaded as far as const method qualifier is
concerned.

As an aside, it makes no sense to return a "constant pointer" by value
- the pointer is returned by value and hence anyways you will make a
copy of it in the caller. Note that it is the _pointer_ which is
constant, not the data pointed by that pointer.

Finally, if m_vMyStruct is a public variable then it makes no sense to
have get-set functions for it. But it seems that you wanted to wrap
them in a class.

hope that helps.

Dec 10 '05 #3

P: n/a

Simon skrev:
Hi,

I am going to use quite a few vectors and I want to make sure I am using it
properly.

//
struct MYSTRUCT
{
...
}
You should reserve all-uppercase names for macroes only.
std::vector< MYSTRUCT > m_vMyStruct;
//
// ...
//
MYSTRUCT * GetItem( unsigned nItem )const
{
return ( nItem >=
m_vMyStruct.size()?NULL:((MYSTRUCT*)&(m_vMyStruct->begin()+nItem)));
it should be m_vMyStruct.begin() instead of m_vMyStruct->begin().
m_vMyStruct is not a pointer!
Your code is wrong. m_vMyStruct.begin()+nItem would be an iterator, so
you would return a pointer to an iterator.

Also beware that your pointers will not be valid as soon as you begin
removing or adding elements to m_vMyStruct.

Why not simply &m_vMyStruct[nItem]? }
//
// ...
//
// and can I also have
const MYSTRUCT * GetItem( unsigned nItem )const
{
return ( nItem >= m_vMyStruct.size()?NULL:((const
MYSTRUCT*)&(m_vMyStruct->begin()+nItem)));
}
//

can I declare both const and non-const functions?
Is there a better way to get/use a vector value? For getting a vector value, you normally use val = vec[i]; for setting
it you simply write vec[i] = val.
But what you have shown us is not an interface for setting/getting
vector values. You have shown us a getter/setter for a class that
internally stores values in a vector.
many thanks

Simon


/Peter

Dec 10 '05 #4

P: n/a
>> //
struct MYSTRUCT
Don't use all caps for a struct:


I didn't know that, I usually have all caps for my structs, i am not sure
where i picked up that habit

std::vector< MYSTRUCT > m_vMyStruct;


std::vector<myStruct> vec;


why did you change the name to "vec"?

MYSTRUCT * GetItem( unsigned nItem )const
you can only use const at the end of a function declaration is this
were a member function - which it does not appear to be.
{
return ( nItem >=
m_vMyStruct.size()?NULL:((MYSTRUCT*)&(m_vMyStruct->begin()+nItem)));
}


Congrats. You've just recreated the wheel. Get rid of your function


do you mean i should have done,

//
MYSTRUCT * GetItem( unsigned nItem )
{
return &vec[nItem];
}
//

or get rid of the function all together?
What if nItem is >= vec.size()?

No, unless these are members functions - which they are not.
Is there a better way to get/use a vector value?


As I showed you. You need to get yourself a decent book on using the
standard library. Try Josuttis' The C++ Standard Library.


Will have a look at it, thanks.

Regards.
Simon
Dec 10 '05 #5

P: n/a
>
"const" method qualifier can only be used for member functions. Did you
want GetItem as member function of some class?
yes, but I didn't know that you could not do it to non member functions.

can I declare both const and non-const functions?


You mean to say functions with _return types_ as const and non-const.


Yes.

As an aside, it makes no sense to return a "constant pointer" by value
why? that way I can use certain values, but not change them.
- the pointer is returned by value and hence anyways you will make a
copy of it in the caller. Note that it is the _pointer_ which is
constant, not the data pointed by that pointer.
I didn't think of that.
My compiler, (.NET), does not allow me to change values of a const pointer.
Finally, if m_vMyStruct is a public variable then it makes no sense to
have get-set functions for it. But it seems that you wanted to wrap
them in a class.
No, it will not be public.
Sorry, my example was not cleat enough.

hope that helps.


Many thanks

Simon
Dec 10 '05 #6

P: n/a
>>
std::vector< MYSTRUCT > m_vMyStruct;
//
// ...
//
MYSTRUCT * GetItem( unsigned nItem )const
{
return ( nItem >=
m_vMyStruct.size()?NULL:((MYSTRUCT*)&(m_vMyStruct->begin()+nItem)));
it should be m_vMyStruct.begin() instead of m_vMyStruct->begin().


Yes, of course, sorry.
Your code is wrong. m_vMyStruct.begin()+nItem would be an iterator, so
you would return a pointer to an iterator.
I thought that the pointer to an iterator was in fact the same as
&m_vMyStruct[nItem]
or, in other words.
&m_vMyStruct[nItem] == (m_vMyStruct.begin()+nItem)
Also beware that your pointers will not be valid as soon as you begin
removing or adding elements to m_vMyStruct.

Why not simply &m_vMyStruct[nItem]?
What if nItem is > than m_vMyStruct.size()?

/Peter


Thanks

Simon

Dec 10 '05 #7

P: n/a
Simon wrote:
As an aside, it makes no sense to return a "constant pointer" by value


why? that way I can use certain values, but not change them.


Note that you can _never_ change a _value_ :
Eg:
int f(int x)
{
int p = 5;
return p;
}

Here you are returning _rvalue_ 10, and since you are not returning an
_lvalue_ you can only use f on RHS of some expression

f(10) = 100; // ERROR

Thus, values are automatically const (non-changable), So it doesnot
make sense to return "const value" from a function. Use const return
type only when you are returning references.

As an aside, returning by value is inefficient since it leads to an
extra call to Copy constructor (though compilers can optimize that
away).

Dec 10 '05 #8

P: n/a
Simon wrote:
Why not simply &m_vMyStruct[nItem]?


What if nItem is > than m_vMyStruct.size()?


If you want to worry about the bounds then use m_vMyStruct.at(nItem) -
this will throw out_of_range exception

Dec 10 '05 #9

P: n/a

Simon wrote:
std::vector<myStruct> vec;

//
MYSTRUCT * GetItem( unsigned nItem )
{
return &vec[nItem];
}
//

or get rid of the function all together?
What if nItem is >= vec.size()?


Then you have undefined behaviour, exactly as you would by reading or
writing past the bounds of an array. It is your job as a programmer to
make sure the logic of your code doesn't allow that to happen.

If that's not possible, you can get range checked access to a
std::vector using the member function at

vec.at(nItem);

which will throw std::out_of_range if nItem >= vec.size();

Gavin Deane

Dec 10 '05 #10

P: n/a

Simon wrote:
std::vector< MYSTRUCT > m_vMyStruct;
MYSTRUCT * GetItem( unsigned nItem )const
{
return ( nItem >=
m_vMyStruct.size()?NULL:((MYSTRUCT*)&(m_vMyStruct->begin()+nItem)));

<snip>
Your code is wrong. m_vMyStruct.begin()+nItem would be an iterator, so
you would return a pointer to an iterator.


I thought that the pointer to an iterator was in fact the same as
&m_vMyStruct[nItem]
or, in other words.
&m_vMyStruct[nItem] == (m_vMyStruct.begin()+nItem)


The type of the expression on the left is MYSTRUCT*
The type of the expression on the right is
std::vector<MYSTRUCT>::iterator which is an implementation defined
typedef.

It is possible that std::vector<T>::iterator is a typedef for T*, but
you can't rely on it. And since it's an implementation detail of
std::vector, you shouldn't even think about it.

The (corrected) expression in your code was

(MYSTRUCT*)&(m_vMyStruct.begin()+nItem)

so you are taking the address of the iterator, i.e. you are taking a
*pointer to* an iterator and casting it to a MYSTRUCT*.

Even if you could guarantee that std::vector<MYSTRUCT>::iterator was a
typedef for MYSTRUCT*, your code would still be wrong because it would
be casting a MYSTRUCT** to a MYSTRUCT*.

The moment you felt the need to write a cast in your code should have
been the moment you stopped and realised you must be doing something
wrong. There is a simple rule for casting:

Never, *ever* cast *anything* unless you know exactly why you are doing
it and why you can't write your code another way.

Casting says to the compiler "throw your comprehensive understanding of
the language rules away because I know what I'm doing". The compiler is
your friend. If you are going to overrule it, you'd better be sure you
know why. And use C++ style casts rather than C style. They can be
safer and are much more obvious in the code.

Gavin Deane

Dec 10 '05 #11

P: n/a
>>
or get rid of the function all together?
What if nItem is >= vec.size()?
Then you have undefined behaviour, exactly as you would by reading or
writing past the bounds of an array. It is your job as a programmer to
make sure the logic of your code doesn't allow that to happen.


er..that is why I was using functions in the first place, (see my OP), but I
was advised not to do it, hence the reason I was asking.

If that's not possible, you can get range checked access to a
std::vector using the member function at

vec.at(nItem);

which will throw std::out_of_range if nItem >= vec.size();

Gavin Deane


Simon
Dec 10 '05 #12

P: n/a
>
Note that you can _never_ change a _value_ :
Eg:
int f(int x)
{
int p = 5;
return p;
}
that's not quite what i was doing.
I was more doing.

int p;

int f( int x )
{
p = 5;
return p;
}

Here you are returning _rvalue_ 10, and since you are not returning an
_lvalue_ you can only use f on RHS of some expression

f(10) = 100; // ERROR

Thus, values are automatically const (non-changable), So it doesnot
make sense to return "const value" from a function. Use const return
type only when you are returning references.
but if i return a pointer then i can do it.

int *p = new int;

int*f()
{
return p;
}

As an aside, returning by value is inefficient since it leads to an
extra call to Copy constructor (though compilers can optimize that
away).


Simon
Dec 10 '05 #13

P: n/a

Simon wrote:

or get rid of the function all together?
What if nItem is >= vec.size()?


Then you have undefined behaviour, exactly as you would by reading or
writing past the bounds of an array. It is your job as a programmer to
make sure the logic of your code doesn't allow that to happen.


er..that is why I was using functions in the first place, (see my OP), but I
was advised not to do it, hence the reason I was asking.


Why were you advised not to do it?

Dec 10 '05 #14

P: n/a

Simon wrote:

but if i return a pointer then i can do it.

int *p = new int;

int*f()
{
return p;
}


Probably you are missing the point that what you are returning is still
a "value", this time it is simply a value of pointer

int *f() { .. } // returns int*
const int* f() { ... } // returns a pointer which is constant, but
thats ok, Return value can anyways not be modified unless it is a
reference. So the const qualifier doesnot add any extra information

const int& f() { ... } // Yeah, this makes sense, now you cannot use
f() on LHS of an expression

int& f() { ...} // Since you are returning a reference, you can use it
in expressions like f() = 10.
HTH.

Dec 10 '05 #15

P: n/a

Simon wrote:

or get rid of the function all together?
What if nItem is >= vec.size()?


Then you have undefined behaviour, exactly as you would by reading or
writing past the bounds of an array. It is your job as a programmer to
make sure the logic of your code doesn't allow that to happen.


er..that is why I was using functions in the first place, (see my OP), but I
was advised not to do it, hence the reason I was asking.


Why were you advised not to do it? Where does the value of nItem come
from?

If it is comes from somewhere outside your program then of course you
need to cope with it being out of range and if you don't want the
exception throwing behaviour of the at member function then writing
your own function that checks nItem against the vector size is the
right thing to do.

Gavin Deane

Dec 10 '05 #16

P: n/a

de*********@hotmail.com wrote:
Why were you advised not to do it?


and intended to write some more, but hit the Post Message button by
accident. Sorry. See my next post.

Dec 10 '05 #17

P: n/a
>> >> or get rid of the function all together?
>> What if nItem is >= vec.size()?
>
> Then you have undefined behaviour, exactly as you would by reading or
> writing past the bounds of an array. It is your job as a programmer to
> make sure the logic of your code doesn't allow that to happen.


er..that is why I was using functions in the first place, (see my OP),
but I
was advised not to do it, hence the reason I was asking.


Why were you advised not to do it?


Tom, said that I should not re-invent the wheel and rather use &vec[nItem];

I asked if I should get rid of my function altogether.

Simon
Dec 10 '05 #18

P: n/a
On 10 Dec 2005 09:39:47 -0800, de*********@hotmail.com wrote:

Simon wrote:
>>
>> or get rid of the function all together?
>> What if nItem is >= vec.size()?
>
> Then you have undefined behaviour, exactly as you would by reading or
> writing past the bounds of an array. It is your job as a programmer to
> make sure the logic of your code doesn't allow that to happen.


er..that is why I was using functions in the first place, (see my OP), but I
was advised not to do it, hence the reason I was asking.


Why were you advised not to do it?


See the first response in this thread. He wasn't advised not to use
"functions" per se, but to get rid of his OWN functions which were
adding an offset to the address of the first element instead of using
either operator[] or at().

--
Bob Hairgrove
No**********@Home.com
Dec 10 '05 #19

P: n/a
>
If it is comes from somewhere outside your program then of course you
need to cope with it being out of range and if you don't want the
exception throwing behaviour of the at member function then writing
your own function that checks nItem against the vector size is the
right thing to do.


You seem to be missing my original post, or i am not really folowing you.

================Original ==============
Hi,

I am going to use quite a few vectors and I want to make sure I am using it
properly.

//
struct MYSTRUCT
{
....
}

std::vector< MYSTRUCT > m_vMyStruct;
//
// ...
//
MYSTRUCT * GetItem( unsigned nItem )const
{
return ( nItem >=
m_vMyStruct.size()?NULL:((MYSTRUCT*)&(m_vMyStruct->begin()+nItem)));
}
//
// ...
//
// and can I also have
const MYSTRUCT * GetItem( unsigned nItem )const
{
return ( nItem >= m_vMyStruct.size()?NULL:((const
MYSTRUCT*)&(m_vMyStruct->begin()+nItem)));
}
//

can I declare both const and non-const functions?
Is there a better way to get/use a vector value?

many thanks

Simon

Dec 10 '05 #20

P: n/a
>>
Why were you advised not to do it?


See the first response in this thread. He wasn't advised not to use
"functions" per se, but to get rid of his OWN functions which were
adding an offset to the address of the first element instead of using
either operator[] or at().


So to make sure I understand, I should use

MYSTRUCT * GetItem( unsigned nItem )
{
return (nItem>=vec.size())?NULL:&vec[nItem]);
}

Simon
Dec 10 '05 #21

P: n/a
Simon wrote:
er..that is why I was using functions in the first place, (see my OP),
but I
was advised not to do it, hence the reason I was asking.


Why were you advised not to do it?


Tom, said that I should not re-invent the wheel and rather use &vec[nItem];

I asked if I should get rid of my function altogether.


Ah, OK. I thought you meant you had written your code and someone had
advised you not to do it like that, *then* you came here to ask about
it.

My misunderstanding.

Gavin Deane

Dec 10 '05 #22

P: n/a
On Sat, 10 Dec 2005 17:54:33 -0000, "Simon" <sp********@example.com>
wrote:

Why were you advised not to do it?


See the first response in this thread. He wasn't advised not to use
"functions" per se, but to get rid of his OWN functions which were
adding an offset to the address of the first element instead of using
either operator[] or at().


So to make sure I understand, I should use

MYSTRUCT * GetItem( unsigned nItem )
{
return (nItem>=vec.size())?NULL:&vec[nItem]);
}

Simon


Yes, this was what he was suggesting. However, it looks like you have
an extra parenthesis in the expression.

--
Bob Hairgrove
No**********@Home.com
Dec 10 '05 #23

P: n/a
Simon wrote:
[redacted]

//
struct MYSTRUCT
{
...
}

std::vector< MYSTRUCT > m_vMyStruct;
//
// ...
//
MYSTRUCT * GetItem( unsigned nItem )const
{
return ( nItem >=
m_vMyStruct.size()?NULL:((MYSTRUCT*)&(m_vMyStruct->begin()+nItem)));
You need to add a * before the & on this, or just use
&m_vMyStruct[nItem]. See below
}

// and can I also have
const MYSTRUCT * GetItem( unsigned nItem )const
{
return ( nItem >= m_vMyStruct.size()?NULL:((const
MYSTRUCT*)&(m_vMyStruct->begin()+nItem))); return ( nitem >= m_vMyStruct.size()
? 0
: &m_vMyStruct[nItem]); }

Dec 10 '05 #24

P: n/a
Simon wrote:

struct MYSTRUCT


Don't use all caps for a struct:


I didn't know that, I usually have all caps for my structs, i am not sure
where i picked up that habit


When you were programming in C?
std::vector< MYSTRUCT > m_vMyStruct;


std::vector<myStruct> vec;


why did you change the name to "vec"?


I'm pretty sure that's not important at all here.

Cheers
--
Mateusz Loskot
http://mateusz.loskot.net

Dec 10 '05 #25

P: n/a
de*********@hotmail.com wrote:
Simon wrote:

What if nItem is >= vec.size()?


Then you have undefined behaviour, exactly as you would by reading or
writing past the bounds of an array. It is your job as a programmer to
make sure the logic of your code doesn't allow that to happen.

If that's not possible, you can get range checked access to a
std::vector using the member function at

vec.at(nItem);

which will throw std::out_of_range if nItem >= vec.size();


OK, but what's wrong with checking if given index exceeds size of
vector and if it does then return NULL? In the original version of
GetItem function author returns MYSTRUCT* so NULL maybe expected.
Certainly, client of this function is required to check for NULL.

Cheers
--
Mateusz Loskot
http://mateusz.loskot.net

Dec 10 '05 #26

P: n/a
Simon wrote:

Why were you advised not to do it?


See the first response in this thread. He wasn't advised not to use
"functions" per se, but to get rid of his OWN functions which were
adding an offset to the address of the first element instead of using
either operator[] or at().


So to make sure I understand, I should use

MYSTRUCT * GetItem( unsigned nItem )
{
return (nItem>=vec.size())?NULL:&vec[nItem]);
}

And more precisely:

// something.h
MYSTRUCT * GetItem( unsigned nItem ) const;

// something.cpp
MYSTRUCT * GetItem( unsigned nItem )
{
return (nItem>=vec.size())?NULL:&vec[nItem]);
}

So, remember to set accessors as const - they not (should not) change
internal state of the object.

Cheers
--
Mateusz Loskot
http://mateusz.loskot.net

Dec 10 '05 #27

P: n/a

Mateusz Loskot wrote:
de*********@hotmail.com wrote:
Simon wrote:

What if nItem is >= vec.size()?

OK, but what's wrong with checking if given index exceeds size of
vector and if it does then return NULL? In the original version of
GetItem function author returns MYSTRUCT* so NULL maybe expected.
Certainly, client of this function is required to check for NULL.


Assuming it is reasonable for the program to expect the index to
sometimes be out of range, there is nothing wrong with it at all. I had
misunderstood the context of the OP's question.

Gavin Deane

Dec 11 '05 #28

P: n/a
On 10 Dec 2005 15:20:27 -0800, "Mateusz Loskot" <ma*****@loskot.net>
wrote:
And more precisely:

// something.h
MYSTRUCT * GetItem( unsigned nItem ) const;

// something.cpp
MYSTRUCT * GetItem( unsigned nItem )
{
return (nItem>=vec.size())?NULL:&vec[nItem]);
}
??? No class specifier, no const ???
So, remember to set accessors as const - they not (should not) change
internal state of the object.


You really meant this:

// something.h
// assume that MYSTRUCT has been defined somewhere...
class something {
vector<MYSTRUCT> vec;
public:
MYSTRUCT * GetItem( unsigned nItem ) const;
// other public functions ...
};

// something.cpp
#include "something.h"
MYSTRUCT * something::GetItem( unsigned nItem ) const
{
return (nItem>=vec.size())?NULL:&vec[nItem]);
}

???
--
Bob Hairgrove
No**********@Home.com
Dec 11 '05 #29

P: n/a
de*********@hotmail.com wrote:
Mateusz Loskot wrote:
de*********@hotmail.com wrote:
Simon wrote:
>
> What if nItem is >= vec.size()?


OK, but what's wrong with checking if given index exceeds size of
vector and if it does then return NULL? In the original version of
GetItem function author returns MYSTRUCT* so NULL maybe expected.
Certainly, client of this function is required to check for NULL.


Assuming it is reasonable for the program to expect the index to
sometimes be out of range, there is nothing wrong with it at all. I had
misunderstood the context of the OP's question.

Yes, you're right. Another of thoughts is that everytime when you
return/expect pointer there is a chance you will get null pointer.
Contract based on pointers _seems_ to be less tight than contract based
on references (reference refer to existing object).

Cheers
--
Mateusz Loskot
http://mateusz.loskot.net

Dec 11 '05 #30

P: n/a
Bob Hairgrove wrote:
On 10 Dec 2005 15:20:27 -0800, "Mateusz Loskot" <ma*****@loskot.net>
wrote:
And more precisely:

// something.h
MYSTRUCT * GetItem( unsigned nItem ) const;

// something.cpp
MYSTRUCT * GetItem( unsigned nItem )
{
return (nItem>=vec.size())?NULL:&vec[nItem]);
}


??? No class specifier, no const ???


Definitely, you are right!
I had in mind we those GetItem _will_be_ a class member, so that's my
copy & paste mistakce.
So, remember to set accessors as const - they not (should not) change
internal state of the object.


You really meant this:

// something.h
// assume that MYSTRUCT has been defined somewhere...
class something {
vector<MYSTRUCT> vec;
public:
MYSTRUCT * GetItem( unsigned nItem ) const;
// other public functions ...
};

// something.cpp
#include "something.h"
MYSTRUCT * something::GetItem( unsigned nItem ) const
{
return (nItem>=vec.size())?NULL:&vec[nItem]);
}

???


Definitely and extremely YES.
As I said, while copying & pasting I had class and its methods in mind.

Thanks for admonishing me for that.

Cheers
--
Mateusz Loskot
http://mateusz.loskot.net

Dec 11 '05 #31

P: n/a

Mateusz Loskot wrote:
de*********@hotmail.com wrote:
Assuming it is reasonable for the program to expect the index to
sometimes be out of range, there is nothing wrong with it at all. I had
misunderstood the context of the OP's question.


Yes, you're right. Another of thoughts is that everytime when you
return/expect pointer there is a chance you will get null pointer.
Contract based on pointers _seems_ to be less tight than contract based
on references (reference refer to existing object).


Which is why you shouldn't use pointers in that way unless a null
pointer, i.e. no object, is meaningful in your program (as it seems to
be for the OP). If it is meaningful then you have to use pointers.

Use references when you can and pointers when you must.

Gavin Deane

Dec 11 '05 #32

P: n/a
de*********@hotmail.com wrote:
Mateusz Loskot wrote:
de*********@hotmail.com wrote:
Assuming it is reasonable for the program to expect the index to
sometimes be out of range, there is nothing wrong with it at all. I had
misunderstood the context of the OP's question.


Yes, you're right. Another of thoughts is that everytime when you
return/expect pointer there is a chance you will get null pointer.
Contract based on pointers _seems_ to be less tight than contract based
on references (reference refer to existing object).


Which is why you shouldn't use pointers in that way unless a null
pointer, i.e. no object, is meaningful in your program (as it seems to
be for the OP). If it is meaningful then you have to use pointers.

Use references when you can and pointers when you must.


Definitely agreed.
Thanks
--
Mateusz Loskot
http://mateusz.loskot.net

Dec 11 '05 #33

P: n/a
On Sat, 10 Dec 2005 09:40:42 -0800, Neelesh Bodas wrote:
Probably you are missing the point that what you are returning is still
a "value", this time it is simply a value of pointer

int *f() { .. } // returns int*
So you can do:

*(f()) = 3;
const int* f() { ... }


But here:

*(f()) = 3;

will not compile because the pointee is constant.

So it does make a difference. (Unless I misunderstood you.)

- Jay
Dec 12 '05 #34

This discussion thread is closed

Replies have been disabled for this discussion.