The Art of C++

M

Maciej

Hi,

I tried to build windl project from the book 'The Art of C++" in VS.NET 7
and it fails. I attached all required .lib files. I got the following error
messages from the linker:

windl error LNK2001: unresolved external symbol __malloc_dbg
windl error LNK2019: unresolved external symbol __free_dbg referenced in
function "void __cdecl operator delete(void *,struct std::_DebugHeapTag_t
const &,char *,int)" (??3@YAXPAXABU_DebugHeapTag_t@std@@PADH@Z)
windl error LNK2019: unresolved external symbol __malloc_dbg referenced in
function "void * __cdecl operator new(unsigned int,struct
std::_DebugHeapTag_t const &,char *,int)"
(??2@YAPAXIABU_DebugHeapTag_t@std@@PADH@Z)

What's wrong?
Maciej
 
M

Mike Hewson

Maciej said:
Hi,

I tried to build windl project from the book 'The Art of C++" in VS.NET 7
and it fails. I attached all required .lib files. I got the following error
messages from the linker:

windl error LNK2001: unresolved external symbol __malloc_dbg
windl error LNK2019: unresolved external symbol __free_dbg referenced in
function "void __cdecl operator delete(void *,struct std::_DebugHeapTag_t
const &,char *,int)" (??3@YAXPAXABU_DebugHeapTag_t@std@@PADH@Z)
windl error LNK2019: unresolved external symbol __malloc_dbg referenced in
function "void * __cdecl operator new(unsigned int,struct
std::_DebugHeapTag_t const &,char *,int)"
(??2@YAPAXIABU_DebugHeapTag_t@std@@PADH@Z)

What's wrong?
Maciej

Your linker's unhappy. It can't match a symbol declaration in one module
to it's definition somewhere else. Looks like memory management stuff.
At a guess you probably missed an #include. Try one of the Microsoft
groups, there's bound to be one for .NET.
 
M

Mike Hewson

Oh, and I think this is such a cool identifier ( undoubtably compiler
generated and/or mangled ):

??3@YAXPAXABU_DebugHeapTag_t@std@@PADH@Z

:)
 
M

msalters

Maciej said:
Hi,

I tried to build windl project from the book 'The Art of C++" in VS.NET 7
and it fails. I attached all required .lib files. I got the following error
messages from the linker:

windl error LNK2001: unresolved external symbol __malloc_dbg
windl error LNK2019: unresolved external symbol __free_dbg referenced in
function "void __cdecl operator delete(void *,struct std::_DebugHeapTag_t
const &,char *,int)" (??3@YAXPAXABU_DebugHeapTag_t@std@@PADH@Z)

You did not attach all reuired .lib files, despite your statement. The
..lib file with __malloc_dbg is missing.

Regards,
Michiel Salters
 
M

msalters

Maciej said:
Hi,

I tried to build windl project from the book 'The Art of C++" in VS.NET 7
and it fails. I attached all required .lib files. I got the following error
messages from the linker:

windl error LNK2001: unresolved external symbol __malloc_dbg
windl error LNK2019: unresolved external symbol __free_dbg referenced in
function "void __cdecl operator delete(void *,struct std::_DebugHeapTag_t
const &,char *,int)" (??3@YAXPAXABU_DebugHeapTag_t@std@@PADH@Z)

You did not attach all reuired .lib files, despite your statement. The
..lib file with __malloc_dbg is missing.

Regards,
Michiel Salters
 
M

Maciej

Uzytkownik "msalters said:
You did not attach all reuired .lib files, despite your statement. The
.lib file with __malloc_dbg is missing.

Regards,
Michiel Salters

I've changed the option mt to mtd in project properties and it works.

Thanks,
Maciej
 
J

Jari Kalevi Savolainen

Bit of code first:

template <typename storeType, typename multiType>
class c_store {
storeType data;
public:
c_store() {
data = multiType(3) * 3;
}

template<typename srcMultiType> //storeType has to match
c_store(const c_store<storeType, srcMultiType> & src) {
data = src.data;
}

};

c_store<int, int> a;
c_store<int, double> b(a);

And we have problems. Compilers report that data is private, which is what
they should do.

There are ways to work around this problem ofcourse, declare a friend
function that returns the data or have a base class that has public method
to do that(ptrs needed and stuff, hack and overkill).
Either way data exposure occurs aswell.

Is there a way to safely, not by some pointer hack, to get this done. I
haven't been able to come up with one yet.

And as everyone can see the Multitype is not a datamember of class
c_store, so the memory usage is the same for instance a and b. the
multiType is only used in methods as a local.
The code above certainly doesn't make much sense but I have a piece of
code where this sort of template usage is 'neat'. The tradeoff is the
exposure that the friend function creates.

Has there been discussion about this before? I'd very much would like to
see a standart where you could specify template parameters as 'not member
types'.
for example:
template<typename T, typename_onlycode U>
where typename_onlycode couldn't be used in datamember declarations.
Therefore no need for access checking.

Thoughts?
 
V

Victor Bazarov

Jari said:
Bit of code first:

