473,323 Members | 1,537 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,323 software developers and data experts.

Should I use pointer inside container?

Hi @ all!

Again one small question due to my shakiness of what to use...

What is better / smarter?

private:
vector<MyClass_t* itsVector;

OR...

private:
vector<MyClass_t * * itsVector;

How works such a stl container? Does it use heap or stack?

Thanks

Goran

Sep 8 '07 #1
18 1786
Goran wrote:
Hi @ all!

Again one small question due to my shakiness of what to use...

What is better / smarter?
STL contains requires the element to be assignable
as it copy each element you push_xxxx and insert.

So, if your element is not assignable, then you have no other way than
to use pointer as element

when your element is assignable, then you have too choose, the major
principle is that whether your element is big object.
if is then use pointer to avoid copy
>
private:
vector<MyClass_t* itsVector;

OR...

private:
vector<MyClass_t * * itsVector;

How works such a stl container? Does it use heap or stack?
you have to refer to a C++ text book or check out some implementation code.
--
Thanks
Barry
Sep 8 '07 #2
On 2007-09-08 16:04, Goran wrote:
Hi @ all!

Again one small question due to my shakiness of what to use...

What is better / smarter?

private:
vector<MyClass_t* itsVector;

OR...

private:
vector<MyClass_t * * itsVector;
None of the above, use either

std::vector<MyClassitsVector;

or

std::vector<MyClass*itsVector;

Which one you should use depends on how you will use the elements, if
you have not special needs the first one is generally preferable since
it removes the need to new and delete the elements manually.

There might be a few legitimate situations where you might need a
pointer to a vector, but I would say that it is most often a sign of bad
design.
How works such a stl container? Does it use heap or stack?
The elements contained in the vector are stored on the heap, notice
thought that for some containers, std::vector among them, the elements
might be re-located when you perform some operations on the containers,
so taking the address of an object can be hazardous.

In fact, I would say that when you find yourself using a pointer ask
yourself if you really need it. In most cases allocating on the stack or
using a reference is just as good.

--
Erik Wikström
Sep 8 '07 #3
er
On Sep 8, 10:04 am, Goran <postmasch...@gmail.comwrote:
Hi @ all!

Again one small question due to my shakiness of what to use...

What is better / smarter?

private:
vector<MyClass_t* itsVector;

OR...

private:
vector<MyClass_t * * itsVector;

How works such a stl container? Does it use heap or stack?

Thanks

Goran
quickly read this but you might want to refer to a previous post of
mine:
http://groups.google.com/group/comp....9d782f6d6dae52

also google ptr_vector

Sep 9 '07 #4
On Sep 8, 5:04 pm, Goran <postmasch...@gmail.comwrote:
Hi @ all!

Again one small question due to my shakiness of what to use...

What is better / smarter?

private:
vector<MyClass_t* itsVector;

OR...

private:
vector<MyClass_t * * itsVector;

How works such a stl container? Does it use heap or stack?

Thanks

Goran
Hi goran
In addition to the answers by others, I want to say something about
vector<MyClass_t * itsVector;
sometimes, it depends on your design. For example, if MyClass_t is an
abstract class like Shape in graphics or Piece in Chess, you should
use vector of pointers:
vector<Shapev; // wrong!
vector<Shape *v; // ok!
Finally, there should be good reasons for using pointer instead of
plain object.

Regards,
Saeed

Sep 9 '07 #5
On Sep 8, 5:27 pm, Erik Wikström <Erik-wikst...@telia.comwrote:
On 2007-09-08 16:04, Goran wrote:
Hi @ all!
Again one small question due to my shakiness of what to use...
What is better / smarter?
private:
vector<MyClass_t* itsVector;
OR...
private:
vector<MyClass_t * * itsVector;

None of the above, use either

std::vector<MyClassitsVector;

or

std::vector<MyClass*itsVector;

