BUG: compiler allows for creation of objects without destructor compiled

[Maxim Yegorushkin]

The following code:

#include <iostream>

class base
{
private:
virtual ~base()
{
std::cout << "virtual ~base()\n";
}
};

class derived : public base // must result in a compile time error
{
// does result in a compile time error when uncommented
//~derived() {}
};

int main()
{
// does result in a compile time error when uncommented
//derived dd;

derived* d = new derived;
delete d;
}

Produces no error when compiled thought it must. It only produces 2
warnings:

warning C4624: 'derived' : destructor could not be generated because a
base class destructor is inaccessible
warning C4527: instances of class 'derived' can never be destroyed -
user-defined destructor required

The second warning is false - the code does create an instance of derived
and what much worse it does destroy it. At runtime it seems like base's
destructor does not get called.

--
Maxim Yegorushkin
MetaCommunications Engineering
http://www.meta-comm.com/engineering/

[Rudresh]

Hi ,
Try this :
class bas

public
virtual ~base(

TRACE("virtual ~base()\n")

}

class derived : public base // must result in a compile time erro

// does result in a compile time error when uncommente
public :
~derived() {}
}

See the code you have written. : you have made destructor "Private ". So that it would not be visible in derived also.
That's why it is giving compile time error.

[Hendrik Schober]

Rudresh <ru***********@efi.com> wrote:

[...]
See the code you have written. : you have made destructor "Private ".
So that it would not be visible in derived also.
That's why it is giving compile time error.

Look at the posting again. I'd say:
"That's why it _should_ be giving a
compile-time error."
I'd call this a bug. So does Comeau:

Comeau C/C++ 4.3.3 (Aug 6 2003 15:13:37) for ONLINE_EVALUATION_BETA1
Copyright 1988-2003 Comeau Computing. All rights reserved.
MODE:strict errors C++

"ComeauTest.c", line 12: error: "base::~base()" is inaccessible
class derived : public base // must result in a compile time error
^
detected during implicit generation of "derived::derived()" at line
23

"ComeauTest.c", line 12: error: "base::~base()" is inaccessible
class derived : public base // must result in a compile time error
^
detected during:
implicit generation of "derived::~derived()" at line 23
implicit generation of "derived::derived()" at line 23

2 errors detected in the compilation of "ComeauTest.c".

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

[Maxim Yegorushkin]

Rudresh wrote:

See the code you have written. : you have made destructor "Private ". So
That is my intent.
that it would not be visible in derived also.
That's why it is giving compile time error.

The problem is that it *does not* give a compile error but it must.

--
Maxim Yegorushkin

[David Olsen]

Maxim Yegorushkin wrote:

The following code: [edited for brevity]
#include <iostream>
class base
{
private:
virtual ~base() { }
};
class derived : public base { };

int main()
{
derived* d = new derived;
delete d;
}

Produces no error when compiled thought it must. It only produces 2
warnings:

According to the C++ standard (12.4/5) it is not an error to define a
class whose destructor cannot be defined (class "derived" in your
example). But it is an error to actually call the destructor of that
class. So the code
delete d;
should be an error, since it calls class derived's destructor. It is a
bug in the compiler that the error is not being reported. The bug is
still present in VC7.1.

--
David Olsen
qg********@yahoo.com

[Maxim Yegorushkin]

David Olsen wrote:

[]

According to the C++ standard (12.4/5) it is not an error to define a
class whose destructor cannot be defined (class "derived" in your
example). But it is an error to actually call the destructor of that
class.

Does it mean that Comeau is wrong about producing the error message in
Hendrik Schober's posting?

--
Maxim Yegorushkin

[David Olsen]

Maxim Yegorushkin wrote:

David Olsen wrote:

According to the C++ standard (12.4/5) it is not an error to define a
class whose destructor cannot be defined (class "derived" in your
example). But it is an error to actually call the destructor of that
class.

Does it mean that Comeau is wrong about producing the error message in
Hendrik Schober's posting?

