«

Is there a way to pass a string parameter to a template class? I would
like to do something like:

MyClass<int, "blah", 5> test;


Thanks

bsmatt wrote:
> Is there a way to pass a string parameter to a template class? I would
> like to do something like:
>
> MyClass<int, "blah", 5> test;

No. Non-type arguments need to be either integral constants, or addresses
of (or references to) objects with external linkage. String literals are
neither.

V

Thanks for the quick response.

That is what I was afraid of.

The reason I am asking is that I am working on a simple way to track
memory allocations so that I can get a list of memory leaks. I am using
STL and those allocations are done in a way that I can track but I
can't figure out how to get information about where the allocation came
from. For example:

std::vector<int> test;
test.push_back(5);

will allocate memory. In other situations I am using __FILE__ and
__LINE__ so that I can see exactly where a "new" happens. I would like
to get enough info to a least know what STL object the memory is
allocated for (in my example I would like to know that the allocation
was associated with the definition of test). Got any suggestions on how
I can accomplish this?

Thanks

bsmatt wrote:
> The reason I am asking is that I am working on a simple way to track
> memory allocations so that I can get a list of memory leaks. I am using
> STL and those allocations are done in a way that I can track but I
> can't figure out how to get information about where the allocation came
> from. For example:
>
> std::vector<int> test;
> test.push_back(5);
>
> will allocate memory. In other situations I am using __FILE__ and
> __LINE__ so that I can see exactly where a "new" happens. I would like
> to get enough info to a least know what STL object the memory is
> allocated for (in my example I would like to know that the allocation
> was associated with the definition of test). Got any suggestions on how
> I can accomplish this?

Not really. 'push_back(5)' will cause allocation (iff it needs to resize
the vector), but that allocation will happen where 'push_back' is
implemented, not where you call it. In order to be able to track
'push_back' calls, you will need to reimplement (by wrapping, for example)
the whole Standard Library (to track all containers your program may be
using).

V

On Tue, 04 Oct 2005 09:02:17 -0700, bsmatt wrote:

<snip>

> In other situations I am using __FILE__ and
> __LINE__ so that I can see exactly where a "new" happens. I would like
> to get enough info to a least know what STL object the memory is
> allocated for (in my example I would like to know that the allocation
> was associated with the definition of test). Got any suggestions on how
> I can accomplish this?
>

How about instead of:

MyClass<int, "blah", 5> test;

you use:

MyClass<int, 5> test("blah");

or even:

MyClass<int> test("blah", 5);

and write the appropriate constructor.

Is there a reason to have a separate type for each instance where it's
used?

- Jay

My idea was to create a new allocator that kept track of where the
object was created so that when allocating memory I would know where
the object was defined. It would look something like

std::vector<int, MyAlloc<int, __FILE__, __LINE__>> test;

This way the allocator knows where it came from...but that won't work.

It looks like the solution I am going to go with is a wrapper based
approach where I can push and pop allocation location info into my
memory tracker before making the calls into the STL.

On Tue, 04 Oct 2005 11:03:13 -0700, bsmatt wrote:

> My idea was to create a new allocator that kept track of where the
> object was created so that when allocating memory I would know where
> the object was defined. It would look something like
>
> std::vector<int, MyAlloc<int, __FILE__, __LINE__>> test;
>
> This way the allocator knows where it came from...but that won't work.
>
> It looks like the solution I am going to go with is a wrapper based
> approach where I can push and pop allocation location info into my
> memory tracker before making the calls into the STL.

I guess my question remains - why does each allocator have to have a
unique *type* (a different instantiation of the template to
effectively generate a new class) as opposed to member variables that hold
the __FILE__ and __LINE__ values in different objects?

- Jay

On Tue, 04 Oct 2005 20:04:55 +0000, Jay Nabonne wrote:

Never mind. I think I misread that.