--- Begin Message ---
- From: "William M. \(Mike\) Miller" <william dot m dot miller at gmail dot com>
- To: undisclosed-recipients:;
- Date: Wed, 3 Feb 2010 12:13:18 -0500
- Subject: Re: C++ object model and dynamic type
- Authentication-results: os-mail-1.tamu.edu; dkim=permerror (body hash did not verify [final] [TEST]) header.i=@gmail.com
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=WWLOA3Yooi0uDwqKxNp5XdGZcH2Df3rlzPby2dI20Ys=; b=HcrMSgQn3fsMYsIyNq5/KlYLZPc9/qHVAH3lN72f1yLgW3/HPVcInz5VCmWfHbZXrL aGVnaeQk60e9dqi2dXl74l5pMlQxptneebR4lCETvLoZ7q68YEh6NHQqnFUQT2F0PHWe WPnvUIMBJdFNmnPGV9sNGMyrx86JsVZzN8Mwg=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=nXvardUk4YoOxUyRbd6zn3w4I/2MDGwtGURdKu4fMD0JsUAfQxZbkjFfEHkEk0cbhC nyRYTx1kSDaxC1hUrPVxvhpmtO1CHZIj2pP8YmJCFhyhbGKfrZuVVqC6YP+ASaWGhBX5 jU8aGVSxoy6ZPBwScMK6L/hr4lBe3oF5iCEU8=
- References: <874olyb6ms.fsf@gauss.cs.tamu.edu>
- Reply-to: c++std-core at accu dot org
- Transport-options: /ignore
- Xref: gauss.cs.tamu.edu mail.misc:48901
To: C++ core language mailing list
Message c++std-core-15735
On Wed, Feb 3, 2010 at 11:56 AM, Gabriel Dos Reis <gdr@cs.tamu.edu> wrote:
> To: C++ core language mailing list
> Message c++std-core-15734
>
> Hi,
>
> Consider the following program fragment
>
> Â Âextern void f(int*);
>
> Â Âint g() {
> Â Â Â int i = 3;
> Â Â Â int* p = &i;
> Â Â Â f(p); Â Â Â Â Â Â // #1
> Â Â Â return i;
> Â Â}
>
> We can assume that the function 'f' does not 'free' its arguments, nor
> does it use funny memcpy().
>
> A question: can a C++ compiler optimizer (that uses a type-based alias
> analysis) assume that, during a call to g(), the *variable* 'i' always
> designates an object of type 'int', especially after the call to 'f'?
>
> Said, differently is it accurate to say that a variable definition
> prescribes "forever" the types of objects that it can hold? ÂCan
> that storage be reused to store objects of any type, or just objects of
> compatible types?
> For example, would the following be a valid definition of 'f'?
>
> Â Â Âvoid f(int* p) {
> Â Â Â Â new (p) float(1.2);
> Â Â Â}
>
>
> Answers to these questions have practical consequences in terms of
> optimizations that a C compiler is permitted to do, but would not be
> applicable to a C++ program -- the old myth of C++ intrinsic slowness
> will finally come true. ÂIn a sense, C++ would become a sort of
> dynamic language with declared types saying very little about runtime
> values.
>
>
> My sense is that only objects of compatible types may be stored in
> a variable, however I do not see a clear statement to that effect in the
> standard text. ÂNote that restricting to objects of compatible types
> still allows allocators that use static or automatic storage (since they
> would be using arrays of characters.)
3.8p7-9 are intended to address concerns such as these. The
existing wording primarily addresses class objects and particularly
class objects with destructors (p7, for instance, which most directly
applies to your example and requires that the old and new objects
have the same type, only applies after the lifetime of the original
object has ended, which only occurs for scalar objects when their
storage is freed), so we probably need to tweak it a bit to make it
clear that non-class objects are also covered.
I'll open an issue for this.
--
William M. (Mike) Miller | Edison Design Group
william.m.miller@gmail.com
--- End Message ---