 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Daveed Vandevoorde
Guest
|
 Posted: Fri Jul 11, 2003 5:52 pm Post subject: Re: is C++ implementation allowed to store object in non-con |
 |
|
[email]jdennett (AT) acm (DOT) org[/email] (James Dennett) wrote:
| Quote: | "Bo-Staffan Lankinen" <bo-staffan.lankinen (AT) gbg (DOT) bonet.se> wrote...
What does it matter whether the bytes are contiguous or spread around?
If you want to copy the object using memcpy or memmove you may only
do that with POD. Any other operation does not require the object to
be in contiguous memory, does it?
I can matter when constructing with placement new.
I am not sure what you mean. How would that matter?
struct T { ... };
unsigned char buffer[sizeof(T)];
new (static_cast<void*>(p)) T;
This must construct a T object in the buffer. It has
to assume that the buffer is contiguous, and use it.
|
Well, it doesn't actually have to work in general because
T might have stronger alignment requirements than
unsigned char.
Even so, the buffer being contiguous does not mean that
the whole object must be contiguous; only the so-called
"object representation" (standardese) must be contiguous.
| Quote: | Every
'new' operator works with memory address returned to it by
the allocation function (3.7.3.1), placement new is not in
any way different, it just passes extra arguments to that
allocation function.
The allocation function in this case returns the address
it's given, and then an object is constructed at that
address.
|
I believe it is possible to design a standard-conforming
implementation that involves a split object even with that
constraint.
| Quote: | It's the job of the allocation function
to recognise that the memory is split into pieces and not to
use it, I suppose.
No, it's the job of the allocation function to return a
pointer to memory suitable for construction of an object.
The standard overload of ::operator new used by the
regular form of placement new simply returns the "extra"
argument it is given.
|
Consider the following implementation strategy. Base class
subobjects are allocated by constructors using a hidden
built-in allocator, and the main ("derivation") chunk of the
object just points to the base classes. sizeof(D) returns the
number of bytes occupied by the main chunk of D only
(including the pointers to base subobjects, but not including
the base subobjects themselves).
I believe that could be a correct C++ object model where the
value of an object is not contained within a contiguous chunk
of bytes.
Daveed
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
 |
