Re: Destructor: not gauranteed to be called?

Peter Oliphant wrote:
>>> 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 :
>
> Correct. Since ToString is not part of the C++ standard it doesn't
> make much sense to justify broken behavior on its part as being
> required because it IS standard behavior! Now, check out this link:

Well, ToString is not defined b the C++ standard, but it is defines by 
another : The .NET Standard (ECMA 335).

> http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=788dfe28-0ac8-4c5f-96c2-bb5065fd7c2b
>
> Recapping, the ToString() function applied to a Char[] results in
> EXACTLY the following string regardless of the contents of the Char[]
> : "System.Char[]". MS claims that they will not 'fix' ToString to
> solve this, but instead might create a new function to accomplished
> more natural and desired results. They say that changing the current
> behavior would be 'breaking'. That could only be true if enough
> people out there wrote code that RELIES on this behavior. Who would
> rely on this behavior is what I was saying in the above?

I totally agree with the MS response to this query :

- the behaviour you observe is as required by the .NET standard (se my 
previous post).

- it *may* break existing code, through unlikely.

- The fact yhat you require or expect a Char[] to act as a string is a sign 
that you are still in a "C" way of though. In OOP, a string is an object in 
itself, and an char array is just an array, it has nothing to do with 
strings. The fact that in C, a string is a char[] is a kludge that has no 
reason to be in OOP.

> It sounds
> like just an excuse NOT to change it since they don't think of it as
> important enough.
I actually think it's a good thing *not* to do this change, since it force 
people to adapt to the new, better, OOP paradigm, where a string is 
represented by System::String and nothing else. You should forget your "C 
guru" reflexes in .NET ;-)

> Personally, I think of the ToString as a means to convert a variable
> to a string equivalent of the *natural symbolic representation* of
> the variable it's given.
Yes, but in OOP, the natural symbolic representation of an array of char is 
*not* a string, since an array of chars is *not* a string!

>I don't think of the natural symbolic
> representation of a char to be its ascii value.
There I agree with you : the choice for simple Char is strange.

Arnaud
MVP - VC


.

Relevant Pages

  • Re: Destructor: not gauranteed to be called?
    ... returns precisely this string and only this string every time: ... Then you believe that ToString applied to an Intshould return this string ... ToString from being applied to an array, ... I expected in the case of giving it a 'char'. ...
    (microsoft.public.dotnet.languages.vc)
  • Re: Destructor: not gauranteed to be called?
    ... - The fact yhat you require or expect a Char[] to act as a string is a sign ... itself, and an char array is just an array, it has nothing to do with ... the natural and expected result of applying ToString to it would return a ...
    (microsoft.public.dotnet.languages.vc)
  • Re: how to convert char* to File *
    ... char* for the content,and I think saving char* to a file and opening it ... So you have a string, and you want to arrange for that string to be ... from a disk file will be too slow. ... There's nothing in the C standard that says a FILE* has to be ...
    (comp.lang.c)
  • Re: UDB and pointer increments and decrements
    ... if s points to the start of a string and e becomes less than s then e is ... not really pointing to defined char. ... One of the reasons the Standard ... worth pointing out the sacrifice and suggesting safer alternatives. ...
    (comp.lang.c)
  • Re: buffer overflow
    ... int main(int argc, char *argv) ... However the standard does require a proper string to copy into ...
    (comp.lang.c)
Quantcast