Displaying 11 results from an estimated 11 matches for "_basic".
Did you mean:
basic
2008 May 01
0
[LLVMdev] optimization assumes malloc return is non-null
...Yes it does:
Replaceable:
a C++ program may define a function with this function
signature
that displaces the default version defined by the C++
Standard
library.
Required behavior:
Return a non-null pointer to suitably aligned
storage
(_basic.stc.dynamic_), or else throw a bad_alloc exception.
This
requirement is binding on a replacement version of this function.
These _are_ the defined semantics. You cannot imagine any other
semantic and substitute it. Any program that does, is outside the
scope of the standard and ha...
2008 May 01
3
[LLVMdev] optimization assumes malloc return is non-null
...> a C++ program may define a function with this function
> signature
> that displaces the default version defined by the C++
> Standard
> library.
> Required behavior:
> Return a non-null pointer to suitably aligned
> storage
> (_basic.stc.dynamic_), or else throw a bad_alloc exception.
> This
> requirement is binding on a replacement version of this function.
>
> These _are_ the defined semantics. You cannot imagine any other
> semantic and substitute it. Any program that does, is outside the
> scope of...
2008 May 01
3
[LLVMdev] optimization assumes malloc return is non-null
On Apr 30, 2008, at 8:51 PM, David Vandevoorde wrote:
>> This isn't safe in general unless you can (tightly) bound "n". You
>> don't want to overflow the stack.
>
> Ah yes, of course. Does LLVM do this for known & small constant n?
We don't do this currently, primarily because I haven't seen a case
where it is a win yet: it would be very easy to
2008 May 05
0
[LLVMdev] optimization assumes malloc return is non-null
...d function whose definition is provided by a C++
program.
Only one definition for such a function is in effect for the
duration
of the program's execution, as the result of creating the
program
(_lex.phases_) and resolving the definitions of all translation
units
(_basic.link_).
17.1.15 required behavior
[defns.required.behavior]
a description of replacement function and handler function
semantics,
applicable to both the behavior provided by the implementation and
the
behavior that shall be provided by any function definition...
2008 Oct 15
3
[LLVMdev] LLVM 2.4 problem? (resend)
...bjects
introduced by declarations (3.1) and implicitly cre-
ated by the implementation (12.2).
A declaration (clause 7) introduces names into a translation unit or
redeclares names introduced by previous declarations.
An object is a region of storage.
An object is created by a definition (_basic.def_)
Each declaration _creates_ an object. The word create means that each
has a region of bytes, distinct from all others.
> The changes to address Core issue 73 invalidates your reasoning
No, they don't. I'm describing a fundamental feature of C and C++
that cannot be dispute...
2008 Oct 16
0
[LLVMdev] LLVM 2.4 problem? (resend)
...(3.1) and implicitly cre-
> ated by the implementation (12.2).
>
> A declaration (clause 7) introduces names into a translation unit or
> redeclares names introduced by previous declarations.
>
> An object is a region of storage.
>
> An object is created by a definition (_basic.def_)
basic.def doesn't contain the word "create" nor words to that effect,
AFAICT. Furthermore, basic.life 3.8/7 makes it clear that an object
may be created on top of another object, and the name of the first
object will correctly evaluate to the new object.
So that reasoni...
2008 Oct 15
2
[LLVMdev] LLVM 2.4 problem? (resend)
...ns they _must_ compare !=, if they are different objects.
Wether are the same object or or not is answered by the notion of
linkage:
8 An identifier used in more than one translation unit can potentially
refer to the same entity in these translation units depending on
the
linkage (_basic.link_) of the identifier specified in each
translation
unit.
2 A name is said to have linkage when it might denote the same object,
reference, function, type, template, namespace or value as a
name
introduced by a declaration in another scope:
to be pedantically clear, entity...
2008 Oct 15
0
[LLVMdev] LLVM 2.4 problem? (resend)
On Oct 15, 2008, at 6:58 AM, Tatu Vaajalahti wrote:
>> Yes, but why do you think they should get a different address? I can
>> understand that it is surprising that they do, but determining
>> whether
>> this is legal or not requires reading the language standard.
>> Hopefully
>> a language lawyer can chime in and say whether this transform is
>>
2008 Oct 15
4
[LLVMdev] LLVM 2.4 problem? (resend)
On 15.10.2008, at 16.43, Duncan Sands wrote:
>> True, but note that it is the address of a variable that is used, not
>> the value.
>
> Yes, but why do you think they should get a different address? I can
> understand that it is surprising that they do, but determining whether
> this is legal or not requires reading the language standard.
> Hopefully
> a language
2008 Oct 16
2
[LLVMdev] LLVM 2.4 problem? (resend)
On Wed, Oct 15, 2008 at 6:16 PM, David Vandevoorde
<daveed at vandevoorde.com> wrote:
> > An object is created by a definition (_basic.def_)
>
> basic.def doesn't contain the word "create" nor words to that effect
That should be [intro.object]: "An object is a region of storage. An
object is created by a definition..."
> Furthermore, basic.life 3.8/7 makes it clear that an object
> may be crea...
2008 Oct 15
0
[LLVMdev] LLVM 2.4 problem? (resend)
On Oct 15, 2008, at 3:53 PM, Mike Stump wrote:
[...]
> Objects are defined like so:
>
> Two pointers of
> the same type compare equal if and only if they are both null,
> both
> point to the same object or function, or both point one past the
> end
> of the same array.
>
> This means they _must_ compare !=, if they are different objects.
Aha! Thanks for