Yes and no. Comeau online (http://www.comeaucomputing.com/tryitout/)
seems to have it bugs in this area, which are different than VC's bugs.
It correctly accepts:

class base { virtual ~base() { } };
class derived : public base { };

But it rejects the following, which should be valid code because the
destructor is never used:

class base { virtual ~base() { } };
class derived : public base { };
derived *f() { return new derived; }

And it accepts the following, which it should reject because the
destructor is used:

class base { virtual ~base() { } };
class derived : public base { };
void f(derived *x) { delete x; }

--
David Olsen
qg********@yahoo.com

[Maxim Yegorushkin]

David Olsen wrote:

According to the C++ standard (12.4/5) it is not an error to define a
class whose destructor cannot be defined (class "derived" in your
example). But it is an error to actually call the destructor of that
class.

Thank you, I did not know that.
Does it mean that Comeau is wrong about producing the error message in
Hendrik Schober's posting?

Yes and no. Comeau online (http://www.comeaucomputing.com/tryitout/)
seems to have it bugs in this area, which are different than VC's bugs.

[]

So, are MS compiler guys going to fix it?

--
Maxim Yegorushkin

[Carl Daniel [VC++ MVP]]

Maxim Yegorushkin wrote:

So, are MS compiler guys going to fix it?
It's already fixed in Whidbey ("VC8").
cl -c -EHs privatedest0408.cpp

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.40309 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.

privatedest0408.cpp
privatedest0408.cpp(8) : warning C4624: 'derived' : destructor could not be
generated because a base class destructor is inaccessible
privatedest0408.cpp(14) : error C2248: 'base::~base' : cannot access private
member declared in class 'base'
privatedest0408.cpp(5) : see declaration of 'base::~base'
privatedest0408.cpp(3) : see declaration of 'base'
This diagnostic occurred in the compiler generated function
'derived::~derived(void)'

Since there's an easy workaround (just don't write illegal code) it's
unlikely that this will be fixed in any other form (patch, service pack,
etc) before Whidbey ships ("1st half of 2005" is the latest official word).

-cd

[Maxim Yegorushkin]

David Olsen wrote:

Yes and no. Comeau online (http://www.comeaucomputing.com/tryitout/)
seems to have it bugs in this area, which are different than VC's bugs.
[]
But it rejects the following, which should be valid code because the
destructor is never used:

class base { virtual ~base() { } };
class derived : public base { };
derived *f() { return new derived; }

I believe Comeau rejects it correctly. If derived constructor throws here
the base subobject destructor must be called (and then operator delete to
deallocate storage). But the base destructor is unaccessable.

--
Maxim Yegorushkin

[Maxim Yegorushkin]

Carl Daniel [VC++ MVP] <cp*****************************@mvps.org.nospam >
wrote:

[]

Since there's an easy workaround (just don't write illegal code) it's
unlikely that this will be fixed in any other form (patch, service pack,
etc) before Whidbey ships ("1st half of 2005" is the latest official
word).

I think the advice not to write illegal code has proved to be completely
useless and did not save MS consumers from writing tons of illegal code
with errors like binding non-const references to temporaries.

--
Maxim Yegorushkin

[Carl Daniel [VC++ MVP]]

Maxim Yegorushkin wrote:

Carl Daniel [VC++ MVP]

Since there's an easy workaround (just don't write illegal code) it's
unlikely that this will be fixed in any other form (patch, service
pack, etc) before Whidbey ships ("1st half of 2005" is the latest
official word).

I think the advice not to write illegal code has proved to be
completely useless and did not save MS consumers from writing tons of
illegal code with errors like binding non-const references to
temporaries.

There's an important difference though: In the case you cite people were
(are, will be) writing illegal (according to the standard) that does
something useful, well defined and predictable with a particular
(pre-standard) tool.

In the case of this bug the resulting program clearly doesn't execute as
intended so it's very unlikely that there's a substantial body of code
that's relying on this non-standard (undocumented, undefined, unpredictable)
behavior.

-cd

[Edward Diener]

Carl Daniel [VC++ MVP] wrote:

Maxim Yegorushkin wrote:

So, are MS compiler guys going to fix it?

It's already fixed in Whidbey ("VC8").

cl -c -EHs privatedest0408.cpp

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.40309
for 80x86 Copyright (C) Microsoft Corporation. All rights reserved.

privatedest0408.cpp
privatedest0408.cpp(8) : warning C4624: 'derived' : destructor could
not be generated because a base class destructor is inaccessible
privatedest0408.cpp(14) : error C2248: 'base::~base' : cannot access
private member declared in class 'base'
privatedest0408.cpp(5) : see declaration of 'base::~base'
privatedest0408.cpp(3) : see declaration of 'base'
This diagnostic occurred in the compiler generated function
'derived::~derived(void)'

Since there's an easy workaround (just don't write illegal code) it's
unlikely that this will be fixed in any other form (patch, service
pack, etc) before Whidbey ships ("1st half of 2005" is the latest
official word).

You say that as if you believe that if a serious some bug has no easy
workaround it is likely that it will be fixed before Whidbey ships <g> .

[Maxim Yegorushkin]

Carl Daniel [VC++ MVP] <cp*****************************@mvps.org.nospam >
wrote:

Maxim Yegorushkin wrote:

Carl Daniel [VC++ MVP]

Since there's an easy workaround (just don't write illegal code) it's
unlikely that this will be fixed in any other form (patch, service
pack, etc) before Whidbey ships ("1st half of 2005" is the latest
official word).

I think the advice not to write illegal code has proved to be
completely useless and did not save MS consumers from writing tons of
illegal code with errors like binding non-const references to
temporaries.

There's an important difference though: In the case you cite people were
(are, will be) writing illegal (according to the standard) that does
something useful, well defined and predictable with a particular
(pre-standard) tool.

In the case of this bug the resulting program clearly doesn't execute as
intended so it's very unlikely that there's a substantial body of code
that's relying on this non-standard (undocumented, undefined,
unpredictable)
behavior.

