The Art of C++

[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::_DebugHeap Tag_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::_DebugHeap Tag_t const &,char *,int)"
(??2@YAPAXIABU_ DebugHeapTag_t@ std@@PADH@Z)

What's wrong?
Maciej

[Mike Hewson]

Maciej wrote:

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::_DebugHeap Tag_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::_DebugHeap Tag_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.

--

Cheers
--
Hewson::Mike
"This letter is longer than usual because I lack the time to make it
shorter" - Blaise Pascal

[Mike Hewson]

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

??3@YAXPAXABU_D ebugHeapTag_t@s td@@PADH@Z

:-)

--

Cheers
--
Hewson::Mike
"This letter is longer than usual because I lack the time to make it
shorter" - Blaise Pascal

[msalters]

Maciej wrote:

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::_DebugHeap Tag_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

[msalters]

Maciej wrote:

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::_DebugHeap Tag_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

[Maciej]

Uzytkownik "msalters" <Mi************ *@logicacmg.com > napisal w wiadomosci
news:11******** **************@ f14g2000cwb.goo glegroups.com.. .

Maciej wrote:

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::_DebugHeap Tag_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

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

Thanks,
Maciej

[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<typena me srcMultiType> //storeType has to match
c_store(const c_store<storeTy pe, 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<typena me T, typename_onlyco de U>
where typename_onlyco de couldn't be used in datamember declarations.
Therefore no need for access checking.

Thoughts?

[Victor Bazarov]

Jari Kalevi Savolainen wrote:

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<typena me srcMultiType> //storeType has to match
c_store(const c_store<storeTy pe, 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<typena me T, typename_onlyco de U>
where typename_onlyco de 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,dou ble>. 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.c om, 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

[Jari Kalevi Savolainen]

On Tue, 4 Jan 2005, Victor Bazarov wrote:

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,dou ble>. 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.c om, 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.

Victor

[Ron Natalie]

Maciej wrote:

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.

Specifically he had the wrong runtime library for the compiler switch.