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

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?

>> 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 am not sure
where 'my perception of reality' breaks on IA32 so perhaps you could educate
me.
As for the reality of the standard perhaps you program on the 'standard
machine' using 'standard compiler'. I don't and I doubt anyone else does.

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

>
> [...]
>
>> I still stand by what I wrote earlier. Either cast once and the cast
>> will work or don't cast at all. The double cast doesn't buy anything
>> here.
>
> Converting between pointers and integers is useful and can be
> generally implemented;

No. If a pointer is say 128 bit and the largest integer only 64, there is no
way you can implement such conversion.

Again I am not sure what exactly do you argue about. Please show me how

(void*)(int)pf;

leads to better code than

(void*)pf;

Note that an answer 'because it is standard' doesn't really explain
anything. How the fact that it is standard makes this particular code (not
code in general) better?


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


.

Relevant Pages

  • Re: struct initilization via memset
    ... >>will all initialize the pointer to a null pointer. ... By the time of the first ANSI C standard, C had been around for well ... over 10 years and C compilers were developed for quite a few different ... expression with a value of 0 cast to pointer to void. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: NULL in variadic function calls
    ... >> Standard. ... >> It is true that on most modern compilers and architectures, ... value is a null pointer: ... valid pointer value, representing an actual, valid memory ...
    (comp.unix.programmer)
  • Re: Another String reversal question
    ... With some hardware, the higher 16 bits would be unchanged. ... (For some compilers, only the low 16 bits took part in pointer ... but the C++ standard requires that the compiler make it ...
    (comp.lang.cpp)
  • Re: struct initilization via memset
    ... > By the time of the first ANSI C standard, C had been around for well ... > compilers generated code that was most efficient for their particular ... and the definition of the macro NULL. ... > expression with a value of 0 cast to pointer to void. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: class variables: scoping
    ... >> standard, though there are variations you can try. ... > with other compilers as well. ... But you can't convert a pointer to member function into a void*, ... > that problems may arise in multithreaded applications. ...
    (comp.lang.cpp)