Yes, that makes a difference.

--
Maxim Yegorushkin

[Carl Daniel [VC++ MVP]]

Edward Diener wrote:

Carl Daniel [VC++ MVP] wrote:

Since there's an easy workaround (just don't write illegal code) it's
unlikely that this will be fixed in any other form (patch, service
pack, etc) before Whidbey ships ("1st half of 2005" is the latest
official word).

You say that as if you believe that if a serious some bug has no easy
workaround it is likely that it will be fixed before Whidbey ships
<g> .

If a serious bug has no easy workaround and you make the appropriate
overtures with PSS, there IS a fair chance that it will be fixed before
Whidbey ships. Of course, "serious" has to be properly defined. If you
have a 10MLOC source code base that built with VC6 but doesn't run when
built with VC7.1 due to a codegen bug with no tractable workaround, that'd
be SERIOUS. If you reported such a bug to PSS, it's pretty likely that
you'd get a fix.

If you find a bug that prevents you from using some particular idiom that
compiles correctly with GCC but not VC7.1, I'd guess you'd be a lot less
likely to wrangle a patch out of PSS since the obivous solution is to simply
not use that idiom when writing new code.

-cd

[Edward Diener]

Carl Daniel [VC++ MVP] wrote:

Edward Diener wrote:

Carl Daniel [VC++ MVP] wrote:

Since there's an easy workaround (just don't write illegal code)
it's unlikely that this will be fixed in any other form (patch,
service pack, etc) before Whidbey ships ("1st half of 2005" is the
latest official word).

You say that as if you believe that if a serious some bug has no easy
workaround it is likely that it will be fixed before Whidbey ships
<g> .

If a serious bug has no easy workaround and you make the appropriate
overtures with PSS, there IS a fair chance that it will be fixed
before Whidbey ships. Of course, "serious" has to be properly
defined. If you have a 10MLOC source code base that built with VC6
but doesn't run when built with VC7.1 due to a codegen bug with no
tractable workaround, that'd be SERIOUS. If you reported such a bug
to PSS, it's pretty likely that you'd get a fix.

I believe that the infamous DLL initialization bug for mixed mode C++
programming of assemblies in NET 2003 is a serious bug. The workaround of
creating a pure mode assembly is not a viable option for C++ programmers
whose use of the C++ standard library is by far the norm in C++ programming.
Microsoft's unwillingness to fix this for the life of .NET 2003 is an
example of a company using their monetary power to greatly inhibit the use
of a community of programmers, C++ programmers, when it comes to the .NET
programming world. There are no other workarounds except no to do mixed mode
DLL assembly programming in C++ for .NET 2003. There is no reasoning for not
having put out a service pack for .NET 2003 as quickly as possible, once
this bug was discovered which was shortly after the release of .NET 2003,
for fixing this problem. Telling C++ programmers that their mixed mode
assembly may hang up the end-user, no matter how slim a chance this may be,
and that there is no sure workaround to this except not to write mixed mode
DLL assemblies, is tantamount to telling C++ programmers that they can not
write mixed mode DLL assembles in C++ for .NET 2003, in other words that
they can not write reusable components and classes in .NET 2003 in their own
languiage in the normal way.

This is one of the primary examples in my career as a programmer of a bug
which a company should have fixed and has decided not to.

[David Lowndes]

>Microsoft's unwillingness to fix this for the life of .NET 2003 is an

example of a company using their monetary power to greatly inhibit the use
of a community of programmers, C++ programmers, when it comes to the .NET
programming world.

Why wouldn't it be in MS's (financial) interests to have C++
developers completely happy to use .Net?

From comments I've seen regarding this problem, it was pretty deep
rooted and difficult to fix.

Dave
--
MVP VC++ FAQ: http://www.mvps.org/vcfaq

[Carl Daniel [VC++ MVP]]

Edward Diener wrote:

I believe that the infamous DLL initialization bug for mixed mode C++
programming of assemblies in NET 2003 is a serious bug. The
workaround of creating a pure mode assembly is not a viable option
for C++ programmers whose use of the C++ standard library is by far
the norm in C++ programming. Microsoft's unwillingness to fix this
for the life of .NET 2003 is an example of a company using their
monetary power to greatly inhibit the use of a community of
programmers, C++ programmers, when it comes to the .NET programming
world.

You're 100% wrong about that. The reason the VC++ team didn't provide a
real fix to the loader lock issue until Whidbey is twofold (as I understand
it). First, the issue was not fully understood until very late in the
Everett (7.1) beta cycle. At that point it was too late to build a proper
fix but there was time to do something, which they did. Second, the problem
has it's roots deep inside the NT loader and the CLR and required changes
far outside the realm of the VC++ team to fix - it simply wasn't possible to
coordinate such a deep and far-reaching change until Whidbey. It's
unfortunate. No one likes it. No one's very happy about it. But to
attribute MS's response to this bug to muscle flexing or malice is simply
ignorant.

-cd

[Edward Diener]

David Lowndes wrote:

