Re: bug in visual studio .net 2003 - breakpoints and memcpy

Slava M. Usov wrote:
> "Eugene Gershnik" <gershnik@xxxxxxxxxxx> wrote in message
> news:uq4RfhxiFHA.3288@xxxxxxxxxxxxxxxxxxxxxxx
>> Slava M. Usov wrote:
>>> "Eugene Gershnik" <gershnik@xxxxxxxxxxx> wrote in message
>>> news:uBtSIrwiFHA.1460@xxxxxxxxxxxxxxxxxxxxxxx
>>>
>>> [...]
>>>
>>>>> Indeed, why would anyone want to stick with a standard?
>>>>
>>>> Indeed why in this particular case?
>>>
>>> And C++ compilers must also compile VB code, right?
>>
>> I don't see what your analogy has to do with this issue. Why in this
>> particular case sticking to the standard is good?
>
> Before we start arguing about "sticking with a standard in a
> particular case", I'd like to hear when you think "sticking with a
> standard" is good. My opinion is very simple: stick with the standard
> by default, and justify each and every case when non-standard
> behavior is necessary.

I certainly agree with that.
In this particular case there are three such justifications. First one is
'what standard'? Posix is a standard too with no less (some would say more)
importance than C++. The second problem is that the standard prohibition is
non-sensical on platforms that support the conversion. The final argument is
that the workaround required to be standard compatible produces bad code.

>>>> Well the standard is obviously out of sync with reality.
>>>
>>> Out of sync with reality is somebody else. Your perception of
>>> reality breaks down even on certain IA32 platforms, and the reality
>>> of the standard is far more diverse.
>>
>> I am not sure what you argue about. Again: GetProcAddress() can
>> return a pointer to data. dlsym() can return pointer to function.
>> Ergo, on Win32 and Posix (modern versions) the pointers are
>> interchangeable.
>
> I was arguing with this:
>
> [begin quote]
>
> "Eugene Gershnik" <gershnik@xxxxxxxxxxx> wrote in message
> news:uDUo0HviFHA.1948@xxxxxxxxxxxxxxxxxxxxxxx
>> Alexander Grigoriev wrote:
>>> According to ANSI C and standard C++, there is no standard
>>> conversion from a function pointer to void*, and vice versa. It's
>>> just not listed among the possible conversions.
>>
>> Sounds like "undefined by omission" to me.
>
> [end quote]
>
> That remark of yours was not about win32 or POSIX; it was about
> Standard C++. Now you are somehow arguing about win32 and POSIX only.

I mentioned Win32 and Posix to show that the reality contains
implementations (indeed, extremely widely used implementations) that allow
or even require the conversion. The standard all-over prohibition thus is
out of sync with reality just as I claimed. Your assumtion about what
constitutes my perception of reality and that I am flexible with arguments
doesn't follow from anything I have written.

> If you're so flexible with your arguments, you might as well say
> "pointers-to-code and pointers-to-data are not interchangeable in
> contemporary Standard C++; any code that uses that relies on a
> non-standard language extension".

Not exactly. Any code that uses that relies on some platform guarantees that
are usually accompanied by a language extension.

>>>> Googling on this issue reveals that even the standard comitteee
>>>> members say so.
>>>
>>> Looking at the standard is a much more straightforward way of
>>> listening to the committee members.
>>
>> I see. So the standard was given to us on mount Sinai as the world
>> of god rather than being written by these same committee members.
>
> If your confession accepts standards only from that authority, it
> conflicts with your profession [I presume writing C++ code is part of
> your profession].

I was being sarcastic. Apparently you haven't noticed.

> If we stay away from religious issues, then I'd like to draw your
> attention to the fact that the standard committee members _do_not_
> "say so". What they do say on this issue is that an entirely new
> concept of "conditionally-supported behavior" is required to support
> this conversion. For more details, see
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html , defect
> no. 195;
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1564.pdf .

This is just one possible compromise. I am not saying I don't like it but,
still, there are other viepoints (some reflected in these links) and the
committee compromises are often not the best decisions. That's why I like to
listen to actual people in context of an actual discussion. A stupid
standard requirement is stupid no matter how standard it is. The current
prohibition is one such case.

>> Please show me how
>>
>> (void*)(int)pf;
>>
>> leads to better code than
>>
>> (void*)pf;
>
> If the latter is supported by a language extension, then it will
> probably lead to exactly the same code as the former, if 'int' is big
> enough. But it will be via an extension, not even undefined behavior.
> This is my whole point.

My point is that first variant is worse code plain and simple. It is not
because it generates different machine code. They both should produce the
same result as you mentioned. The problem with the first variant is that it
doesn't add anything to portability. Either you can convert function
pointers to data ones on a platform or you cannot. If you cannot the first
form still doesn't work and you need to restructure your code anyway. If you
can your compiler will most likely provide the 'extension'. To make the
first form even marginally portable you will need to introduce and maintain
some typedef like DWORD_FUNC_PTR which means more work and more chances to
screw up for a maintainance programmer. The second form follows the simple
maxim "say what you mean and mean what you say". The fact that the current
C++ standard disallows it is a defect in the standard not code.


--
Eugene
http://www.gershnik.com


.

Relevant Pages

  • Re: Judge Jones speaks
    ... the Bible corresponds with the rare act in reality. ... sensible persons conclude they cannot perform His standard WHICH leaves ... God allows, faith alone, apart from the works of the law, to be ...
    (talk.origins)
  • Re: International Pricing Policy
    ... might say "What that person is willing to pay is too much". ... is there any standard against which the person's decision could be ... reference to reality" - i.e. arbitrarily. ...
    (borland.public.delphi.non-technical)
  • Re: OT: Mozilla/Firefox (was:Re: Windoze ends year with a major cert ...)
    ... Not saying it's right or wise, just reality. ... Enough squeeky wheels and some ... world won't change it until MS is supplanted as the industry standard. ... I didn't vote them into that position and I don't have the power to vote ...
    (comp.os.vms)
  • Re: Kramer Explains Why He Said What He Said...
    ... As I said, it might be a double standard, but it's reality. ... racial history underlying the things he was saying -- he did this on two ... Their entire act is based on kill whitey and fuck his woman. ...
    (alt.sports.football.pro.ne-patriots)
  • Re: help me learn C
    ... many C implementations have not. ... It depends if you want to discuss reality or a standard that is not ... of recent non-native English speakers who now have access to Usenet and post ...
    (comp.lang.c)