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

fwd declaring STL containers

P: n/a
Is there any way to forward declare STL container classes such as list,
set, map, etc.? (My impression is that there isn't, since these are all
defined in std.)

Failing that, consider the following snippet of code:

//////////

#include <list>

template <class Ty = int>
struct Foo
{
typedef std::list<Ty> Type;
};

//////////

If this block of code were included in a translation unit that never
made any further reference to Foo or Foo::Type, is it reasonable to
assume that the compiled code would not be any larger? (I understand
this is an implementation issue, but your experience and intuition would
be very helpful.) FWIW, my testing on gcc indicates no difference.

[If you're curious, I have a bunch of these wrapped typedefs for various
STL container classes which I use to supply my own default allocator.
This in turn simplifies the client syntax significantly. However,
they're all stuck together in a single header file which includes many
of the STL container headers, even though any particular user of the
header may only need some of them.]

Thanks,
Mark
Jun 20 '06 #1
Share this Question
Share on Google+
8 Replies


P: n/a
LR
Mark P wrote:
Is there any way to forward declare STL container classes such as list,
set, map, etc.? (My impression is that there isn't, since these are all
defined in std.)

Failing that, consider the following snippet of code:

//////////

#include <list>

template <class Ty = int>
struct Foo
{
typedef std::list<Ty> Type;
};

//////////

If this block of code were included in a translation unit that never
made any further reference to Foo or Foo::Type, is it reasonable to
assume that the compiled code would not be any larger? (I understand
this is an implementation issue, but your experience and intuition would
be very helpful.) FWIW, my testing on gcc indicates no difference.

Could you expand on this a little bit?

Have you tried to compare something like:

int main() {
static Foo f;
}

and

int main() { }

My intuition tells me these will be different sizes. I tried with two
compilers, with the first, the object file size changed, but not the
executable file size. With the second, both files changed size.

Did you mean the executable file size? Object file size? Footprint in
memory at runtime?


[If you're curious, I have a bunch of these wrapped typedefs for various
STL container classes which I use to supply my own default allocator.
This in turn simplifies the client syntax significantly. However,
they're all stuck together in a single header file which includes many
of the STL container headers, even though any particular user of the
header may only need some of them.]


Now I'm curious. How does this simplify client syntax?

LR
Jun 21 '06 #2

P: n/a
LR wrote:
Mark P wrote:
Is there any way to forward declare STL container classes such as
list, set, map, etc.? (My impression is that there isn't, since these
are all defined in std.)

Failing that, consider the following snippet of code:

//////////

#include <list>

template <class Ty = int>
struct Foo
{
typedef std::list<Ty> Type;
};

//////////

If this block of code were included in a translation unit that never
made any further reference to Foo or Foo::Type, is it reasonable to
assume that the compiled code would not be any larger? (I understand
this is an implementation issue, but your experience and intuition
would be very helpful.) FWIW, my testing on gcc indicates no difference.

Could you expand on this a little bit?

Have you tried to compare something like:

int main() {
static Foo f;
}

and

int main() { }

My intuition tells me these will be different sizes. I tried with two
compilers, with the first, the object file size changed, but not the
executable file size. With the second, both files changed size.

Did you mean the executable file size? Object file size? Footprint in
memory at runtime?


I looked at object file size and executable file size and saw no
difference. I don't know that your example is particularly relevant to
my issue though. I never instantiate my Foo object-- it's only used to
emulate a templated typedef.


[If you're curious, I have a bunch of these wrapped typedefs for
various STL container classes which I use to supply my own default
allocator. This in turn simplifies the client syntax significantly.
However, they're all stuck together in a single header file which
includes many of the STL container headers, even though any particular
user of the header may only need some of them.]


Now I'm curious. How does this simplify client syntax?


Compare the following two declarations:

std::map<Key, Ty, std::less<Key>,
myAlloc<std::pair<const Key,Ty> > > myMap;

my_map<Key,Ty>::Type myMap;

The issue is that the allocator parameter is the last among all
parameters so to override the default it's necessary to specify all
parameters. Compound this with the particularly unwieldy value_type of
the map, and it gets pretty ugly.

-Mark
Jun 21 '06 #3

P: n/a
LR wrote:
Mark P wrote:
Is there any way to forward declare STL container classes such as
list, set, map, etc.? (My impression is that there isn't, since
these are all defined in std.)
To Mark: there can be, but it would be implementation-specific.
Failing that, consider the following snippet of code:

//////////

#include <list>

template <class Ty = int>
struct Foo
{
typedef std::list<Ty> Type;
};

//////////

If this block of code were included in a translation unit that never
made any further reference to Foo or Foo::Type, is it reasonable to
assume that the compiled code would not be any larger?
To Mark: Yes.
(I understand
this is an implementation issue, but your experience and intuition
would be very helpful.) FWIW, my testing on gcc indicates no
difference.