Microsoft's unwillingness to fix this for the life of .NET 2003 is an
example of a company using their monetary power to greatly inhibit
the use of a community of programmers, C++ programmers, when it
comes to the .NET programming world.
Why wouldn't it be in MS's (financial) interests to have C++
developers completely happy to use .Net?

Do you believe it is not in MS's financial interests to promote the use of
C#, even over C++, as a programming language ? I think you must be naive if
you believe so. I am not saying that is necessarily the reason why the bug
exists, but I believe, no matter what others will say, it is part of the
reason why no efforts were made to fix it in .NET 1.1.

From comments I've seen regarding this problem, it was pretty deep
rooted and difficult to fix.

It may have been difficult to fix but that is no reason not to do so for a
period which will extend more than two years by the time VC 2005 is
scheduled to finally be released.

[Edward Diener]

Carl Daniel [VC++ MVP] wrote:

Edward Diener wrote:

I believe that the infamous DLL initialization bug for mixed mode C++
programming of assemblies in NET 2003 is a serious bug. The
workaround of creating a pure mode assembly is not a viable option
for C++ programmers whose use of the C++ standard library is by far
the norm in C++ programming. Microsoft's unwillingness to fix this
for the life of .NET 2003 is an example of a company using their
monetary power to greatly inhibit the use of a community of
programmers, C++ programmers, when it comes to the .NET programming
world.
You're 100% wrong about that. The reason the VC++ team didn't
provide a real fix to the loader lock issue until Whidbey is twofold
(as I understand it). First, the issue was not fully understood
until very late in the Everett (7.1) beta cycle. At that point it
was too late to build a proper fix but there was time to do
something, which they did.

What was it which they did ?
Second, the problem has it's roots deep
inside the NT loader and the CLR and required changes far outside the
realm of the VC++ team to fix - it simply wasn't possible to
coordinate such a deep and far-reaching change until Whidbey.
I am sorry but I don't buy this sort of generality. Do you seriously mean to
tell me that it would take more than two months, much less two years, from a
team of programmers, to fix a problem such as this, no matter how
deep-rooted the problem is ?
It's
unfortunate. No one likes it. No one's very happy about it. But to
attribute MS's response to this bug to muscle flexing or malice is
simply ignorant.

Then I will be "ignorant" in your terms. First the term "malice" was never
used by me. I take it as a given that companies look to their own interests,
which revolve largely around making profits, over much of everything else. I
don't call this malice, but there is an element of greed over fairness which
is evident in corporate life. Secondly, to think that MS hasn't engaged in
muscle flexing in numerous areas numerous times is just ludicrous, but of
course that doesn't prove that they have done so here. Nonetheless when a
bug such as this exists, which makes it impossible for the programmers of
the leading computer language in the world to reliably write reusable code
for the leading programming environment in the world, and when this
situation exists for the lifetime of a particular release of that
environment and one is told that it is too difficult a problem to be fixed
for that lifetime, and when that lifetime exists for a period of two years
or more, and when the company producing that environment has also produced
other programming languages which compete with the previously mentioned
language, and when those other programming languages have no inherent
problems within the lifetime of that particular release of that environment
in reliably producing reusable code, I think it is natural to feel that
their may be some muscle flexing involved. If there isn't and this problem
is truly too difficult to fix for .NET 1.1, then my suggestion is that MS
needs to hire better programmers, period !

[William DePalo [MVP VC++]]

"Edward Diener" <ed******@tropicsoft.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

Do you believe it is not in MS's financial interests to promote the use of
C#, even over C++, as a programming language ?

No, I don't.

I have met some of the development team, have shot the breeze, have kicked
back a few beers, have shot a couple of racks of eight-ball. If they are not
serious about what they are doing someone should call the Oscar selection
committee. :-)

Stay tuned, the C++ development "experience" (to use the current
marketing-droid speak) will only get better.

Regards,
Will

[David Lowndes]

>Do you believe it is not in MS's financial interests to promote the use of

C#, even over C++, as a programming language ? I think you must be naive if
you believe so.

Call me naive, but think how much C/C++ code MS themselves have. I
don't believe their internal developers would relish re-writing their
code in C# no matter how fashionable it might be. I suspect that MS's
internal product teams have told the VC++ development team that the
existing mangled C++ isn't good enough - hence the big changes for
Whidbey.

From comments I've seen regarding this problem, it was pretty deep
rooted and difficult to fix.

It may have been difficult to fix but that is no reason not to do so for a
period which will extend more than two years by the time VC 2005 is
scheduled to finally be released.

I can only agree with you in general and tell you that MS's
unwillingness to release SP's with trivial bug fixes frustrates me
highly. However, I really do think this particular issue is a
different kettle of fish.

Dave
--
MVP VC++ FAQ: http://www.mvps.org/vcfaq

[Edward Diener]

William DePalo [MVP VC++] wrote:

"Edward Diener" <ed******@tropicsoft.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

Do you believe it is not in MS's financial interests to promote the
use of C#, even over C++, as a programming language ?

