Re: Strategies for avoiding new?

From: Leor Zolman (leor_at_bdsoft.com)
Date: 02/23/04 

Date: Mon, 23 Feb 2004 00:33:31 GMT

On Sun, 22 Feb 2004 23:57:16 GMT, Wolfie <dbgbdwolf@gte.net> wrote:

>
>I'm wondering if I'm missing something. Coming from a
>C background, I'm using a typical "for each data read,
>allocate and store (the pointer) in a container" strategy.
>IOW, I'm using map (in some cases) but (generally) the
>data type stored is a pointer.
>
>I'm just wondering if there's an alternative to using new
>in these general cases where you don't know the exact number
>of items to store in the container at design time (and/or
>don't want to create a huge container and individual items
>one may not need.)

The criteria for deciding whether to store values or pointers in your
"container" is pretty much the same regardless of whether you're working in
C or C++. You have to balance your use of memory, time, complexity, etc.
against the requirements of the app.

So whether you store pointers or values in the container depends upon what
serves the purposes of your program the best. If you've chosen to use a
std::vector and have to sort it a lot, and the objects are big, then
storing pointers may work out better than storing bulky values.

I don't quite understand your question about whether "there's an
alternative to using new", since you're not forced to use new in the first
place. Even if you're storing pointers, they don't /have/ to be pointing to
dynamically allocated objects (although they typically would be.)

Are you asking about using new in the sense of allocating a dynamic array
in C, so that you're then "stuck" with its size unless you do a complete
re-allocation? STL containers handle their own resizing (std::vector and
std::string, which also let you reserve space if you know the minimum size
up front and want to save a bit of execution time) or other memory
management needs (the other containers) automatically. If you choose your
data structures carefully, the price for that overhead should not be an
issue.

>
>Something about the whole "always storing pointers in
>containers" bothers me, but maybe I'm missing the cases
>where a container stores objects (rather than pointers
>to objects).

Are you saying that you've only seen code where the value_type of an STL
container is a pointer? I'm not sure you've looked at very much code. You
may find Scott Meyers' book _Effective STL_ a good investment at this
point.

Good luck!
        -leor

>

Leor Zolman
BD Software
leor@bdsoft.com
www.bdsoft.com -- On-Site Training in C/C++, Java, Perl & Unix
C++ users: Download BD Software's free STL Error Message
           Decryptor at www.bdsoft.com/tools/stlfilt.html

Relevant Pages

  • Re: inheritance from STL-container
    ... First of all, you've shown the DBC ... number of algorithms are implemented as member functions. ... container wouldn't allow you to add the DBC stuff to them anyway. ... Generally smart pointers. ...
    (microsoft.public.vc.stl)
  • Re: Strategies for avoiding new?
    ... > container is important (which is why I use map or whatever.) ... from the container and manipulate it directly. ... So after my snippet, ... using pointers is unnecessary. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Strategies for avoiding new?
    ... > allocate and store in a container" strategy. ... you should almost never use raw pointers unless you're writing ... > don't want to create a huge container and individual items ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Code critique
    ... Other than the 'less typing' argument, is there any reason ... I intended it to be a standard container such as deque. ... The aim is to keep using a container of pointers, ... Rethrowing the same exception often hints at bad ...
    (comp.lang.cpp)
  • Re: void *
    ... A container that can store any kind of object, ... 'void *' may help me. ... If you want to *store* objects in the linked list, as you say, then ... pointers in them, etc. ...
    (comp.lang.c)