Which one you should use depends on how you will use the elements, if
you have not special needs the first one is generally preferable since
it removes the need to new and delete the elements manually.

There might be a few legitimate situations where you might need a
pointer to a vector, but I would say that it is most often a sign of bad
design.
How works such a stl container? Does it use heap or stack?

The elements contained in the vector are stored on the heap, notice
thought that for some containers, std::vector among them, the elements
might be re-located when you perform some operations on the containers,
so taking the address of an object can be hazardous.

In fact, I would say that when you find yourself using a pointer ask
yourself if you really need it. In most cases allocating on the stack or
using a reference is just as good.

--
Erik Wikström
I tend to consider containers as very huge objects(due to the
unpredictable number of elements),and as far as I have been digging
into my platform`s library neither of STL containers are built upon
the idea of reference counting .I simply conclude that a pointer to a
container is not really that bad.As a rookie I must respect a pro but
I do not see any reason to complaign about 'vector <T*' as you did.

regards,
FM.

Sep 9 '07 #6
On 2007-09-09 13:34, terminator wrote:
On Sep 8, 5:27 pm, Erik Wikström <Erik-wikst...@telia.comwrote:
>On 2007-09-08 16:04, Goran wrote:
Hi @ all!
Again one small question due to my shakiness of what to use...
What is better / smarter?
private:
vector<MyClass_t* itsVector;
OR...
private:
vector<MyClass_t * * itsVector;

None of the above, use either

std::vector<MyClassitsVector;

or

std::vector<MyClass*itsVector;

Which one you should use depends on how you will use the elements, if
you have not special needs the first one is generally preferable since
it removes the need to new and delete the elements manually.

There might be a few legitimate situations where you might need a
pointer to a vector, but I would say that it is most often a sign of bad
design.
How works such a stl container? Does it use heap or stack?

The elements contained in the vector are stored on the heap, notice
thought that for some containers, std::vector among them, the elements
might be re-located when you perform some operations on the containers,
so taking the address of an object can be hazardous.

In fact, I would say that when you find yourself using a pointer ask
yourself if you really need it. In most cases allocating on the stack or
using a reference is just as good.

--
Erik Wikström

I tend to consider containers as very huge objects(due to the
unpredictable number of elements),and as far as I have been digging
into my platform`s library neither of STL containers are built upon
the idea of reference counting .I simply conclude that a pointer to a
container is not really that bad.As a rookie I must respect a pro but
I do not see any reason to complaign about 'vector <T*' as you did.
The actual container is usually quite small, it's the elements contained
that are large. This means that putting a container on the stack and
inserting thousands of objects is no problem, since the objects are on
the heap. The reason I don't recommend using a pointer to a container
(and if possible not a container with pointers) is that it requires the
user to take care of creating and deleting the container (and also the
elements if using a container of pointers).

Imagine a class Foo like this:

class Foo
{
std::vector<BarbarContainer;
// ...
};

If used like this I don't have to worry about a thing, I know that all
instances will have a barContainer as soon as they are created without
writing anything in the constructor, and when the object is destroyed so
will the container (again, without putting anything in the destructor).
And, when the vector is destroyed so are the elements it contains.

If you had a pointer to the vector you need to new it in the constructor
and delete it in the destructor, or you'll be leaking memory. If you
have a pointer to the vector I'd take that as a sign that the vector is
not owned by the object, perhaps it's shared between many Foo objects or
some such.

If you have a vector of pointers, you must again implement the
destructor, and this time loop through the vector and delete each and
every element in it, or you would be leaking loads of memory.

In short use only pointers where ownership, lifetime, or efficiency
requires it, because it complicates the code.

--
Erik Wikström
Sep 9 '07 #7

terminator wrote:

I tend to consider containers as very huge objects(due to the
unpredictable number of elements),and as far as I have been digging
into my platform`s library neither of STL containers are built upon
the idea of reference counting.
Then you should have also seen that the contents of containers most
often live on the heap, making there size not much larger than a
pointer.
I simply conclude that a pointer to a
container is not really that bad.
Containers already contain pointers. Apart from the fact that one
needs
to manage a resource that was previously managed automagically,
one also has an additional level of indirection for (in the most
cases)
no reason what-so-ever. This is an example of pre-mature
pessimization.

Regards,

Werner

Sep 9 '07 #8
On Sep 9, 3:23 pm, Erik Wikström <Erik-wikst...@telia.comwrote:
On 2007-09-09 13:34, terminator wrote:


On Sep 8, 5:27 pm, Erik Wikström <Erik-wikst...@telia.comwrote:
On 2007-09-08 16:04, Goran wrote:
Hi @ all!
Again one small question due to my shakiness of what to use...
What is better / smarter?
private:
vector<MyClass_t* itsVector;
OR...
private:
vector<MyClass_t * * itsVector;
None of the above, use either
std::vector<MyClassitsVector;
or
std::vector<MyClass*itsVector;
Which one you should use depends on how you will use the elements, if
you have not special needs the first one is generally preferable since
it removes the need to new and delete the elements manually.
There might be a few legitimate situations where you might need a
pointer to a vector, but I would say that it is most often a sign of bad
design.
How works such a stl container? Does it use heap or stack?
The elements contained in the vector are stored on the heap, notice
thought that for some containers, std::vector among them, the elements
might be re-located when you perform some operations on the containers,
so taking the address of an object can be hazardous.
In fact, I would say that when you find yourself using a pointer ask
yourself if you really need it. In most cases allocating on the stack or
using a reference is just as good.
--
Erik Wikström
I tend to consider containers as very huge objects(due to the
unpredictable number of elements),and as far as I have been digging
into my platform`s library neither of STL containers are built upon
the idea of reference counting .I simply conclude that a pointer to a
container is not really that bad.As a rookie I must respect a pro but
I do not see any reason to complaign about 'vector <T*' as you did.
In short use only pointers where ownership, lifetime, or efficiency
requires it, because it complicates the code.
thats exacltly the point,when you need to share a container in
different places, or very simpler the return of a function(this one
mabye bad design).

regards,
FM.

Sep 10 '07 #9
On Sep 9, 11:09 pm, werasm <wer...@gmail.comwrote:
terminator wrote:
I tend to consider containers as very huge objects(due to the
unpredictable number of elements),and as far as I have been digging
into my platform`s library neither of STL containers are built upon
the idea of reference counting.

Then you should have also seen that the contents of containers most
often live on the heap, making there size not much larger than a
pointer.
I said huge because a container contains data spatered all over the
heap and when it comes to copy(instead of reference) ,then it does not
matter if the data is stored in a contigeous portion of memory or
segmented into peices on different corners of memory.the actual size
of a container is often much larger than its own data structure(one or
two pointers and intrinsic values as well as the vtable in runtime
polymorphic ones).

regards,
FM.

Sep 10 '07 #10
On 2007-09-10 14:16, terminator wrote:
On Sep 9, 3:23 pm, Erik Wikström <Erik-wikst...@telia.comwrote:
>On 2007-09-09 13:34, terminator wrote:


On Sep 8, 5:27 pm, Erik Wikström <Erik-wikst...@telia.comwrote:
On 2007-09-08 16:04, Goran wrote:
Hi @ all!
Again one small question due to my shakiness of what to use...
What is better / smarter?
private:
vector<MyClass_t* itsVector;
OR...
private:
vector<MyClass_t * * itsVector;
>None of the above, use either
> std::vector<MyClassitsVector;
>or
> std::vector<MyClass*itsVector;
>Which one you should use depends on how you will use the elements, if
you have not special needs the first one is generally preferable since
it removes the need to new and delete the elements manually.
>There might be a few legitimate situations where you might need a
pointer to a vector, but I would say that it is most often a sign of bad
design.
How works such a stl container? Does it use heap or stack?
>The elements contained in the vector are stored on the heap, notice
thought that for some containers, std::vector among them, the elements
might be re-located when you perform some operations on the containers,
so taking the address of an object can be hazardous.
>In fact, I would say that when you find yourself using a pointer ask
yourself if you really need it. In most cases allocating on the stack or
using a reference is just as good.
>--
Erik Wikström
I tend to consider containers as very huge objects(due to the
unpredictable number of elements),and as far as I have been digging
into my platform`s library neither of STL containers are built upon
the idea of reference counting .I simply conclude that a pointer to a
container is not really that bad.As a rookie I must respect a pro but
I do not see any reason to complaign about 'vector <T*' as you did.
>In short use only pointers where ownership, lifetime, or efficiency
requires it, because it complicates the code.