Could you expand on this a little bit?

Have you tried to compare something like:

int main() {
static Foo f;
}

and

int main() { }


What's the connection? Mark's code defines a type. Your code defines
an object. Types are not objects. Types do not take up any memory
(except the compiler's during compilation).
My intuition tells me these will be different sizes.
Unknown. FWIW, 'f' is not used anywhere, so it can be optimized away.
I tried with two
compilers, with the first, the object file size changed, but not the
executable file size. With the second, both files changed size.

Did you mean the executable file size? Object file size? Footprint
in memory at runtime?


My guess would be "all of the above".
[If you're curious, I have a bunch of these wrapped typedefs for
various STL container classes which I use to supply my own default
allocator. This in turn simplifies the client syntax significantly.
However, they're all stuck together in a single header file which
includes many of the STL container headers, even though any
particular user of the header may only need some of them.]


Now I'm curious. How does this simplify client syntax?


Using 'Foo<>::Type' instead of 'std::list<int>'? I doubt it. It
might just tickle the fancy of the younger programmer, who's barely
started with templates...

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Jun 21 '06 #4

P: n/a
Mark P wrote:
LR wrote:
[..]
Now I'm curious. How does this simplify client syntax?


Compare the following two declarations:

std::map<Key, Ty, std::less<Key>,
myAlloc<std::pair<const Key,Ty> > > myMap;

my_map<Key,Ty>::Type myMap;

The issue is that the allocator parameter is the last among all
parameters so to override the default it's necessary to specify all
parameters. Compound this with the particularly unwieldy value_type
of the map, and it gets pretty ugly.


Yes, when you want to supply some kind of pre-defined umpteenth template
argument, then a typedef is an easy way out. But how often do you have
to do that, really? I guess that along with a custom allocator you could
define your own typedefs for using the same allocator with the standard
containers... But that would be also hiding the fact that a custom
allocator is used... I just prefer everything explicit.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Jun 21 '06 #5

P: n/a
LR
Mark P wrote:
LR wrote:
Mark P wrote:
Is there any way to forward declare STL container classes such as
list, set, map, etc.? (My impression is that there isn't, since
these are all defined in std.)

Failing that, consider the following snippet of code:

//////////

#include <list>

template <class Ty = int>
struct Foo
{
typedef std::list<Ty> Type;
};

//////////

If this block of code were included in a translation unit that never
made any further reference to Foo or Foo::Type, is it reasonable to
assume that the compiled code would not be any larger? (I understand
this is an implementation issue, but your experience and intuition
would be very helpful.) FWIW, my testing on gcc indicates no
difference.


Could you expand on this a little bit?

Have you tried to compare something like:

int main() {
static Foo f;
}

and

int main() { }

My intuition tells me these will be different sizes. I tried with two
compilers, with the first, the object file size changed, but not the
executable file size. With the second, both files changed size.

Did you mean the executable file size? Object file size? Footprint
in memory at runtime?


I looked at object file size and executable file size and saw no
difference. I don't know that your example is particularly relevant to
my issue though. I never instantiate my Foo object-- it's only used to
emulate a templated typedef.

I was only looking at what you said here: "If this block of code were
included in a translation unit that never made any further reference to
Foo" But probably I misinterpreted what you meant.

But if you never instantiate, yet you have some need to wrap the typedef
into a scope of some kind, have you considered a namespace?
[If you're curious, I have a bunch of these wrapped typedefs for
various STL container classes which I use to supply my own default
allocator. This in turn simplifies the client syntax significantly.
However, they're all stuck together in a single header file which
includes many of the STL container headers, even though any
particular user of the header may only need some of them.]

Now I'm curious. How does this simplify client syntax?


Compare the following two declarations:

std::map<Key, Ty, std::less<Key>,
myAlloc<std::pair<const Key,Ty> > > myMap;

my_map<Key,Ty>::Type myMap;

The issue is that the allocator parameter is the last among all
parameters so to override the default it's necessary to specify all
parameters. Compound this with the particularly unwieldy value_type of
the map, and it gets pretty ugly.

-Mark


Even more curious, why do you need to specify an allocator?

LR
Jun 21 '06 #6

P: n/a
LR wrote:
Mark P wrote:
LR wrote:
Mark P wrote:

Is there any way to forward declare STL container classes such as
list, set, map, etc.? (My impression is that there isn't, since
these are all defined in std.)

Failing that, consider the following snippet of code:

//////////

#include <list>

template <class Ty = int>
struct Foo
{
typedef std::list<Ty> Type;
};

//////////

If this block of code were included in a translation unit that never
made any further reference to Foo or Foo::Type, is it reasonable to
assume that the compiled code would not be any larger? (I
understand this is an implementation issue, but your experience and
intuition would be very helpful.) FWIW, my testing on gcc indicates
no difference.

Could you expand on this a little bit?

Have you tried to compare something like:

int main() {
static Foo f;
}

and

int main() { }

My intuition tells me these will be different sizes. I tried with
two compilers, with the first, the object file size changed, but not
the executable file size. With the second, both files changed size.

Did you mean the executable file size? Object file size? Footprint
in memory at runtime?
I looked at object file size and executable file size and saw no
difference. I don't know that your example is particularly relevant
to my issue though. I never instantiate my Foo object-- it's only
used to emulate a templated typedef.

I was only looking at what you said here: "If this block of code were
included in a translation unit that never made any further reference to
Foo" But probably I misinterpreted what you meant.

But if you never instantiate, yet you have some need to wrap the typedef
into a scope of some kind, have you considered a namespace?


The point is not simply to wrap the typedef inside of a scope, but
rather to obtain something like a templated typedef since the language
has no "direct" support for such a thing.

[If you're curious, I have a bunch of these wrapped typedefs for
various STL container classes which I use to supply my own default
allocator. This in turn simplifies the client syntax significantly.
However, they're all stuck together in a single header file which
includes many of the STL container headers, even though any
particular user of the header may only need some of them.]
Now I'm curious. How does this simplify client syntax?


Compare the following two declarations:

std::map<Key, Ty, std::less<Key>,
myAlloc<std::pair<const Key,Ty> > > myMap;

my_map<Key,Ty>::Type myMap;

The issue is that the allocator parameter is the last among all
parameters so to override the default it's necessary to specify all
parameters. Compound this with the particularly unwieldy value_type
of the map, and it gets pretty ugly.

-Mark


Even more curious, why do you need to specify an allocator?


Just the nature of the project I'm working on. All memory allocations
are handled by a memory manager. My allocator serves as an interface
between STL allocation conventions and the memory manager.
Jun 21 '06 #7

P: n/a
Victor Bazarov wrote:
Mark P wrote:
LR wrote:
[..]
Now I'm curious. How does this simplify client syntax?
Compare the following two declarations:

std::map<Key, Ty, std::less<Key>,
myAlloc<std::pair<const Key,Ty> > > myMap;

my_map<Key,Ty>::Type myMap;

The issue is that the allocator parameter is the last among all
parameters so to override the default it's necessary to specify all
parameters. Compound this with the particularly unwieldy value_type
of the map, and it gets pretty ugly.


Yes, when you want to supply some kind of pre-defined umpteenth template
argument, then a typedef is an easy way out. But how often do you have
to do that, really?


Short answer: everywhere. I probably have hundreds of such declarations
spread over dozens of source files. Every instance of an STL container
has to use this allocator and individual typedefs help a little, but
there are still a lot of them.

I try hard to keep my code within an 80 column width and these map
declarations are often spread over 3 lines in order to adhere to this
(since my template parameters are rarely so compact as "Key" and "Ty"
above). I'll concede to being a bit anal when it comes to formatting
code but to me this reduced syntax really helps the readability (and
rest assured I choose a slightly more informative name than "my_map" to
indicate the default custom allocator).

I guess that along with a custom allocator you could define your own typedefs for using the same allocator with the standard
containers... But that would be also hiding the fact that a custom
allocator is used... I just prefer everything explicit.


I don't think I understand your suggestion here, unless you're restating
the "template typedef" notion I mentioned in my original post?

Thanks,
Mark
Jun 21 '06 #8

P: n/a
Mark P wrote:
Is there any way to forward declare STL container classes such as
list,
set, map, etc.? (My impression is that there isn't, since these are
all defined in std.)
Not by you, but the library provider could.
The reason is that it is allowed for the STL containers to accept more
template parameters than the set defined by the standard. (The extra
template parameters then must have default values, in order to conform
to the standards requirements.)

Failing that, consider the following snippet of code:

//////////

#include <list>

template <class Ty = int>
struct Foo
{
typedef std::list<Ty> Type;
};

//////////

If this block of code were included in a translation unit that never
made any further reference to Foo or Foo::Type, is it reasonable to
assume that the compiled code would not be any larger? (I understand
this is an implementation issue, but your experience and intuition
would
be very helpful.) FWIW, my testing on gcc indicates no difference.

[If you're curious, I have a bunch of these wrapped typedefs for
[various
STL container classes which I use to supply my own default allocator.
This in turn simplifies the client syntax significantly. However,
they're all stuck together in a single header file which includes many
of the STL container headers, even though any particular user of the
header may only need some of them.]
If you use those structures exclusively as type-aliasses, and you never
create an instance of them, then their existence should have no impact
at all on the generated code.
The only impact that it should have is in the resources that the
compiler uses (time and memory).

Thanks,
Mark


Bart
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://www.eskimo.com/~scs/C-faq/top.html
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/
Jun 21 '06 #9

This discussion thread is closed

Replies have been disabled for this discussion.