template <typename storeType, typename multiType>
class c_store {
storeType data;
public:
c_store() {
data = multiType(3) * 3;
}

I'd do

c_store() : data(multiType(3)*3) {}
template<typename srcMultiType> //storeType has to match
c_store(const c_store<storeType, srcMultiType> & src) {
data = src.data;
}

};

c_store<int, int> a;
c_store<int, double> b(a);

And we have problems. Compilers report that data is private, which is what
they should do.

There are ways to work around this problem ofcourse, declare a friend
function that returns the data or have a base class that has public method
to do that(ptrs needed and stuff, hack and overkill).
Either way data exposure occurs aswell.

Is there a way to safely, not by some pointer hack, to get this done. I
haven't been able to come up with one yet.

And as everyone can see the Multitype is not a datamember of class
c_store, so the memory usage is the same for instance a and b. the
multiType is only used in methods as a local.
The code above certainly doesn't make much sense but I have a piece of
code where this sort of template usage is 'neat'. The tradeoff is the
exposure that the friend function creates.

Has there been discussion about this before? I'd very much would like to
see a standart where you could specify template parameters as 'not member
types'.
for example:
template<typename T, typename_onlycode U>
where typename_onlycode couldn't be used in datamember declarations.
Therefore no need for access checking.

Thoughts?

Several.

First, why did you reply to another, unrelated, thread instead of starting
a new one? Not a good idea.

Second, I am not sure what you expect. c_store<A,A> and c_store<A,B> are
two distinct and unrelated types. Unless you tell them to be friends of
each other, there is no seeing of any privates.

Third, if you really need a design suggestion, post the real problem you
are trying to solve instead of a hypothetical, contrived, and non-working
solution.

Now, there are several work-arounds. A friend member function would be
one. You can make them (instantiations) all friends of each other. You
can have a member function that simply returns a value of 'data'. I am
not sure what "exposure" you're afraid of. A common base class probably
won't work since an instance is not allowed to see even protected members
of an object of another derived type. Another solution is to drop the
'multiType' from the main template and _always_ have it for members:

template<class T> class c_store {
T data;
public:
template<class mT> c_store(mT md = 3) : data(md * 3) {}
c_store(c_store const & cs) : data(cs.data) {} // actually no need
};

That of course may not be acceptable if you do need distinct types like
c_store<int,int> and c_store<int,double>. But I cannot conclude that from
the example you gave, that's why you need to state the real problem.

Please elaborate why these work-arounds are not suitable in your case.

As to whether there was a discussion, try groups.google.com, that's a very
good source of information that has been discussed. Yes, you'd need to
dig through some posts. But that's what the search is for. Computer
memory is much more reliable than human, keep that in mind.

Victor
 
J

Jari Kalevi Savolainen

Several.

First, why did you reply to another, unrelated, thread instead of starting
a new one? Not a good idea.

That was my honest intention, mistake on my part.
Second, I am not sure what you expect. c_store<A,A> and c_store<A,B> are
two distinct and unrelated types. Unless you tell them to be friends of
each other, there is no seeing of any privates.
Yes.


Third, if you really need a design suggestion, post the real problem you
are trying to solve instead of a hypothetical, contrived, and non-working
solution.

I tried to provide a small compact code sample. Too small maybe and the
copy constructor I chose because I need to deep copy dynamically allocated
memory.
Now, there are several work-arounds. A friend member function would be
one. You can make them (instantiations) all friends of each other. You
can have a member function that simply returns a value of 'data'. I am
not sure what "exposure" you're afraid of.

Will try. Not sure if I've tried this.

The 'real' problem involves ptrs/dynamic memory. Keeping the pointer
private is my goal.
A common base class probably
won't work since an instance is not allowed to see even protected members
of an object of another derived type.

It can be done but you need to bounce pointers around.
Not going to get any deeper into how, but it works.
But it creates the same problem as methods returning ptr/value need to be
public.
Another solution is to drop the
'multiType' from the main template and _always_ have it for members:

template<class T> class c_store {
T data;
public:
template<class mT> c_store(mT md = 3) : data(md * 3) {}
c_store(c_store const & cs) : data(cs.data) {} // actually no need
};

That of course may not be acceptable if you do need distinct types like
c_store<int,int> and c_store<int,double>. But I cannot conclude that from
the example you gave, that's why you need to state the real problem.

Again I obviously provided bad code sample, in my 'real' project it really
makes a difference and solution:
template<class mT> c_store(mT md = 3) : data(md * 3) {}
Could result in unexpected behauvior, of course this is one way to do it
but it could easily lead to a situation where template generates code that
compiles fine but results are unexpected because the types are unsuitable
for operations performed.
Please elaborate why these work-arounds are not suitable in your case.

As to whether there was a discussion, try groups.google.com, that's a very
good source of information that has been discussed. Yes, you'd need to
dig through some posts. But that's what the search is for. Computer
memory is much more reliable than human, keep that in mind.

Did that but couldn't find anything specific to this.
 
R

Ron Natalie

Maciej said:
I've changed the option mt to mtd in project properties and it works.
Specifically he had the wrong runtime library for the compiler switch.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,434
Messages
2,571,690
Members
48,796
Latest member
Greg L.

Latest Threads

Top