thats exacltly the point,when you need to share a container in
different places, or very simpler the return of a function(this one
mabye bad design).
If the container is a member of the class using a reference would
probably be better.

--
Erik Wikström
Sep 10 '07 #11
On Sep 10, 2:42 pm, Erik Wikström <Erik-wikst...@telia.comwrote:
On 2007-09-10 14:16, terminator wrote:
[...]
In short use only pointers where ownership, lifetime, or
efficiency requires it, because it complicates the code.
You can easily use pointers for navigation as well. Vectors or
sets of pointers aren't really that rare, when the vector or set
is only used for navigation, and doesn't imply ownership.
thats exacltly the point,when you need to share a container
in different places, or very simpler the return of a
function(this one mabye bad design).
If the container is a member of the class using a reference
would probably be better.
If the class has value semantics, a reference probably isn't a
good idea, since it creates problems for the assignment
operator.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Sep 11 '07 #12

terminator wrote:

I said huge because a container contains data spatered all over the
heap and when it comes to copy(instead of reference) ,then it does not
matter if the data is stored in a contigeous portion of memory or
segmented into peices on different corners of memory.the actual size
of a container is often much larger than its own data structure(one or
two pointers and intrinsic values as well as the vtable in runtime
polymorphic ones).
In that case I don't see how it contributes to your argument of using
a pointer to the container instead of the actual container, if I
understand you correctly, as whether one uses a pointer to
a container, or the container itself, you always going to use the
heap, and in the case of a pointer to the container, slightly more
than in the other case, as now the pointer members are also on
the heap.

As far as inside a container is concerned, it depends on the type
T. Typically, if I want to prevent copying, I use either pointers,
or even a pointer_container aka. boost::ptr_vector. If copying of
the container does not happen often, and T has the relevant
members required, then I use T (by value).

Regards,

Werner

Sep 11 '07 #13
On Sep 11, 11:03 pm, werasm <wer...@gmail.comwrote:
terminator wrote:
I said huge because a container contains data spatered all over the
heap and when it comes to copy(instead of reference) ,then it does not
matter if the data is stored in a contigeous portion of memory or
segmented into peices on different corners of memory.the actual size
of a container is often much larger than its own data structure(one or
two pointers and intrinsic values as well as the vtable in runtime
polymorphic ones).

In that case I don't see how it contributes to your argument of using
a pointer to the container instead of the actual container, if I
understand you correctly, as whether one uses a pointer to
a container, or the container itself, you always going to use the
heap, and in the case of a pointer to the container, slightly more
than in the other case, as now the pointer members are also on
the heap.
only dynamic objects are placed on heap not pointers to objects,also
pointers can simply point to some stack variable in the presenet
thread as well.
The contribution? Very obvious!!! Copying containers is generally both
memory and runtime consuming and should be avoided whenever
possible ,and the simplest way is to use ref/ptr semantics.
As far as inside a container is concerned, it depends on the type
T. Typically, if I want to prevent copying, I use either pointers,
or even a pointer_container aka. boost::ptr_vector. If copying of
the container does not happen often, and T has the relevant
members required, then I use T (by value).
I am talking about the container itself, not the elements.If one
address/refrences a container no element copy is performed but copying
a container is a nightmare sometimes,eventhough elements are pointers.

