Re: Deprecated POSIX functions ?
On 9/1/2010 2:49 PM, Goran Pusic wrote:
On Sep 1, 12:47 pm, Timothy Madden<terminato...@gmail.com> wrote:
Knowing about their undocumented _POSIX_ test macro in Visual Studio
really shed light on my view of things, so thank you again for it. Were
did you here or read about _POSIX_ ?
You prompt me to look. I was shooting off my hip, got lucky (blushes).
(Well, I knew that MS, at least formally, is... ahem, POSIX-
compliant).
Well, trying to actually use the _POSIX_ macro further in my project
shows that it does not do what I think, even if i can now get the ATL
headers to compile with it. :(
I do not understand what it is meant to do, but it looks like _POSIX_
just excludes many non ISO C symbols from the headers ... including
creat() :(
In the end the only way to get the POSIX functions is to define the
documented _CRT_NONSTDC_NO_WARNINGS to disable the warning about
deprecation.
I am getting tired ...
Thank you,
Timothy Madden
on startup, which just creates and empty
collection.
It is only called once.
It is filled in (also once) with a method of CMyColllection schematically of
the form
CMyCollection::FillIn()
{
CMyThing thing;
for( allthings )
{
thing = .... // fill in the thing
push_back( thing ); //*********
}
}
It is usually not changed, and lasts until the program shuts down.
It is never copied. (It has a copy constructor, because I feel nervous
without them, but it is never called.)
The destructor is called once, and just calls clear() (because I feel it
is neat to do so).
I am being told that the memory leak is associated with the CMyThing's copy
constructor invoked by push_back() above.
How can that be?
Even stranger, I have had all of this present in the code for years and a
memory leak has only been reported recently.
Any ideas gratefully received.
Dave
--
David Webber
Author of 'Mozart the Music Processor'
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mzusers/mailinglist.htm
On Wednesday, October 10, 2007 6:05 PM Norbert Unterberg wrote:
David Webber schrieb:
If the memory leak is associated with CMyThing's copy constructor then I guess
it contains some deep copy opearions? If you overrode the CMyThing's copy
constructor, did you also override it's assignment operator and destructor? See
the "Law of the Big Three".
http://www.artima.com/cppsource/bigtwo.html
Norbert
On Wednesday, October 10, 2007 6:05 PM Giovanni Dicanio wrote:
Hi Dave,
"David Webber" <dave@musical-dot-demon-dot-co.uk> ha scritto nel messaggio
news:untsc43CIHA.5976@TK2MSFTNGP02.phx.gbl...
[...]
Could you please try to use a Has-A "embedding" relationship (not Is-A via
inheritance), i.e. : putting a private/protected instance of
std::vector<CMyThing> into CMyCollection.
[...]
It would be interesting to see some code for CMyThing... (maybe it has got
some non-smart pointers that are not correctly copied, or it hasn't got a
virtual destructor that would be required...).
Also, you should pay attention about the C/C++ run-time used by each module
(DLLs and EXE).
I think it should be the same (e.g. debug multithreaded DLL, or
multithreaded DLL for release builds).
Maybe you are now using VS2005 which implements better checking for memory
leaks than VC6 or 2003...
Ciao
Giovanni
On Wednesday, October 10, 2007 6:32 PM Giovanni Dicanio wrote:
"Giovanni Dicanio" <giovanni.dicanio@invalid.it> ha scritto nel messaggio
news:%23vsdcn4CIHA.3884@TK2MSFTNGP05.phx.gbl...
[...]
One more thing: reading the above code, it seems that this is not the case,
but maybe you posted a simplification of real code. So: I think that you
should also pay attention about *where* (i.e. which module) you
allocate/free data.
i.e. I think that if you allocate something in the heap from module X (e.g.
a given DLL), you should also free that in the *same* module X.
I'm not sure, but I think it is not safe to allocate something in the heap
from module X, and free in module Y.
Giovanni
On Wednesday, October 10, 2007 6:37 PM David Webber wrote:
"Norbert Unterberg" <nunterberg@newsgroups.nospam> wrote in message
news:uX9Wym4CIHA.748@TK2MSFTNGP04.phx.gbl...
Not particularly deep...
... and yes - I am particular to the point of pedantry about that sort of
thing.
But explaining the problem has given me an idea.
Here's some real code:
=========================
this warning.
// Instantiate a vector:
// This seems to be necessary if the class derived from vector is to be
exported.
EXTERN_MZWN_API template class MZWN_API
std::allocator<CPercussionInstrument>;
EXTERN_MZWN_API template class MZWN_API std::vector<CPercussionInstrument>;
// class CPercussionSet
class MZWN_API CPercussionSet : public std::vector<CPercussionInstrument>
{
public:
CPercussionSet();
CPercussionSet( const CPercussionSet &ps );
virtual ~CPercussionSet();
CPercussionSet & operator = ( const CPercussionSet &ps );
//....
};
=============
I am pretty sure the copy constructor, destructor, and assignment of
CPercussionInstrument are ok (I am checking). I *am* a little concerned
about exporting this class from the DLL, (in which the only instance is
global) and wondering if that is at the root of things. It may not be
being correctly destroyed when the DLL is unloaded - though the destructor
*is* getting called.
Perhaps I should store a global; pointer to a CPercussionSet and explicitly
create and destroy it with new and delete. That way I'd have more control
over when it happens! I'll experiment.
Dave
--
David Webber
Author of 'Mozart the Music Processor'
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mzusers/mailinglist.htm
On Wednesday, October 10, 2007 6:46 PM David Webber wrote:
"Giovanni Dicanio" <giovanni.dicanio@invalid.it> wrote in message
news:%23FSVO24CIHA.4308@TK2MSFTNGP06.phx.gbl...
Thanks! This is the way I am starting to think too - see other post. With
the class being global in the DLL I am not in control of where it is
constructed and destroyed. I propose to do something about that tomorrow -
it's late now.
Dave
--
David Webber
Author of 'Mozart the Music Processor'
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mzusers/mailinglist.htm
.
On Wednesday, October 10, 2007 7:25 PM David Wilkinson wrote:
David Webber wrote:
Dace:
What happens if you call clear() on your vector from somewhere else
(like ExitInstance()) rather than waiting for your derived destructor to
do it.
Actually, I don't think calling clear() from the destructor is
necessary, because the destructors of the contained objects are
automatically called by the std::vector destructor. I think the problem
is that your derived constructor is getting called too late relative to
the leak reporting mechanism.
--
David Wilkinson
Visual C++ MVP
On Wednesday, October 10, 2007 7:33 PM David Ching wrote:
That's what I thought also, but then why would it only start happening
recently when nothing has changed?
-- David
On Wednesday, October 10, 2007 10:32 PM Doug Harrison [MVP] wrote:
On Wed, 10 Oct 2007 21:37:33 +0100, "David Webber"
<dave@musical-dot-demon-dot-co.uk> wrote:
That is the key sentence.
For some reason, your non-MFC DLL is loading before the MFC DLL now, and
during program termination, MFC is calling its "dump_spurious_leaks()"
function before your DLL has gotten the chance to destroy its globals.
See these messages for an explanation and workaround:
http://groups.google.com/group/microsoft.public.vc.mfc/msg/990674e598690af9
http://groups.google.com/group/microsoft.public.vc.language/msg/6b90e68f21529e56
--
Doug Harrison
Visual C++ MVP
On Thursday, October 11, 2007 3:30 AM David Webber wrote:
"David Ching" <dc@remove-this.dcsoft.com> wrote in message
news:YkdPi.2523$sm6.921@nlpi069.nbdc.sbc.com...
I do that anyway - which is another puzzle.
That is a puzzle too - unless I have accidentally changed a setting in the
project which causes it to be reported. I don't *think* I have.
It isn't very serious. It is a bit of memory which should be used unchanged
(mostly) for the duration of the program, so having the system free it on
exit, isn't a disaster. But it's sloppy and I just *hate* it!
[The only time the memory is changed is when someone changes language
options: the instruments are unloaded and reloaded with their names in the
new language.]
Dave
--
David Webber
Author of 'Mozart the Music Processor'
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mzusers/mailinglist.htm
On Thursday, October 11, 2007 3:43 AM David Webber wrote:
"Doug Harrison [MVP]" <dsh@mvps.org> wrote in message
news:3g1rg3dugtuqaat9d8e9q4gnen7q154vmb@4ax.com...
Thanks Doug,
That appears to explain just about everything. And it makes me very
happy, because it means I did not program a memory leak - and thus delays
the fall I expect following my pride in never doing so :-)
I try to avoid global objects like the plague and this was my only infection
in this DLL. Most of my stuff which really needs to be global is stored
as a static pointer in a class, and the object is created by my InitInstance
code and explicitly deleted on ExitInstance. Once Norbert had told me how
to find it, the coincidence of global object and (apparent) memory leak
started ringing alarm bells.
I am now restructuring to handle this object like the others - which should
cure it as the memory will be freed from a call made by the MFC module.
Onward and upward.
Dave
--
David Webber
Author of 'Mozart the Music Processor'
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mzusers/mailinglist.htm
On Thursday, October 11, 2007 5:24 AM David Webber wrote:
"Doug Harrison [MVP]" <dsh@mvps.org> wrote in message
news:3g1rg3dugtuqaat9d8e9q4gnen7q154vmb@4ax.com...
All fixed now - thanks again to everyone.
Dave
--
David Webber
Author of 'Mozart the Music Processor'
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mzusers/mailinglist.htm
On Thursday, October 11, 2007 5:40 AM Giovanni Dicanio wrote:
"David Webber" <dave@musical-dot-demon-dot-co.uk> ha scritto nel messaggio
news:OdLNni%23CIHA.2268@TK2MSFTNGP02.phx.gbl...
Thanks to you because we (or at least, I) learnt important lessons from your
post, like how super-important is to avoid global variables.
Giovanni
On Thursday, October 11, 2007 8:06 AM David Wilkinson wrote:
David Webber wrote:
In that case, it seems to me that the leak must be the memory allocated
for std::vector itself, rather than any memory internal to your CMyThing
objects.
What happens if you also shrink the vector to zero capacity (using the
swap trick)?
--
David Wilkinson
Visual C++ MVP
On Thursday, October 11, 2007 9:01 AM David Webber wrote:
"David Wilkinson" <no-reply@effisols.com> wrote in message
news:OR1ah8$CIHA.5024@TK2MSFTNGP06.phx.gbl...
I am rather concerned that I might know why. Well -ish. As I have an MFC
program with no main(), I put the _CrtSetBreakAlloc in the CWinApp drived
class constructor.
If the global vector object in the DLL was being constructed before the
CWinApp was constructed, it couldn't have actually stopped the program on
the vector's constuctor. The fact that it stopped when something was added
to the vector may have been a complete coincidence - in which case I've had
a monumental bit of luck :-(
So where does one put _CrtSetBreakAlloc to guarantee it is invoked before
absolutely anything is constructed?
Dave
--
David Webber
Author of 'Mozart the Music Processor'
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mzusers/mailinglist.htm
On Thursday, October 11, 2007 9:02 AM David Webber wrote:
"Giovanni Dicanio" <giovanni.dicanio@invalid.it> wrote in message
news:OzdOIr%23CIHA.5360@TK2MSFTNGP03.phx.gbl...
Yes I have told myself that many times. It is my punishment for not taking
enough notice :-)
Dave
--
David Webber
Author of 'Mozart the Music Processor'
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mzusers/mailinglist.htm
On Thursday, October 11, 2007 9:14 AM Giovanni Dicanio wrote:
"David Webber" <dave@musical-dot-demon-dot-co.uk> ha scritto nel messaggio
Gio
On Thursday, October 11, 2007 9:36 AM David Wilkinson wrote:
David Webber wrote:
Dave:
Constructing an empty vector does not assign any memory. When you add
things to it, the vector assigns memory and there may be additional
memory owned by the objects being placed in the vector.
I am not an expert on _CrtSetBreakAlloc(). I have always just used the
MFC DEBUG_NEW and have always been able to get rid of any leaks it
reported. But I don't use global objects.
--
David Wilkinson
Visual C++ MVP
On Thursday, October 11, 2007 9:39 AM David Ching wrote:
"David Webber" <dave@musical-dot-demon-dot-co.uk> wrote in message
news:OJpqGdADIHA.2004@TK2MSFTNGP06.phx.gbl...
There is another way.
http://msdn2.microsoft.com/en-us/library/w2fhc9a3(VS.80).aspx describes
setting the _crtBreakAlloc variable to the desired value instead of calling
_CrtSetBreakAlloc(). So just step into your code in the debugger so it
stops at the entrypoint, then set this variable in the watch window.
OTOH, I'm not sure if it's too late once you step into your code... global
vars might have already been init. But you can try it.
BTW, I'm not sure why it's any concern because this is not a true memory
leak in that the memory is freed when the app is exited anyway. I
understand you don't like to see the mem leak output though, since it makes
it easy to ignore true memory leak output.
-- David
On Thursday, October 11, 2007 9:40 AM David Ching wrote:
Your CWinApp derived class is a global object! :-)
-- David
On Thursday, October 11, 2007 10:22 AM David Webber wrote:
"David Wilkinson" <no-reply@effisols.com> wrote in message
news:OugHAvADIHA.1056@TK2MSFTNGP03.phx.gbl...
I'm not sure in what sense you mean this. Obviously if I put
CMyVector v;
Then &v will tell me where it is and sizeof v will tell me how big it is.
Ok, it is not being assigned dynamically but as a Global variable it sits
there and does not go out of scope until the program ends. In fact I have
always been rather vague on at what point its memory will be freed up,
because I have never really needed to know - until now :-)
But each will have its own block of assigned memory and I only got 1 leak
with 200 odd objects.
I too am a believer in DEBUG_NEW but this was happening in a non-MFC DLL.
Dave
--
David Webber
Author of 'Mozart the Music Processor'
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mzusers/mailinglist.htm
On Thursday, October 11, 2007 10:56 AM Giovanni Dicanio wrote:
"David Ching" <dc@remove-this.dcsoft.com> ha scritto nel messaggio
news:5LpPi.1560$Pv2.668@newssvr23.news.prodigy.net...
Yes, I was thinking about app class, too.
Maybe, in an elegant object-oriented designed system, the app instance
should be the only global object, and every other object should be created
by the app.
Giovanni
On Thursday, October 11, 2007 1:25 PM David Wilkinson wrote:
David Ching wrote:
David:
Yes, but I do not think its constructor assigns any memory.
--
David Wilkinson
Visual C++ MVP
On Thursday, October 11, 2007 1:26 PM Doug Harrison [MVP] wrote:
it is fine if both modules link to the same CRT DLL. Given that David is
sharing C++ classes between modules, it is pretty much required.
--
Doug Harrison
Visual C++ MVP
On Thursday, October 11, 2007 1:26 PM Doug Harrison [MVP] wrote:
On Thu, 11 Oct 2007 11:40:20 +0200, "Giovanni Dicanio"
<giovanni.dicanio@invalid.it> wrote:
I hope there is a better reason than to avoid spurious leak reporting by
MFC. :) It's not just "globals"; this problem affects any object that is
destroyed after MFC calls its "cause_spurious_leak_report()" function. For
example, MFC would have caused the same problem if the OP's vector had been
a static data member of one of the classes in his DLL.
When I said "That is the key sentence," the implied second part was,
"...that helps me identify the problem." I did not mean that having a
global object was the problem, just that "non-MFC DLL", "global object",
and mysterious "memory leaks" remind me of this long-standing MFC bug.
--
Doug Harrison
Visual C++ MVP
On Thursday, October 11, 2007 1:37 PM David Wilkinson wrote:
David Webber wrote:
Dave:
But only heap memory contributes to memory leaks, yes? If the objects
you put in your vector do not themselves assign heap memory (i.e. use
new internally) they will not contribute to memory leaks. The only
possible leak will come from the memory assigned by the vector itself.
And this should be released by the destructor, because std::vector is a
well-behaved RAII class.
I think the problem is just that the destructor of your global object is
getting called too late (and Doug thinks so also, so this must be right...).
--
David Wilkinson
Visual C++ MVP
On Thursday, October 11, 2007 2:09 PM David Webber wrote:
"David Wilkinson" <no-reply@effisols.com> wrote in message
news:O%23roW1CDIHA.5228@TK2MSFTNGP05.phx.gbl...
I wasn't sure of that.
Yes, it makes sense.
Dave
--
David Webber
Author of 'Mozart the Music Processor'
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mzusers/mailinglist.htm
Date: Mon, 24 Apr 2006 15:21:02 -0700
Lines: 15
Message-ID: <3E3F94C3-009C-40C2-BE1A-6F4A213EE48B@microsoft.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: 7bit
X-Newsreader: Microsoft CDO for Windows 2000
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830
Newsgroups: microsoft.public.vc.language
NNTP-Posting-Host: TK2MSFTNGXA01.phx.gbl 10.40.2.250
Path: text.usenetserver.com!atl-c01.usenetserver.com!news.usenetserver.com!atl-c02.usenetserver.com!news.usenetserver.com!newscon02.news.prodigy.com!prodigy.net!wn13feed!worldnet.att.net!207.217.77.102!elnk-nf2-pas!newsfeed.earthlink.net!newshub.sdsu.edu!msrtrans!TK2MSFTFEEDS01.phx.gbl!TK2MSFTNGP01.phx.gbl!TK2MSFTNGXA01.phx.gbl
Xref: usenetserver.com microsoft.public.vc.language:330063
X-Received-Date: Mon, 24 Apr 2006 18:24:17 EDT (text.usenetserver.com)
memset does not allocate any memory, it just fills existing memory.
Image is probably a stack (automatic) variable, so the memory for the
structure itself is allocated when you declare it. But the structure
only contains a pointer to the actual memory buffer, and memset
helpfully sets this pointer to NULL.
With all due respect, I suggest you go back to basics and review your
favorite C 101 textbook.
Got it! malloc was missing.
Never cracked open a book on C in my life and, with the short time I have
left, well on the way of never having to! ;-)
Thanks.