Subject: Enhance Your Sex Life with Viagra - msg#00083

Previous Message by Date: (click to view message preview)

std::auto_ptr errors with MINGW, seems ok to MS Visual C++

Hey everyone, congrats on the new install process for 2.0.0 - quite slick. Also glad to see vtable thunking is on by default. Looks like MINGW is poised to insinuate itself onto a lot of development desktops! In any case, I'm trying to compile a program that does o.k. with MS Visual Studio .NET, but chokes on some usages of auto_ptr in MINGW. I've researched it a bit, but I know so little about smart pointers that I can't hardly make heads or tails of the guru debates about the various versions of std::auto_ptr and their quirks! What it seems to come down to is that using the install from 2.0.0 I get errors that look like: foo.cpp:200: no matching function for call to `std::auto_ptr<MODBASE>::auto_ptr(std::auto_ptr<MODBASE>)' D:/DEV/MINGW/include/c++/3.2/memory:346: candidates are: std::auto_ptr<_Tp>::auto_ptr(std::auto_ptr_ref<_Tp>) [with _Tp = MODBASE] D:/DEV/MINGW/include/c++/3.2/memory:216: std::auto_ptr<_Tp>::auto_ptr(std::auto_ptr<_Tp1>&) [with _Tp1 = MODBASE, _Tp = MODBASE] D:/DEV/MINGW/include/c++/3.2/memory:203: std::auto_ptr<_Tp>::auto_ptr(std::auto_ptr<_Tp>&) [with _Tp = MODBASE] This results from a piece of source that looks like: 199: P<MOD<DOC_MUSIC> > pmodCreate (new DOC_MUSIC::MOD_CREATE()); 200: pdoc->ApplyMod(pmodCreate); The prototype for ApplyMod looks like: void DOC::ApplyMod(std::auto_ptr<MODBASE> pmod); My intention is to pass ownership of the "MOD" object to the document (and MOD<xxx> is just a way of generating a class derived from MODBASE). All seems to work fine if I don't use a derived class auto_ptr: 199: P<MODBASE> pmodCreate (new DOC_MUSIC::MOD_CREATE()); 200: pdoc->ApplyMod(pmodCreate); As it happens, though, I'm trying to discourage explicit use of MODBASE in this particular body of code. Does anyone understand the issues here well enough to tell me what might be going wrong, and why this conversion would work in MSVC and not in MINGW? Any way to make it work? Many thanks! ---Brian _________________________________________________________________ Unlimited Internet access for only $21.95/month.  Try MSN! http://resourcecenter.msn.com/access/plans/2monthsfree.asp ------------------------------------------------------- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en _______________________________________________ MinGW-users mailing list MinGW-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users

Next Message by Date: click to view message preview

Re: Mingw on AlphaNT

Steven Edwards <steven_ed4153-/E1597aS9LQAvxtiuMwx3w@xxxxxxxxxxxxxxxx> wrote: > Recently HP donated a Digital Personal Workstation to me > for the purpose of starting a port of ReactOS to alphaAXP > and I am looking for some advice on getting a working Mingw > going on it. Has anyone tried to build a alpha-mingw32 > cross-compiler on AlphaLinux? The 'ftp://quiduck.com' used to have a 'alpha-mingw32' port a couple of years ago... Don't know who was the provider, but there it was. > I know the old gcc 2.7 and 2.8 cygwin ports had support for > Mingw so I assume that building 2.95.3 or 3.2 might still > have a chance as Interix and Cygwin supported AlphaNT at > one point in time and Alpha*-*-* is still a supported platform > for gcc. I know the official Cygwin once supporting NT/PowerPC, but not NT/Alpha or NT/MIPS... The 'quiduck.com' then had an unofficial NT/Alpha port of Cygwin (just like the Mingw-port) too. > 3. Attempt to build a alpha-mingw32 cross-compiler and binutils (TODO) I don't remember the official GNU binutils supporting the PE-format on Alpha, the 'native' ports at quiduck may have used some native MS binutils. So a crosscompiler without binutils is somehow 'orphan' - one can produce assembly code but not compile into objects or link on the cross-platform... But maybe the 'quiduck' or the GNU 'binutils' maillist archives have some unmerged patches for Alpha/PE, assumed to be the object format there... The PowerPC/PE, MIPS/PE, ARM/PE, MCORE/PE, SH/PE formats are though supported, because of WinCE, EPOC etc. using PE... Cheers, Kai ------------------------------------------------------- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en _______________________________________________ MinGW-users mailing list MinGW-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users

Previous Message by Thread: click to view message preview

std::auto_ptr errors with MINGW, seems ok to MS Visual C++

Hey everyone, congrats on the new install process for 2.0.0 - quite slick. Also glad to see vtable thunking is on by default. Looks like MINGW is poised to insinuate itself onto a lot of development desktops! In any case, I'm trying to compile a program that does o.k. with MS Visual Studio .NET, but chokes on some usages of auto_ptr in MINGW. I've researched it a bit, but I know so little about smart pointers that I can't hardly make heads or tails of the guru debates about the various versions of std::auto_ptr and their quirks! What it seems to come down to is that using the install from 2.0.0 I get errors that look like: foo.cpp:200: no matching function for call to `std::auto_ptr<MODBASE>::auto_ptr(std::auto_ptr<MODBASE>)' D:/DEV/MINGW/include/c++/3.2/memory:346: candidates are: std::auto_ptr<_Tp>::auto_ptr(std::auto_ptr_ref<_Tp>) [with _Tp = MODBASE] D:/DEV/MINGW/include/c++/3.2/memory:216: std::auto_ptr<_Tp>::auto_ptr(std::auto_ptr<_Tp1>&) [with _Tp1 = MODBASE, _Tp = MODBASE] D:/DEV/MINGW/include/c++/3.2/memory:203: std::auto_ptr<_Tp>::auto_ptr(std::auto_ptr<_Tp>&) [with _Tp = MODBASE] This results from a piece of source that looks like: 199: P<MOD<DOC_MUSIC> > pmodCreate (new DOC_MUSIC::MOD_CREATE()); 200: pdoc->ApplyMod(pmodCreate); The prototype for ApplyMod looks like: void DOC::ApplyMod(std::auto_ptr<MODBASE> pmod); My intention is to pass ownership of the "MOD" object to the document (and MOD<xxx> is just a way of generating a class derived from MODBASE). All seems to work fine if I don't use a derived class auto_ptr: 199: P<MODBASE> pmodCreate (new DOC_MUSIC::MOD_CREATE()); 200: pdoc->ApplyMod(pmodCreate); As it happens, though, I'm trying to discourage explicit use of MODBASE in this particular body of code. Does anyone understand the issues here well enough to tell me what might be going wrong, and why this conversion would work in MSVC and not in MINGW? Any way to make it work? Many thanks! ---Brian _________________________________________________________________ Unlimited Internet access for only $21.95/month.  Try MSN! http://resourcecenter.msn.com/access/plans/2monthsfree.asp ------------------------------------------------------- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en _______________________________________________ MinGW-users mailing list MinGW-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users

Next Message by Thread: click to view message preview

(Fwd) Re: Mingw on AlphaNT

Kai Ruottu <kai.ruottu-LhJqALMAyK3QT0dZR+AlfA@xxxxxxxxxxxxxxxx> wrote: > The 'ftp://quiduck.com' used to have a 'alpha-mingw32' port Ooops, of course it was 'ftp://guiduck.com'.... ------------------------------------------------------- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en _______________________________________________ MinGW-users mailing list MinGW-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users