regards,
FM.

Sep 15 '07 #14
On 2007-09-15 15:09, terminator wrote:
On Sep 11, 11:03 pm, werasm <wer...@gmail.comwrote:
>terminator wrote:
I said huge because a container contains data spatered all over the
heap and when it comes to copy(instead of reference) ,then it does not
matter if the data is stored in a contigeous portion of memory or
segmented into peices on different corners of memory.the actual size
of a container is often much larger than its own data structure(one or
two pointers and intrinsic values as well as the vtable in runtime
polymorphic ones).

In that case I don't see how it contributes to your argument of using
a pointer to the container instead of the actual container, if I
understand you correctly, as whether one uses a pointer to
a container, or the container itself, you always going to use the
heap, and in the case of a pointer to the container, slightly more
than in the other case, as now the pointer members are also on
the heap.

only dynamic objects are placed on heap not pointers to objects,also
pointers can simply point to some stack variable in the presenet
thread as well.
The contribution? Very obvious!!! Copying containers is generally both
memory and runtime consuming and should be avoided whenever
possible ,and the simplest way is to use ref/ptr semantics.
>As far as inside a container is concerned, it depends on the type
T. Typically, if I want to prevent copying, I use either pointers,
or even a pointer_container aka. boost::ptr_vector. If copying of
the container does not happen often, and T has the relevant
members required, then I use T (by value).

I am talking about the container itself, not the elements.If one
address/refrences a container no element copy is performed but copying
a container is a nightmare sometimes,eventhough elements are pointers.
Yes, what you say is true, but it is a question of semantics. For some
types the container should be copied for some it should not, you should
only use pointers where the containers are shared (and perhaps not even
then, you can use "smart" containers instead).

--
Erik Wikström
Sep 15 '07 #15
On Sep 15, 4:23 pm, Erik Wikström <Erik-wikst...@telia.comwrote:
On 2007-09-15 15:09, terminator wrote:


On Sep 11, 11:03 pm, werasm <wer...@gmail.comwrote:
terminator wrote:
I said huge because a container contains data spatered all over the
heap and when it comes to copy(instead of reference) ,then it does not
matter if the data is stored in a contigeous portion of memory or
segmented into peices on different corners of memory.the actual size
of a container is often much larger than its own data structure(one or
two pointers and intrinsic values as well as the vtable in runtime
polymorphic ones).
In that case I don't see how it contributes to your argument of using
a pointer to the container instead of the actual container, if I
understand you correctly, as whether one uses a pointer to
a container, or the container itself, you always going to use the
heap, and in the case of a pointer to the container, slightly more
than in the other case, as now the pointer members are also on
the heap.
only dynamic objects are placed on heap not pointers to objects,also
pointers can simply point to some stack variable in the presenet
thread as well.
The contribution? Very obvious!!! Copying containers is generally both
memory and runtime consuming and should be avoided whenever
possible ,and the simplest way is to use ref/ptr semantics.
As far as inside a container is concerned, it depends on the type
T. Typically, if I want to prevent copying, I use either pointers,
or even a pointer_container aka. boost::ptr_vector. If copying of
the container does not happen often, and T has the relevant
members required, then I use T (by value).
I am talking about the container itself, not the elements.If one
address/refrences a container no element copy is performed but copying
a container is a nightmare sometimes,eventhough elements are pointers.

Yes, what you say is true, but it is a question of semantics. For some
types the container should be copied for some it should not, you should
only use pointers where the containers are shared (and perhaps not even
then, you can use "smart" containers instead).
???what is that one?somewhat smart ptr?

thanks,
FM.

