From: thor@math.tu-berlin.de
On 13.05.2013 08:10, James K. Lowden wrote:
>
> On Thu, 9 May 2013 16:06:39 -0700 (PDT)
> Öö Tiib wrote:
>
>>> One can enforce byte order using shifts and masks, but it is
>>> inefficient.
>
> Efficiency is always measured with respect to something. If
> byte-swapping is needed, the compiler can do it more efficiently
> than the programmer.
I kind of doubt that, but anyhow...
>> It is inefficient to keep data in memory in some file format.
>
> Hmm, what would you say about mmap(2)?
Good for raw data. Not good if I have to fiddle around with the
data. As soon as I have to touch non-native endian data more than
probably a couple of times, it is more efficient just to convert them
by hand than to rely on the compiler to arrange accesses to the
data. Actually, in many cases it does not even make sense for C++ data
types. Did I say "pointer"?
>> It is inefficient and non-portable to keep data in file in memory
>> layout of particular platform.
>
> That is exactly what many DBMSs do.
I'm not an expert in DBMSs at all, but this sounds like a bad idea to
me.
>> So something what you request feels to be doomed to be
>> fundamentally inefficient.
>
> Quite to the contrary: the OP is asking for language support for
> something currently handled by runtime libraries.
So what's so bad about runtime libraries? A lot of stuff in C++ is
handled by runtime libraries. Does it make a difference to you whether
the runtime library has a ANSI C++ logo printed on it or not?
> Jack Adrian Zappa's suggestion is obviously good. Endianism
> conversion is tedious and error-prone. The compiler knows the
> endianism of the object code it is generating. By allowing the
> programmer to denote endianism of I/O structures, the compiler
> enables endian conversion at the lowest possible cost and highest
> possible convenience.
Use a library for that.
> The objection is raised that this functionality need not be in the
> language proper, but could be in the library. OK, let there be
> std::integer defined with compile-time endianism and implicit
> conversion to built-in types, such that the above notation would
> work.
Then create a library for that if you need it.
> The objection is raised that this language feature might be used
> inappropriately, not in an I/O context. C++ is rope. How you use
> it is up to you. Compared to operator overloading, this is nothing.
C++ never stops you to shoot you in your foot, but it enables you to
check in many places with its language features. So I afraid I don't
quite get the argument.
> At the very least, the compiler should provide a built-in similar to
> __FILE__ to denote endianism, saving the library writer the need to
> depend on header files.
But you can have that nowadays right away. Autoconf has a built-in
check for that, and generates a define for right that if you need
it. Again, I don't see your point. If you need it, it's right in front
of your face to grab it.
> I fail to see any advantage to requiring the programmer to detect
> something known full well to the compiler.
And why should the compiler detect it if there are already tools that
can do that for you right away?
Greetings,
Thomas
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
