El 26/07/2013 0:26, Gabriel Dos Reis escribió:
> Ion Gaztañaga <igaztanaga_at_[hidden]> writes:
>
> [...]
>
> | > Note also that with clang and gcc, you can call __builtin_memcpy to
> | > get defined and optimized behavior even without #including <string.h>.
> | > It may be replaced with a library call if the compiler doesn't
> | > optimize it, and your certified compiler may not provide the same
> | > feature.
> |
> | Thanks for the explanation. A built-in memcpy is one of the language
> | features that I miss,
>
> The language has a builtin memcpy: it is variously called assignment
> (operator=), or copy-construction depending on the type :-)

But it's not callable by the user to copy arbitrary bytes of memory.

>
> | as it seems to be the only way to do bit-casts
> | that are essential in some embedded domains (inspecting network packets,
> | data serialization...). A conforming freestanding implementation could
> | also include memcpy.
>
> Indeed. I'm pretty sure if you are an important customer for your
> compiler supplier, you can convince him or her to include it :-)

Sadly, I'm not an important customer, and It wouldn't be portable. ¿How
can a C/C++ programmer inspect a network packet in a freestanding
implementation (e.g.when programming a DSP)? Should the programmer
accept a performance penalty and copy byte per byte? Should the
programmer write assembler code? It's a bad idea to make std::memcpy a
requirement for freestanding implementations (assuming std::memcpy call
is inlined, otherwise the performance penalty would be noticeable)? It's
a bad idea that the programmer could have access to the memcpy
implementation that the compiler is already using for trivial types?

Best,

Ion