Sep 15 '07 #16
On 2007-09-15 15:56, terminator wrote:
On Sep 15, 4:23 pm, Erik Wikström <Erik-wikst...@telia.comwrote:
>On 2007-09-15 15:09, terminator wrote:


On Sep 11, 11:03 pm, werasm <wer...@gmail.comwrote:
terminator wrote:
I said huge because a container contains data spatered all over the
heap and when it comes to copy(instead of reference) ,then it does not
matter if the data is stored in a contigeous portion of memory or
segmented into peices on different corners of memory.the actual size
of a container is often much larger than its own data structure(one or
two pointers and intrinsic values as well as the vtable in runtime
polymorphic ones).
>In that case I don't see how it contributes to your argument of using
a pointer to the container instead of the actual container, if I
understand you correctly, as whether one uses a pointer to
a container, or the container itself, you always going to use the
heap, and in the case of a pointer to the container, slightly more
than in the other case, as now the pointer members are also on
the heap.
only dynamic objects are placed on heap not pointers to objects,also
pointers can simply point to some stack variable in the presenet
thread as well.
The contribution? Very obvious!!! Copying containers is generally both
memory and runtime consuming and should be avoided whenever
possible ,and the simplest way is to use ref/ptr semantics.
>As far as inside a container is concerned, it depends on the type
T. Typically, if I want to prevent copying, I use either pointers,
or even a pointer_container aka. boost::ptr_vector. If copying of
the container does not happen often, and T has the relevant
members required, then I use T (by value).
I am talking about the container itself, not the elements.If one
address/refrences a container no element copy is performed but copying
a container is a nightmare sometimes,eventhough elements are pointers.

Yes, what you say is true, but it is a question of semantics. For some
types the container should be copied for some it should not, you should
only use pointers where the containers are shared (and perhaps not even
then, you can use "smart" containers instead).

???what is that one?somewhat smart ptr?
I was thinking about a container (cannot remember which) in Qt3 which
employed copy on write semantics. When you made a copy of the container
all you did was to copy a few variables (a pointer to the data, size,
etc.) and it was first when you tried to make any changes to it that the
elements were copied.

The rationale was that most of the time a container was copied the
elements were only read not modified, so they delayed the actual copy
until modification. To me it sounded like passing by reference might
have solved that one but what do I know.

--
Erik Wikström
Sep 15 '07 #17
On Sep 15, 7:26 pm, Erik Wikström <Erik-wikst...@telia.comwrote:
On 2007-09-15 15:56, terminator wrote:


On Sep 15, 4:23 pm, Erik Wikström <Erik-wikst...@telia.comwrote:
On 2007-09-15 15:09, terminator wrote:
On Sep 11, 11:03 pm, werasm <wer...@gmail.comwrote:
terminator wrote:
I said huge because a container contains data spatered all over the
heap and when it comes to copy(instead of reference) ,then it does not
matter if the data is stored in a contigeous portion of memory or
segmented into peices on different corners of memory.the actual size
of a container is often much larger than its own data structure(one or
two pointers and intrinsic values as well as the vtable in runtime
polymorphic ones).
In that case I don't see how it contributes to your argument of using
a pointer to the container instead of the actual container, if I
understand you correctly, as whether one uses a pointer to
a container, or the container itself, you always going to use the
heap, and in the case of a pointer to the container, slightly more
than in the other case, as now the pointer members are also on
the heap.
only dynamic objects are placed on heap not pointers to objects,also
pointers can simply point to some stack variable in the presenet
thread as well.
The contribution? Very obvious!!! Copying containers is generally both
memory and runtime consuming and should be avoided whenever
possible ,and the simplest way is to use ref/ptr semantics.
As far as inside a container is concerned, it depends on the type
T. Typically, if I want to prevent copying, I use either pointers,
or even a pointer_container aka. boost::ptr_vector. If copying of
the container does not happen often, and T has the relevant
members required, then I use T (by value).
I am talking about the container itself, not the elements.If one
address/refrences a container no element copy is performed but copying
a container is a nightmare sometimes,eventhough elements are pointers.
Yes, what you say is true, but it is a question of semantics. For some
types the container should be copied for some it should not, you should
only use pointers where the containers are shared (and perhaps not even
then, you can use "smart" containers instead).
???what is that one?somewhat smart ptr?

