Connecting Tech Pros Worldwide Forums | Help | Site Map

The Art of C++

Maciej
Guest
 
Posts: n/a
#1: Jul 23 '05
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



Mike Hewson
Guest
 
Posts: n/a
#2: Jul 23 '05

re: The Art of C++


Maciej wrote:[color=blue]
> 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
>
>[/color]

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
Guest
 
Posts: n/a
#3: Jul 23 '05

re: The Art of C++


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

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

:-)

--

Cheers
--
Hewson::Mike
"This letter is longer than usual because I lack the time to make it
shorter" - Blaise Pascal
msalters
Guest
 
Posts: n/a
#4: Jul 23 '05

re: The Art of C++



Maciej wrote:[color=blue]
> Hi,
>
> I tried to build windl project from the book 'The Art of C++" in[/color]
VS.NET 7[color=blue]
> and it fails. I attached all required .lib files. I got the following[/color]
error[color=blue]
> messages from the linker:
>
> windl error LNK2001: unresolved external symbol __malloc_dbg
> windl error LNK2019: unresolved external symbol __free_dbg referenced[/color]
in[color=blue]
> function "void __cdecl operator delete(void *,struct[/color]
std::_DebugHeapTag_t[color=blue]
> const &,char *,int)" (??3@YAXPAXABU_DebugHeapTag_t@std@@PADH@Z)[/color]

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

Regards,
Michiel Salters

msalters
Guest
 
Posts: n/a
#5: Jul 23 '05

re: The Art of C++



Maciej wrote:[color=blue]
> Hi,
>
> I tried to build windl project from the book 'The Art of C++" in[/color]
VS.NET 7[color=blue]
> and it fails. I attached all required .lib files. I got the following[/color]
error[color=blue]
> messages from the linker:
>
> windl error LNK2001: unresolved external symbol __malloc_dbg
> windl error LNK2019: unresolved external symbol __free_dbg referenced[/color]
in[color=blue]
> function "void __cdecl operator delete(void *,struct[/color]
std::_DebugHeapTag_t[color=blue]
> const &,char *,int)" (??3@YAXPAXABU_DebugHeapTag_t@std@@PADH@Z)[/color]

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

Regards,
Michiel Salters

Maciej
Guest
 
Posts: n/a
#6: Jul 23 '05

re: The Art of C++



Uzytkownik "msalters" <Michiel.Salters@logicacmg.com> napisal w wiadomosci
news:1104837363.508627.254820@f14g2000cwb.googlegr oups.com...[color=blue]
>
> Maciej wrote:[color=green]
> > Hi,
> >
> > I tried to build windl project from the book 'The Art of C++" in[/color]
> VS.NET 7[color=green]
> > and it fails. I attached all required .lib files. I got the following[/color]
> error[color=green]
> > messages from the linker:
> >
> > windl error LNK2001: unresolved external symbol __malloc_dbg
> > windl error LNK2019: unresolved external symbol __free_dbg referenced[/color]
> in[color=green]
> > function "void __cdecl operator delete(void *,struct[/color]
> std::_DebugHeapTag_t[color=green]
> > const &,char *,int)" (??3@YAXPAXABU_DebugHeapTag_t@std@@PADH@Z)[/color]
>
> You did not attach all reuired .lib files, despite your statement. The
> .lib file with __malloc_dbg is missing.
>
> Regards,
> Michiel Salters
>[/color]

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

Thanks,
Maciej


Jari Kalevi Savolainen
Guest
 
Posts: n/a
#7: Jul 23 '05

re: The Art of C++


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?

Victor Bazarov
Guest
 
Posts: n/a
#8: Jul 23 '05

re: The Art of C++


Jari Kalevi Savolainen wrote:[color=blue]
> Bit of code first:
>
> template <typename storeType, typename multiType>
> class c_store {
> storeType data;
> public:
> c_store() {
> data = multiType(3) * 3;
> }[/color]

I'd do

c_store() : data(multiType(3)*3) {}
[color=blue]
>
> 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?[/color]

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
Jari Kalevi Savolainen
Guest
 
Posts: n/a
#9: Jul 23 '05

re: The Art of C++


On Tue, 4 Jan 2005, Victor Bazarov wrote:
[color=blue]
> Several.
>
> First, why did you reply to another, unrelated, thread instead of starting
> a new one? Not a good idea.[/color]

That was my honest intention, mistake on my part.
[color=blue]
>
> 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.[/color]

Yes.
[color=blue]
>
> 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.
>[/color]

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.
[color=blue]
> 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.[/color]

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

The 'real' problem involves ptrs/dynamic memory. Keeping the pointer
private is my goal.
[color=blue]
> 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.[/color]

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.
[color=blue]
> 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.
>[/color]

Again I obviously provided bad code sample, in my 'real' project it really
makes a difference and solution:[color=blue]
> template<class mT> c_store(mT md = 3) : data(md * 3) {}[/color]
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.
[color=blue]
> 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.[/color]

Did that but couldn't find anything specific to this.
[color=blue]
>
> Victor
>[/color]
Ron Natalie
Guest
 
Posts: n/a
#10: Jul 23 '05

re: The Art of C++


Maciej wrote:
[color=blue][color=green]
>>You did not attach all reuired .lib files, despite your statement. The
>>.lib file with __malloc_dbg is missing.
>>
>>Regards,
>>Michiel Salters
>>[/color]
>
>
> I've changed the option mt to mtd in project properties and it works.
>[/color]
Specifically he had the wrong runtime library for the compiler switch.

Closed Thread