BUG: compiler allows for creation of objects without destructor compiled

[William DePalo [MVP VC++]]

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.

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

 

[Edward Diener]

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]

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.

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]]

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

 

[Edward Diener]

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.

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++]]

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]

What was it which they did ?


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]

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.

 

[Edward Diener]

Edward,


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 \(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/archive/2003/08/20/51504.aspx

 

[Edward Diener]

Edward,


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]

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/archive/2003/08/20/51504.aspx

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.