I was thinking about a container (cannot remember which) in Qt3 which
employed copy on write semantics. When you made a copy of the container
all you did was to copy a few variables (a pointer to the data, size,
etc.) and it was first when you tried to make any changes to it that the
elements were copied.

The rationale was that most of the time a container was copied the
elements were only read not modified, so they delayed the actual copy
until modification. To me it sounded like passing by reference might
have solved that one but what do I know.
OK ,reference-counting(marking) with duplication on modification.but
that is still refrencing something which can be an STL container .

thank you again,
FM.

Sep 15 '07 #18

terminator wrote:
only dynamic objects are placed on heap not pointers to objects,
std::vector<int>** ppv = new std::vector<int>*();
*ppv = new std::vector<int>(10,0);

In the case above the pointer was also placed on the heap :-).
also pointers can simply point to some stack variable in the present
thread as well.
Of course
The contribution? Very obvious!!! Copying containers is generally both
memory and runtime consuming and should be avoided whenever
possible ,and the simplest way is to use ref/ptr semantics.
In my opinion (and IME) copying is quite a rare occurrence, especially
copying of objects with containers as members. You are compromising
maintainability for efficiency which in most cases give you no gain.

I Agreed that if it did matter, wrap it in a smart pointer (as you
want to
copy, it would probably be a shared pointer). The question remains:
Would you want the copy to be bounded to the original, or not - if
not,
there is no purpose in storing a pointer. I could give you an
elaborate
example, but I hope you understand my point.
I am talking about the container itself, not the elements.If one
address/refrences a container no element copy is performed but copying
a container is a nightmare sometimes,eventhough elements are pointers.
I was talking about both, just incase you were talking about the
other, but
I was especially talking about the container itself.

Regards,

Werner

Sep 15 '07 #19

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

11
by: Vivi Orunitia | last post by:
Hi all, I tried looking this up in the sgi docs but it didn't provide any concrete answer to what I'm looking for. Basically, is there any difference between using ::iterator for a container vs...
16
by: forester | last post by:
lets say its common situation when object have subobjects in container and receives callbacks from contained items. and object want to move objects in containers on signal(callback). iterator is...
64
by: Morgan Cheng | last post by:
Hi All, I was taught that argument valuse is not supposed to be changed in function body. Say, below code is not good. void foo1(int x) { x ++; printf("x+1 = %d\n", x); } It should be...
10
by: vb | last post by:
Hi all, I am a newbie in C and i want to know what all pointer conversions are "legal" according to ANSI C standard. For Example, int* to char*, some_struct* to char* and so on .. According to...
8
by: Axter | last post by:
I normally use a program call Doxygen to document my source code.(http://www.stack.nl/~dimitri/doxygen) This method works great for small and medium size projects, and you can get good...
0
by: uncensored | last post by:
Hello everyone, I'm fairly new at .Net and I have a repeater inside a repeater problem. I will attach my code to this message but basically what I am able to tell when I run my page it tells me...
2
by: domehead100 | last post by:
I have a templated class, CDerived: template <typename TValue, typename TDraw, typename TEdit ...> class CDerived : public CBase { TValue m_Value public: TValue& GetValue() const {
4
by: drhowarddrfine | last post by:
What am I forgetting here. It's the last thing I have to fix after a day of coding. char *box={ "red","blue","green" }; struct item{ char **container; }; struct item *item;
13
by: Phil Bouchard | last post by:
I am currently writting a smart pointer which is reasonnably stable and I decided supporting allocators for completion because of its increase in efficiency when the same pool used by containers is...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.