No, I don't.

I have met some of the development team, have shot the breeze, have
kicked back a few beers, have shot a couple of racks of eight-ball.
If they are not serious about what they are doing someone should call
the Oscar selection committee. :-)

That is not what I asked. Of course they are serious. But MS has a large
financial stake in promoting their own languages over C++, and if it just
happens that a bug in .NET 1.1, discovered prior to the release of Visual
Studio .NET 2003 does not allow C++ programmers to reliably create reusable
code when using the C++ standard library in a DLL assembly, and that bug is
declared unfixable for a period of more than 2 years, it is just an
unfortunate situation, right ?

How wonderfullt gullible and naive human beings are !

[Edward Diener]

David Lowndes wrote:

Do you believe it is not in MS's financial interests to promote the
use of C#, even over C++, as a programming language ? I think you
must be naive if you believe so.
Call me naive, but think how much C/C++ code MS themselves have. I
don't believe their internal developers would relish re-writing their
code in C# no matter how fashionable it might be. I suspect that MS's
internal product teams have told the VC++ development team that the
existing mangled C++ isn't good enough - hence the big changes for
Whidbey.

The changes in managed C++ ( not mangled C++ ) are welcome from a
programming point of view but are unwelcome by me when the new keywords lose
their __ notation, but I have already expressed this view to Mr. Sutter. It
is neither here nor there, when referring to the DLL initialization bug
which essentially destroys the ability of C++ programmers to write reliable
classes and components in ,NET 2003 unless they forgo the use of the C++
standard library and write a pure-mode DLL assembly.

From comments I've seen regarding this problem, it was pretty deep
rooted and difficult to fix.

It may have been difficult to fix but that is no reason not to do so
for a period which will extend more than two years by the time VC
2005 is scheduled to finally be released.

I can only agree with you in general and tell you that MS's
unwillingness to release SP's with trivial bug fixes frustrates me
highly. However, I really do think this particular issue is a
different kettle of fish.

I do too. I see it as going beyond the inability to release service packs
for VS .NET. After all a hotfix that fixes this problem could also have been
issued. Even that has been denied because, as I tried to state above, it is
in MS's best interests that developers write their reusable classes and
components in C# and VB .NET and not C++. How else do you give programmers a
head start using inferior languages, which you have created yourself, over a
superior one, unless you can somehow cripple that superior language and
produce a slanted playing field ? I am not claiming that MS created the bug
intentionally to begin with. I can't possibly know that. But the attitude
about not seeing it as important enough to fix in over a two year time span
makes me very suspicious over MS's motives in this regard. No one can
convince me, without a good deal of technical information very strongly
proving that it was impossible, that MS could not have fixed this bug in a
few months at the most if they thought it important enough to do so. They
obviously didn't, and I choose to believe that it served their general
interests not to do so.

[Carl Daniel [VC++ MVP]]

Edward Diener wrote:

Even that has been denied because, as I tried
to state above, it is in MS's best interests that developers write
their reusable classes and components in C# and VB .NET and not C++.
Pure baseless uninformed speculation. It just so happens that the outcomes
of your hypothesized motives and the truth are similar.
How else do you give programmers a head start using inferior
languages, which you have created yourself, over a superior one,
unless you can somehow cripple that superior language and produce a
slanted playing field ? I am not claiming that MS created the bug
intentionally to begin with. I can't possibly know that. But the
attitude about not seeing it as important enough to fix in over a two
year time span makes me very suspicious over MS's motives in this
regard. No one can convince me, without a good deal of technical
information very strongly proving that it was impossible, that MS
could not have fixed this bug in a few months at the most if they
thought it important enough to do so. They obviously didn't, and I
choose to believe that it served their general interests not to do
so.

