From: eldiener@tropicsoft.invalid
On 5/21/2013 10:02 AM, James K. Lowden wrote:
> On Sat, 18 May 2013 06:45:59 -0700 (PDT)
> Edward Diener wrote:
>
>>>> struct Foo { void* p; size_t x; size_t y; };
>>>
>>> Given the language as it stands today, that can't be done, it's
>>> true. It might well represent
>>>
>>> double[10][10];
>>>
>>> and there's no way to know. And that's exactly what I'm saying
>>> should change.
>>>
>>> Consider: the compiler (or the heap) knows exactly the extent of the
>>> memory pointed to by Foo::p.
>>
>> The compiler knows no such thing. It only knows that 'void* p' is a
>> pointer.
>
> Of course it does, as you well know. The information isn't recorded in
> the pointer, but any allocated memory -- no matter how allocated -- has
> size. That size is tracked by the compiler/stack/heap. It's C++'s way
> of keeping everything from using the same space.
The compiler/stack/heap are all different things. From your 'struct'
above the compiler only knows that p is a pointer to void. That pointer
can be to anywhere in memory and can point to anything. It does not have
to point to dynamic memory or be on the stack. I tend to doubt that
today the information ( length in bytes ) about that 'void * p' is kept
anywhere while the program is running by the run-time system.
>
> If you constrain yourself to thinking that the only thing the compiler
> knows about void* is sizeof(void*) and its value, yes, your Foo can't be
> serialized. If you allow the language to be changed to track the size
> of any memory assigned to any pointer, it can.
>
>> What you think the "heap" ( whatever that is ) knows you need
>> to explain.
>
> What do you want me to call it? The free store? I'm not trying to be
> obscure; I'm using standard terminology afaik. Last I checked,
> operator new was just malloc in heap's clothing, at least in GNU's
> implementation.
I know what you mean by "heap". I was only questioning the idea of what
the "heap" knows.
The 'void * p' can point to anything. To serialize it correctly the
run-time system has to know to what it points. I am not saying that is
impossible, but that the run-time system has to have a means to keep
track of it. That may be overhead for which an end-user may not want to
pay ( in size or speed ).
>
>> You cannot expect a run-time type system to do analysis of a program's
>> instructions at run-time to determine what a particular serialization
>> should be.
>
> I don't believe I every suggested any run-time analysis. All I've ever
> mentioned is the potential utility of metadata:
>
> 1. static metadata about class/union/struct members
> 2. the static type-system graph
> 3. pointer extents
> 4. last-used union member
>
> Also useful would be
>
> 5. __ENDIAN__ or similar, and automatic conversion
>
> Of these #1 is #1, because it would permit automatic handling of
> the collection-of-records that are the bread and butter of I/O.
I am not in principal against a run-time system that can track what you
want it to track but I think you may be understimating the speed/size
costs as well as the effort involved. If there were overhead I would
want an end-user to be able to opt out of it. Not everyone will agree
that the ability to automatically serialize data should be paid for in
terms of either slower code or bigger code.
--
[ 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)
|
