Re: Destructor: not gauranteed to be called?

• From: "Arnaud Debaene" <adebaene@xxxxxxxxxxxxxxxx>
• Date: Tue, 31 Jan 2006 23:41:50 +0100

Peter Oliphant wrote:
>> Possible. Another explanation is perhaps you didn't master the
>> differences between finalizers and destructors, and you expected
>> something of the system without taking care of checking in the
>> documentation wether your expectations were justified.
>
> I agree, but there's a problem. You see, how do you know when a
> change has been made, or what the new features are, or if something
> exists that solves your problem in VS C++.NET? Please don't tell me
> this info is easily obtained.

I don't say so. I say that, just as you have learned native C++, you should 
learn C++/CLI, most probably in a book or a course if you find MSDN to be 
too "dictionnarish" (I agree with that).

> Another problem is that there is no convention as to what is made
> into a 'method' and what is made into a 'property'. Often, changing a
> property is like a method (i.e., to change visibility change the
> Visible property, there is no SetVisible() and SetInvisible()
> functions, which would of course be another logical way to do this),
> and many methods are the equivalent of properties (they return a
> state but have no affect).
Well, for me, the difference between function and property is just syntaxic 
sugar, they are really the same and I don't see this as a problem.

> And, IMHO, the MSDN2 doco is
> written by people so well versed in the subject they seem to forget
> they actually need to explain it

MSDN is a reference, just as a dictionnary or an encyclopedia. It is not 
meant to be a teaching tool (through, IMHO, it do quite a good job as a 
teaching tool too, thanks to the many articles beside the mere 
classes/functions/properties reference pages, but i agree it can be quite 
difficult to find what you are looking for when you are not used to it).
Anyway, have you ever tried Linux man-pages or Oracle 800 pages PDF 
reference books before complaining about MSDN ;-)

<snip samples>
> And THIS is what I'M suppose to get my knowledge of the VS C++.NET
> from? <shiver>

Have you looked at MS Press books?

Anyway, MSDN2 was supposed to be a Beta version of the documentation for the 
Beta version of Visual 2005 (that's the way I understood it at least).
Now that Visual 2005 is on the shelves, it doesn't seems that Visual 2005 
specific stuff has been merged in the "main" MSDN site. I am not sure why 
and if the MSDN2 is there to stay as the definitive doc (that would be a bad 
idea IMHO to have 2 different "release" MSDN sites), or if we are in a 
transitory state.

> Let's take the point at hand. How was I suppose to find out about
> these new rules regarding destructors and finalizers?
They are no new : It was the same story in Managed C++, through the syntax 
was different. The really new thing is the stack semantic.

> Why shouldn't I
> assume that an UPGRADE would maintain ALL previous functionality and
> possibly add onto it.
> Changes, IMHO, violate the concept of UPGRADE.
> They should call VS C++.NET someting like C+++ (3 +'s) to make sure
> we are clear we need to learn all its details, since if you assume it
> will behave like standard C++ you might find yourself chasing bugs
> that are actually features!
Well, you know, they do call it C++/CLI for a purpose! Anyway, I agree that 
MS nomenclature is (as most often) very confusing.

>
> The reason is not lack of desire or ability, is is lack of knowing
> such info exists or that changes were made in the first place. One
> only 'discovers' these when code stops working when you do what use
> to work and now doesn't.
Your only error was to expect that C++/CLI will react exactly as native C++. 
There I must say that the MS commercial woodoo about "It Just Work", "simply 
compile your old code and see it work like it used to" and the like is 
misleading.

> The real annoyance though comes when you point out a bug in the
> language and the response it that it can't be changed because it
> would 'violate the C++ standard'.
Huuu??? What are you speaking about here?

> How is that even close to a
> justification when VS C++.NET violates the standard whenever it sees
> fit to in most areas. For example, did you know that if you apply the
> ToString() method to a Char[] it returns with the EXACT SAME STRING
> every time, and it's something like "Char[]". I reported this, and
> they said this couldn't bechanged since it would violate the standard
> and might break someone's existing code. HUH? Who in HELL depends on
> this behavior?

I don't understand you here... ToString is not part of the C++ standard! It 
is the .NET standard (ECMA 335) that define the ToString method, and it 
seems consistent to me, as this specification says that :

<quote ECMA 335> "default : System.Object.ToString is equivalent to calling 
System.Object.GetType to obtain the System.Type object for the current 
instance and then returning the result of calling the System.Object.ToString 
implementation for that type.
Note : The value returned includes the full name of the type.
</quote>

and, on the other hand, ToString is not redefined for System.Array. 
Therefore, according to usual override rules, the return value is as 
expected.

Note : My quotes from the ECMA 335 standard are from the XML file definining 
the BCL and available at 
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-335-xml.zip. 
See partition 4 of 
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-335.pdf 
for a description of this XML file

Arnaud
MVP - VC


.

• Follow-Ups:
  • Re: Destructor: not gauranteed to be called?
    • From: Peter Oliphant

• Prev by Date: Re: Visual C++ bug report
• Next by Date: Re: ostream constructor error
• Previous by thread: Re: Visual C++ bug report
• Next by thread: Re: Destructor: not gauranteed to be called?
• Index(es):
  • Date
  • Thread

• Windows
• Science
• Usenet

• Archive
• About
• Privacy
• Search
• Imprint