Impossibility has nothing to do with it. It's practicality and return on
investment. Adoption of Managed C++ was slow and was likely to remain slow,
given the third-class citizen that C++ is in the .NET world with the
original Managed Extensions for C++. While the C++ team (I'm sure)
certainly would have liked to really fix the bug, it was simply out of their
hands and not important enough to Microsoft as a whole to warrant diverting
several teams to fix. Their general interests are of course, those that are
most likely to yield maximum value for their stockholders. If you don'y
like that, I'd suggest using more altruistic tools that are supported "for
the common good".

-cd

[David Lowndes]

>I choose to believe that it served their general

interests not to do so.

Oh, OK.

Dave
--
MVP VC++ FAQ: http://www.mvps.org/vcfaq

[Edward Diener]

Carl Daniel [VC++ MVP] wrote:

Edward Diener wrote:

Even that has been denied because, as I tried
to state above, it is in MS's best interests that developers write
their reusable classes and components in C# and VB .NET and not C++.
Pure baseless uninformed speculation. It just so happens that the
outcomes of your hypothesized motives and the truth are similar.

Yes, just pure coincidence. Amazing how that works.

How else do you give programmers a head start using inferior
languages, which you have created yourself, over a superior one,
unless you can somehow cripple that superior language and produce a
slanted playing field ? I am not claiming that MS created the bug
intentionally to begin with. I can't possibly know that. But the
attitude about not seeing it as important enough to fix in over a two
year time span makes me very suspicious over MS's motives in this
regard. No one can convince me, without a good deal of technical
information very strongly proving that it was impossible, that MS
could not have fixed this bug in a few months at the most if they
thought it important enough to do so. They obviously didn't, and I
choose to believe that it served their general interests not to do
so.

Impossibility has nothing to do with it. It's practicality and
return on investment. Adoption of Managed C++ was slow and was
likely to remain slow, given the third-class citizen that C++ is in
the .NET world with the original Managed Extensions for C++. While
the C++ team (I'm sure) certainly would have liked to really fix the
bug, it was simply out of their hands and not important enough to
Microsoft as a whole to warrant diverting several teams to fix.
Their general interests are of course, those that are most likely to
yield maximum value for their stockholders. If you don'y like that,
I'd suggest using more altruistic tools that are supported "for the
common good".

Ah, the "we serve are investors and we have to make money" argument. So
unique ! I just never heard that one before. How easy it is to reduce every
effort to determine what is right and wrong, even to what is technically
right and wrong, to this when all else fails.

I am so glad you spelled it out and the cat is out of the bag. If C++ is a
3rd class citizen in the .NET world I am wasting my time with .NET since
that is my language of choice, and I have come from an environment which I
quit using because C++ was merely a second class citizen ( BCB/Delphi ) . I
hope MS also announces this to companies which are using C++ and .NET for
their development, just so they are sure to know about it. But wait, they
don't really have to do this, the non-fix of the DLL initialization bug
tells them that already. So C++ is a 3rd class citizen in the .NET world but
my statement that "it is in MS's best interests that developers write their
reusable classes and components in C# and VB .NET and not C++." is "pure
baseless uninformed speculation". Truly hilarious ! Bravo ! I must be
Nostradamus then to make such good guesses. Wait my crystal ball is clearing
up and ... <g> .

[William DePalo [MVP VC++]]

"Edward Diener" <ed******@tropicsoft.com> wrote in message
news:OG**************@tk2msftngp13.phx.gbl...

That is not what I asked. Of course they are serious. But MS has a large
financial stake in promoting their own languages over C++,
It would be the height of folly, even for an organization with pockets as
deep as MS, to make the kind of investments they are making in C++ if what
they really wanted to do is foist C# on everyone. In some respects they are
like every other software house with a huge codebases in C++ that implement
products that make them lots of money. What do the languages teams tell the
product teams like Office? - "trash your old source and start again in C#".
I doubt it. Managed C++ is the way development groups within and without can
salvage their codebases AND target .Net at the same time.

Besides, it is not at all clear to me that when you compile with the /clr
switch that Managed C++ is not in a real sense MS' own language in the same
way as are the sharps.
and if it just happens that a bug in .NET 1.1, discovered prior to
the release of Visual Studio .NET 2003 does not allow C++
programmers to reliably create reusable code when using the C++
standard library in a DLL assembly, and that bug is declared unfixable
for a period of more than 2 years, it is just an
unfortunate situation, right ?
No. It is a decision taken by those in charge of allocating resources -
human and not - to the tasks at hand. My guess is that there was some
calculation as to the cost of the effort and the gain, likely measured in
terms of customers affected. Of course, no one asked me and I wasn't there
so that's just a guess.
How wonderfullt gullible and naive human beings are !

And how good some are at seeing nefarious motives at every turn. IMO, it's
project management 101. We can quarrel about the decision but it's just a
tradeoff like so many others that managers make on a daily basis.

That is not to make light of the problem. It has bitten me too. It's extra
work to be sure but it remains much less work, than say, JNI. :-)

Regards,
Will

[Bo Persson]

"Edward Diener" <ed******@tropicsoft.com> skrev i meddelandet
news:u6**************@TK2MSFTNGP10.phx.gbl...

Carl Daniel [VC++ MVP] wrote:

Edward Diener wrote:

I believe that the infamous DLL initialization bug for mixed mode C++
programming of assemblies in NET 2003 is a serious bug. The
workaround of creating a pure mode assembly is not a viable option
for C++ programmers whose use of the C++ standard library is by far
the norm in C++ programming. Microsoft's unwillingness to fix this
for the life of .NET 2003 is an example of a company using their
monetary power to greatly inhibit the use of a community of
programmers, C++ programmers, when it comes to the .NET programming
world.
You're 100% wrong about that. The reason the VC++ team didn't
provide a real fix to the loader lock issue until Whidbey is twofold
(as I understand it). First, the issue was not fully understood
until very late in the Everett (7.1) beta cycle. At that point it
was too late to build a proper fix but there was time to do
something, which they did.

What was it which they did ?

Second, the problem has it's roots deep
inside the NT loader and the CLR and required changes far outside the
realm of the VC++ team to fix - it simply wasn't possible to
coordinate such a deep and far-reaching change until Whidbey.

I am sorry but I don't buy this sort of generality. Do you seriously mean

to tell me that it would take more than two months, much less two years, from a team of programmers, to fix a problem such as this, no matter how
deep-rooted the problem is ?

I believe he tells you that if you make significant changes to the NT loader
in a .NET install, all hell will break loose.

How many months do you think is needed to verify that all other programs
will still work? How much would MS be sued for, if a .NET install would stop
some non-.NET programs from working?

Bo Persson

[Edward Diener]

Bo Persson wrote:

"Edward Diener" <ed******@tropicsoft.com> skrev i meddelandet
news:u6**************@TK2MSFTNGP10.phx.gbl...

Carl Daniel [VC++ MVP] wrote:

Edward Diener wrote:
I believe that the infamous DLL initialization bug for mixed mode
C++ programming of assemblies in NET 2003 is a serious bug. The
workaround of creating a pure mode assembly is not a viable option
for C++ programmers whose use of the C++ standard library is by far
the norm in C++ programming. Microsoft's unwillingness to fix this
for the life of .NET 2003 is an example of a company using their
monetary power to greatly inhibit the use of a community of
programmers, C++ programmers, when it comes to the .NET programming
world.

You're 100% wrong about that. The reason the VC++ team didn't
provide a real fix to the loader lock issue until Whidbey is twofold
(as I understand it). First, the issue was not fully understood
until very late in the Everett (7.1) beta cycle. At that point it
was too late to build a proper fix but there was time to do
something, which they did.
What was it which they did ?

Second, the problem has it's roots deep
inside the NT loader and the CLR and required changes far outside
the realm of the VC++ team to fix - it simply wasn't possible to
coordinate such a deep and far-reaching change until Whidbey.

I am sorry but I don't buy this sort of generality. Do you seriously
mean to tell me that it would take more than two months, much less
two years, from a team of programmers, to fix a problem such as
this, no matter how deep-rooted the problem is ?

I believe he tells you that if you make significant changes to the NT
loader in a .NET install, all hell will break loose.

Changes need not be made to the NT loader, but rather to the generated VC++
managed code which is created when a mixed mode DLL assembly occurs. This is
evidently the path that Whidbey took in solving this problem.

How many months do you think is needed to verify that all other
programs will still work? How much would MS be sued for, if a .NET
install would stop some non-.NET programs from working?

All software entails making changes and testing them out. The idea of suing
companies because some software doesn't work is just silly, and you needn't
throw that ridiculous bugaboo in the discussion.

The fix was obviously made for Whidbey and done some time ago. I choose to
believe that it could obviously have been made for VS .NET 2003 and released
so that C++ programmers could reliably write reusable classes and components
for that environment in the usual way of using the C++ standard library.
That MS didn't choose to do so means to me that they are content that C++
does not have the same ability to create reusable classes in its normal way
as does C# or VB .NET in the VS .NET 2003 world. I am pretty sure that if a
similar bug were discovered for C# or VB .NET, in which those programmers
were prevented from creating resuable classes and components for VS .NET
2003, it would have been fixed so quickly, no matter what the difficulty in
doing so might be, that one would never even have heard about it !

It is largely because this is not one of MS's favored languages for .NET
development, that this bug was left unfixed. The fact that it forces C++
programmers to write pure mode assemblies in VS .NET 2003, meaning no use of
the C++ standard library at all, is not something which bothers MS very much
but I believe it bothers C++ programmers greatly. I know it bothers me not
to be able to do normal C++ programming in VS .NET 2003. I was looking
forward to doing .NET programming and writing reusable components and now I
can not do so without severely twisting my programming style, and frankly
doing so with the extra work involved is hardly worth it. The .NET framework
does not have the facilities for doing C++ programming as does the C++
standard library and language.

[Tomas Restrepo \(MVP\)]

Edward,

Changes need not be made to the NT loader, but rather to the generated VC++ managed code which is created when a mixed mode DLL assembly occurs. This is evidently the path that Whidbey took in solving this problem.

Actually, that's by far not it. AFAIK, It required extensive changes to the
way the CLR itself worked, not merely changing the VC++ code generation. In
other words, even if the VC++ team dedicated all of its resources to fixing
it, they wouldn't have been able to without the participation of other teams
in the suite. And that's part of the problem.

--
Tomas Restrepo
to****@mvps.org

[Edward Diener]

Tomas Restrepo (MVP) wrote:

Edward,

Changes need not be made to the NT loader, but rather to the
generated VC++ managed code which is created when a mixed mode DLL
assembly occurs. This is evidently the path that Whidbey took in
solving this problem.

Actually, that's by far not it. AFAIK, It required extensive changes
to the way the CLR itself worked, not merely changing the VC++ code
generation. In other words, even if the VC++ team dedicated all of
its resources to fixing it, they wouldn't have been able to without
the participation of other teams in the suite. And that's part of the
problem.

OK, it was difficult. But do you think that if it kept C# and VB .NET
programmers from creating reusable components that the fix would not have
been done for VS .NET 2003 ? It's a rhetorical question because I think we
all know the answer.

[Tomas Restrepo \(MVP\)]

Edward,

OK, it was difficult. But do you think that if it kept C# and VB .NET
programmers from creating reusable components that the fix would not have
been done for VS .NET 2003 ? It's a rhetorical question because I think we
all know the answer.

Actually, no, we don't. At least, that's my opinion, from what I've seen of
how microsoft works.

Feel free to disagree.

--
Tomas Restrepo
to****@mvps.org

[Tomas Restrepo \(MVP\)]

Also, btw, I don't know if anyone else is interested in this topic, but I
found one of Chris Brumme's post on the topic to be quite enlightening:

http://blogs.msdn.com/cbrumme/archiv.../20/51504.aspx

--
Tomas Restrepo
to****@mvps.org

"Tomas Restrepo (MVP)" <to****@mvps.org> wrote in message
news:Ow**************@TK2MSFTNGP10.phx.gbl...

Edward,

Changes need not be made to the NT loader, but rather to the generated VC++

managed code which is created when a mixed mode DLL assembly occurs.

This is

evidently the path that Whidbey took in solving this problem.
Actually, that's by far not it. AFAIK, It required extensive changes to

the way the CLR itself worked, not merely changing the VC++ code generation. In other words, even if the VC++ team dedicated all of its resources to fixing it, they wouldn't have been able to without the participation of other teams in the suite. And that's part of the problem.

--
Tomas Restrepo
to****@mvps.org

[Edward Diener]

Tomas Restrepo (MVP) wrote:

Edward,

OK, it was difficult. But do you think that if it kept C# and VB .NET
programmers from creating reusable components that the fix would not
have been done for VS .NET 2003 ? It's a rhetorical question because
I think we all know the answer.

Actually, no, we don't. At least, that's my opinion, from what I've
seen of how microsoft works.

Feel free to disagree.

You really believe that if C# programmers were kept from creating components
in VS .NET 2003 because of some sort of bug, MS would still have released it
and said, as they have for MC++, "You won't be able to create any reusable
DLL assemblies in C#. You will have to use VB .NET to do that. It is really
regrettable but what could we do. The bug was too difficult to fix prior to
this release, and we will not be fixing it within the 2+ years until the
next release. We do plan on fixing this for our next release so that you, as
a C# programmer, can create reliable reusable .NET code about the year
2005."

[Edward Diener]

Tomas Restrepo (MVP) wrote:

Also, btw, I don't know if anyone else is interested in this topic,
but I found one of Chris Brumme's post on the topic to be quite
enlightening:

http://blogs.msdn.com/cbrumme/archiv.../20/51504.aspx
"Tomas Restrepo (MVP)" <to****@mvps.org> wrote in message
news:Ow**************@TK2MSFTNGP10.phx.gbl...

Edward,

Changes need not be made to the NT loader, but rather to the
generated VC++ managed code which is created when a mixed mode DLL
assembly occurs. This is evidently the path that Whidbey took in
solving this problem.

Actually, that's by far not it. AFAIK, It required extensive changes
to the way the CLR itself worked, not merely changing the VC++ code
generation. In other words, even if the VC++ team dedicated all of
its resources to fixing it, they wouldn't have been able to without
the participation of other teams in the suite. And that's part of
the problem.

While it certainly sounded like the VC++ team needed co-operation of others
outside them, I do believe that all concerned work for the same company,
unless MS has been magically split up while I was in a trance <g> . How hard
can that really be ?

The Blog is interesting in that it further illuminates the problem. But some
of the programmer suggestions are already known from DllMain documentation.
I don't mind MS saying that this is what one has to do or not do in order to
get around this bug, as far as not using DllMain, unmanaged exports, or
whatever, if this was a valid workaround for this bug.

My disappointment is that the documented solution, even if one follows the
recommendations given there when writing mixed mode DLL assemblies as given
in the MSDN artcile about it, still provides no assurances that one's own
code will not hang. And that, in my way of viewing programming, means that
one simply can not program mixed mode DLL assemblies in C++. The
alternative, to create pure mode DLL assemblies in C++ is onerous to the
extreme to any C++ programmer used to the C++ standard library functionality
not to even speak of Boost and other advanced C++ libraries. And to tell
people to wait until 2005 before they can reliably create .NET components in
C++ is equally horrible. It is essentially cutting out C++ programmer's
ability to make a living programming .NET and since there are more C++
programmers than any other language it is not a funny result.

Between the unwillingness of MS to create a highly compliant C++ compiler
for many years of VC5/VC6 and the destruction of the ability of C++
programmers to fully be part on an equal basis with C# and VB .NET in the
first four years or so of .NET programming, I who have been a Windows
programmer for 14 years am seriously thinking of leaving this arena. I don't
know how others feel but I am tired of C++, still IMHO the best general
programming language in the world, being treated as second or third class
citizens of the modern Windows programming OSs.