Ron Natalie
Guest
|
| Posted: Fri Jul 11, 2003 5:52 pm Post subject: Re: is C++ implementation allowed to store object in non-con |
|
|
""Bo Persson"" <bop2 (AT) telia (DOT) com> wrote
| Quote: | No, the compiler can claim that unsigned char has the wrong alignment
for a T and refuse.
|
Actually, it can even not refuse but blow up at runtime.
| Quote: | If you use malloc(sizeof(T)) the returned block, if any, will be
suitable.
|
new char[sizeof(T)] is requrired to behave the same way
| Quote: | However malloc is specifically allowed to return a larger
block than requested, to make it suitably aligned.
|
You mean it might allocate more memory...
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Victor Bazarov
Guest
|
| Posted: Sat Jul 12, 2003 12:14 am Post subject: Re: is C++ implementation allowed to store object in non-con |
|
|
"Mirek Fidler" <cxl (AT) volny (DOT) cz> wrote...
| Quote: | function return one chunk _always_. Again, I haven't seen any
explanation yet as to why _allowing_ to keep objects spread in
memory interferes with anything else.
Perhaps I start to understand you. What you are claiming is that C++
standard allows different layout for automatic/static objects and for
objects on heap ? 
|
Yes. For some reason some folks understand it in reverse.
Nothing says that when allocating an object using 'new' the
operation has to support construction of the object in non-
contiguous memory. Allocation function returns a memory
chunk, all contiguous, an everything is fine. However, if
I declare a local object or a global object, there is nothing
in the language that requires it to be in one piece. That's
how I read the Standard. That's how the language seems to
work. It doesn't contradict itself in that regard, I think.
It's not illogical to allow objects to be broken up. Only
POD objects have to have contiguous storage and that's the
requirement made explicitly. The fact that allocators need
contiguous storage and the fact that allocation functions
return contiguous storage for new objects to be constructed
in, doesn't change a thing...
Now, if I do
someNonPODClass object; // can it be broken up?
someNonPODClass *other = new (&object) someNonPODClass;
(which seems to be the argument against allowing breaking
even non-POD objects up), I have a slight problem. First,
the Standard does say that an object's lifetime ends as soon
as its _storage_is_reused_. However, in another paragraph
the Standard says that in order an object's lifetime ends
with execution of the destructor. To me it seems that due
to the 'execution of the destructor' requirement the code
above is ill-formed. Another argument towards allowing the
object in the code above to be broken up is that the used
"placement new" here does not necessarily create the object
directly in the storage of 'object'. It passes it onto the
allocation function, which could after detecting that the
storage is non-contiguous, return another, contiguous, piece
and ignore the non-contiguous one. If I were implementing
a compiler, that's what I'd do. OTOH, if it's possible to
create 'object' in a broken-up storage in the first place,
why can't we create another one, the "dynamic" object in
the same broken-up place? The layout will be the same, no?
That's just MHO, of course. I can be mistaken. It would
be nice to hear from others on the subject.
Victor
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Francis Glassborow
Guest
|
| Posted: Sat Jul 12, 2003 7:44 pm Post subject: Re: is C++ implementation allowed to store object in non-con |
|
|
In article <vgtp84dh21hd21 (AT) corp (DOT) supernews.com>, Victor Bazarov
<v.Abazarov (AT) attAbi (DOT) com> writes
| Quote: | Yes. For some reason some folks understand it in reverse.
Nothing says that when allocating an object using 'new' the
operation has to support construction of the object in non-
contiguous memory. Allocation function returns a memory
chunk, all contiguous, an everything is fine. However, if
I declare a local object or a global object, there is nothing
in the language that requires it to be in one piece. That's
how I read the Standard. That's how the language seems to
work. It doesn't contradict itself in that regard, I think.
|
The new expression calls an allocator function operator new to get the
memory which the ctor uses to construct the object. One of these
allocator functions is the simple placement version. I do not understand
how the new expression is supposed to do other than assume that the
placement new returns a single contiguous chunk.
Now it is also allowed by the standard to explicitly call the dtor on an
object and then use the memory which the object had been occupying to
build another object of exactly the same type. There is consciously no
constraints on the origin of the object that was destroyed, the only
constraint is that if it was a stack object its memory must once again
contain an object of exactly the same type before it is automatically
destroyed when the name goes out of scope.
I am sorry if this is confused. But it is quite clear that even if some
perverted reading of the standard allows otherwise the only logical
mechanism is for all complete objects with the same dynamic type to have
the same layout. I have to say complete type because virtual bases and
MI introduce the necessity that some subobjects will be disjoint.
However I do not believe that it is allowed to try to destroy a base
subobject other than as part of the destruction of the complete object.
--
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Francis Glassborow
Guest
|
| Posted: Sun Jul 13, 2003 7:01 pm Post subject: Re: is C++ implementation allowed to store object in non-con |
|
|
In article <bes3m3$8dq40$1 (AT) ID-47792 (DOT) news.uni-berlin.de>, Bo-Staffan
Lankinen <bo-staffan.lankinen (AT) gbg (DOT) bonet.se> writes
| Quote: | AFAICT, the C++ standard doesn't guarantee that the bytes in the
object-representation is a contiguous memory-chunk. As I interpret the
standard, when constructing an object in a new-expression, an implementation
is allowed to split up the bytes in 2 or more contiguous chunks, which are
allocated by separate invokations to an allocation function, 1.9/17 seems to
support that claim. If an object is split up in such a way, an object
created with the corresponding placement new-expression must also have that
object-representation.
|
Exactly how do you think that 1.9/17 supports this viewpoint. Of course
evaluating a new expression might result in more than one allocator
being called, the first one might fail, or the object's ctor might
include a new expression.
If a complete object could exist in non-contiguous then id would simply
be impossible for users to write placement new functions. If you think
otherwise it is up to you to demonstrate how this can be done. C++
allows the following:
void * raw = operator new(sizeof mytype);
mytype object = new(raw) mytype;
How do you propose that we implement that?
--
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Mirek Fidler
Guest
|
| Posted: Sun Jul 13, 2003 8:23 pm Post subject: Re: is C++ implementation allowed to store object in non-con |
|
|
| Quote: | Exactly how do you think that 1.9/17 supports this viewpoint. Of
course
evaluating a new expression might result in more than one allocator
being called, the first one might fail, or the object's ctor might
include a new expression.
If a complete object could exist in non-contiguous then id would
simply
be impossible for users to write placement new functions. If you think
otherwise it is up to you to demonstrate how this can be done. C++
allows the following:
void * raw = operator new(sizeof mytype);
mytype object = new(raw) mytype;
How do you propose that we implement that?
|
Well, although I agree with you that multichunk complete objects are
not a good idea, I could imagine that implementation of
struct Alfa : Beta { int dummy; }
could be done as
struct Alfa {
Beta *base; // hidden member inserted by compiler
int dummy;
Alfa() {
base = compiler_generated_alloc_of_Beta(); }
~Alfa() {
compiler_generated_free_of_Beta(base);
}
};
Now, sizeof(Alfa) would be sizeof(Beta) + sizeof(int) (+
alignment...) and placement new would work. OTOH, it is still possible
that this is forbidden by some standard paragraph we have not considered
yet... (in fact, I hope it is :)
Of course, I can hardly imagine that some C++ implementation would
be as crazy....
Mirek
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Bo-Staffan Lankinen
Guest
|
| Posted: Mon Jul 14, 2003 1:59 am Post subject: Re: is C++ implementation allowed to store object in non-con |
|
|
| Quote: | If a complete object could exist in non-contiguous then id would simply
be impossible for users to write placement new functions. If you think
otherwise it is up to you to demonstrate how this can be done. C++
allows the following:
void * raw = operator new(sizeof mytype);
mytype object = new(raw) mytype;
|
Yes, syntactically it's correct, but as the standard currently is written, I
don't think it's guaranteed to be semantically correct.
| Quote: | How do you propose that we implement that?
|
I don't propose a change to the current placement-new idiom. I'd like the
standard to guarantee the bytes in the object-representation to be one
contiguous memory-chunk, that would make me sleep much better at night.
Bo-Staffan
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Daveed Vandevoorde
Guest
|
| Posted: Mon Jul 14, 2003 5:34 am Post subject: Re: is C++ implementation allowed to store object in non-con |
|
|
[email]francis (AT) robinton (DOT) demon.co.uk[/email] (Francis Glassborow) wrote:
[...]
| Quote: | void * raw = operator new(sizeof mytype);
mytype object = new(raw) mytype;
How do you propose that we implement that?
|
Say mytype contains a simple base occupying 32 bytes, and that it
adds a field of 8 bytes to that. A split object model could deem
the "object representation" to consist of the latter 8 bytes plus a
pointer to the 32 bytes (say, also 8 bytes). sizeof(mytype) is therefore
16 bytes, but note how the "whole object" contains 40 bytes of
information.
With this scenario (change the numbers however you like), the
first initialization allocates 16 bytes. For the second initialization,
I assume you meant (added asterisk):
mytype *object = new(raw) mytype;
This invokes the mytype constructor which can implictly allocate
a 40 byte chunk, set the aforementioned pointer to it, and call
the base constructor with that pointer.
Perhaps not efficient, but certainly standard conforming (and
perhaps even useful is some specialized environments).
Daveed
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Ron Natalie
Guest
|
| Posted: Mon Jul 14, 2003 5:25 pm Post subject: Re: is C++ implementation allowed to store object in non-con |
|
|
""Ron Natalie"" <ron (AT) sensor (DOT) com> wrote
| Quote: |
""Bo Persson"" <bop2 (AT) telia (DOT) com> wrote
No, the compiler can claim that unsigned char has the wrong alignment
for a T and refuse.
Actually, it can even not refuse but blow up at runtime.
That doesn't read the way I intended it. |
It should say "It can accept the program but blow up at runtime."
Alignment problems are not required to be diagnosed.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Andy Sawyer
Guest
|
| Posted: Mon Jul 14, 2003 8:02 pm Post subject: Re: is C++ implementation allowed to store object in non-con |
|
|
In article <besurv$8jf09$1 (AT) ID-47792 (DOT) news.uni-berlin.de>,
on Mon, 14 Jul 2003 01:59:01 +0000 (UTC),
[email]bo-staffan.lankinen (AT) gbg (DOT) bonet.se[/email] ("Bo-Staffan Lankinen") wrote:
| Quote: | void * raw = operator new(sizeof mytype);
mytype object = new(raw) mytype;
Yes, syntactically it's correct
|
Only if mytype has a constructor that looks something like:
mytype( mytype * ); // or const mytype *
I suspect the second line should actually read:
mytype* object = new(raw) mytype;
Regards,
Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
how fast light travels it finds the darkness has always got there first,
and is waiting for it." -- Terry Pratchett, Reaper Man
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Bo-Staffan Lankinen
Guest
|
| Posted: Mon Jul 14, 2003 9:57 pm Post subject: Re: is C++ implementation allowed to store object in non-con |
|
|
| Quote: | Even so, the buffer being contiguous does not mean that
the whole object must be contiguous; only the so-called
"object representation" (standardese) must be contiguous.
|
Where do you find that requirement in the standard?
Bo-Staffan
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Markus Mauhart
Guest
|
| Posted: Mon Jul 14, 2003 9:58 pm Post subject: Re: is C++ implementation allowed to store object in non-con |
|
|
"Daveed Vandevoorde" <google (AT) vandevoorde (DOT) com> wrote ...
| Quote: | argument it is given.
Consider the following implementation strategy. Base class
subobjects are allocated by constructors using a hidden
built-in allocator, and the main ("derivation") chunk of the
object just points to the base classes. sizeof(D) returns the
number of bytes occupied by the main chunk of D only
(including the pointers to base subobjects, but not including
the base subobjects themselves).
I believe that could be a correct C++ object model where the
value of an object is not contained within a contiguous chunk
of bytes.
|
I dont think so.
With any outstanding "::operator new" allocation IMHO I am
allowed to do the following ...
BYTE* p0 = (BYTE*) ::operator new(1024*1024);
.....days
.....and
.....weeks
.....later
int count = 1024*1024 / sizeof(ANY_X) ;//"ANY_X::ANY_X(..) throw()"
for (int i=0 ;i!=count ;++i)
::new ( (void*) (p0 + i*sizeof(ANY_X)) ) ANY_X(..);
//.... use the array ... I KNOW I dont need destructor ...
for (int i=0 ;i!=count ;++i)
::new ( (void*) (p0 + i*sizeof(ANY_X))) ANY_X(..);
//.... use the array ... I KNOW I dont need destructor ...
for (int i=0 ;i!=count ;++i)
::new ( (void*) (p0 + i*sizeof(ANY_X))) ANY_X(..);
//.... use the array ... I KNOW I dont need destructor ...
for (int i=0 ;i!=count ;++i)
::new ( (void*) (p0 + i*sizeof(ANY_X))) ANY_X(..);
..... and note, the 'hidden' allocation to allcoate the real memory for
the subobjects may not fail if your hypothetical c++ implementation
was conforming ... ANY_X-ctor is throw(), and AFAIK c++ implementations
generally may not create 'failures' at their will.
That iterated construction w/o destruction was surely a bit extreme, but
my point is that ::operator new(size_t) doesnt know in advance how much
memory it has to reserve for possibly later necessary hidden subobject
allocation. ::operator new() reasonably may be used to allocates MBs
of memory necessary for a STL-container-tuning small block allocator.
For example take Mr. Stroustrups decades old example for using and
implementing conforming class-specific allocation by suballocating
fixed size pieces out of greater blocks. This technique would be
non-portable if the above method (of using "::placement new" inside
the super-aligned byte-arrays we get as result of ::operator new)
was wrong ... and AFAIK such suballocation technique was one of the
very 1st things that Mr. Stroustrup used.
If my scenarios of ::operator new(size_t) usage are conforming, then
your hypothetical c++ implementation AFAICS would have to set aside
an incredibly (even infinite ?) large amount of extra memory to stay
conforming ... had such memory-destroying technology then anything
todo with C or C++ ?
If I was a member of the c++-committee, then I wouldnt spend a minute
of my time thinking about whether any change for c++0x might break such
"storage/=7" c++ implementation. Instead I would assume that anyone
interested enough in such a strange c++-simulator should simulate
continuous objects too; why not, when even the complete 25 year old
Intel "x86 machine" today is simulated by the engineers of Intel, AMD
and Transmeta, resulting in performance good enough for me and probably
also for you.
You are a c++ implementor: would you expect simulating continuous
objects to be an issue for you, when comparing it with 'simulating'
full featured templates, export and the rest of c++ ?
Regards,
Markus.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Markus Mauhart
Guest
|
| Posted: Tue Jul 15, 2003 3:35 pm Post subject: Re: is C++ implementation allowed to store object in non-con |
|
|
""Victor Bazarov"" <v.Abazarov (AT) attAbi (DOT) com> wrote ...
| Quote: |
"Markus Mauhart" <markus.mauhart (AT) nospamm (DOT) chello.at> wrote...
I dont think so.
With any outstanding "::operator new" allocation IMHO I am
allowed to do the following ...
BYTE* p0 = (BYTE*) ::operator new(1024*1024);
int count = 1024*1024 / sizeof(ANY_X) ;//"ANY_X::ANY_X(..) throw()"
for (int i=0 ;i!=count ;++i)
::new ( (void*) (p0 + i*sizeof(ANY_X)) ) ANY_X(..);
//.... use the array ... I KNOW I dont need destructor ...
Here is my question: how do you KNOW? The Standard says that
you may reuse the storage if the lifetime of the object ended.
The lifetime ends with a call to the destructor. How is that
you don't need one?
|
"I KNOW" means "I dont need want dtor code to be executed" and
"I know that my program will never refer to the previous objects".
But it doesnt mean "I know c++ allows this".
The case of reusing the memory w/o calling dtors is and was not
my main argument against the outlined c++ implementation, this
special case happend during writing, and I was aware that this
might introduce undefined behaviour. But your argument did not
say explicitely nor convince me that calling placement new twice
on the same location introduces UB ... so if you or sombody else
are sure that this is the case, then please provide more concrete
pointers into the standard.
| Quote: | [...]
If my scenarios of ::operator new(size_t) usage are conforming,
That would be my doubt too.
|
Please for now ignore the above *special case* of forgetting to call dtors.
| Quote: | BYTE* p0 = (BYTE*) ::operator new(1024*1024);
int count = 1024*1024 / sizeof(ANY_X) ;//"ANY_X::ANY_X(..) throw()"
for (int i=0 ;i!=count ;++i)
::new ( (void*) (p0 + i*sizeof(ANY_X)) ) ANY_X(..);
|
Is this allowed ?
Is it also allowed for any result of malloc() ?
Both happens in stdlib++'s std::allocator, boost's pool uses it too.
Do you agree that then, with Daveed's sample object model, most calls
to ::operator new(size_t) or malloc() would have to set aside a big,
maybe even infinite amount of memory ?
Regards,
Markus.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Daveed Vandevoorde
Guest
|
| Posted: Tue Jul 15, 2003 11:49 pm Post subject: Re: is C++ implementation allowed to store object in non-con |
|
|
[email]bo-staffan.lankinen (AT) gbg (DOT) bonet.se[/email] ("Bo-Staffan Lankinen") wrote in message news:<bes3oe$86ph7$1 (AT) ID-47792 (DOT) news.uni-berlin.de>...
| Quote: | Even so, the buffer being contiguous does not mean that
the whole object must be contiguous; only the so-called
"object representation" (standardese) must be contiguous.
Where do you find that requirement in the standard?
|
I believe it's implicit in the requirements for sizeof (5.3.3/1,2)
that sizeof (T[N]) == N*sizeof(T). This doesn't make continuity
of the object representation a requirement, but I cannot think
of a discontinous model for that part (while I can for the "whole
object").
Daveed
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Markus Mauhart
Guest
|
| Posted: Wed Jul 16, 2003 4:47 pm Post subject: Re: is C++ implementation allowed to store object in non-con |
|
|
""Victor Bazarov"" <v.Abazarov (AT) attAbi (DOT) com> wrote ...
| Quote: | "Markus Mauhart" <markus.mauhart (AT) nospamm (DOT) chello.at> wrote...
""Victor Bazarov"" <v.Abazarov (AT) attAbi (DOT) com> wrote ...
Here is my question: how do you KNOW? The Standard says that
you may reuse the storage if the lifetime of the object ended.
The lifetime ends with a call to the destructor. How is that
you don't need one?
[...]
The case of reusing the memory w/o calling dtors is and was not
my main argument against the outlined c++ implementation, this
special case happend during writing, and I was aware that this
might introduce undefined behaviour. But your argument did not
say explicitely nor convince me that calling placement new twice
on the same location introduces UB ... so if you or sombody else
are sure that this is the case, then please provide more concrete
pointers into the standard.
Based on 3.8: the lifetime ends when a non-trivial destructor is
called or when the storage is released or reused.
|
Thanks for the more details here. This is now significantly different
from your previous opinion "The Standard says that you may reuse the
storage if the lifetime of the object ended. The lifetime ends with a
call to the destructor.".
| Quote: | If your object (due to a specific object model Daveed described) ends
its life, the storage for the base classes (which are allocated
elsewhere) has to be released. How? I don't know. Ask Daveed.
|
Neither I know it  IMHO Daveed knows a lot about this problem
and about possible strategies to tackle it.
Our current consensus seems to be that reusing w/o dtor is allowed
(not UB), but with some object models/c++-implementations under
discussion this practise would generate serious resource leaks.
| Quote: | If I understand what Daveed was talking about, your schema will
have "gaps" in the allocated 'p0' for the base classes. You will
have fewer 'ANY_X' objects allocated than the "real size" of any
ANY_X object is. "sizeof" reports the number of bytes taken by
all subobjects combined. Given that the most derived object will
contain pointers to base class objects, every pointer will waste
sizeof(void*) in the entire object (because it has to be accounted
for).
|
With 'waste' I meant the necessity to reserve enough address space
(besides the 1024*1024 bytes as requested) and page file space, so that
later a possible ANY_X-creation needing large hidden subobject-allocation
may succeed. The factor will be up to the largest ...
'sizeof(T)/hidden_sizeof(T)'
..... for any T in the program.
| Quote: | I am not seeing any "infinite" amounts of memory here.
|
You are probably right. I saw "infinite" as the unavoidable consequence
when creating AGAIN objects w/o prior dtor; but now I think that during
the "n'th object creation" the implementation gets enough information
to reclaim all non-destructed resources of the "(n-1)'th creation" ...
this doesnt make the c++ implementation easier, but this way it can
reliably avoid to leak infinite resources.
Regards,
Markus.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Powered by phpBB © 2001, 2006 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
