On 8 February 2016 at 22:40, H.J. Lu wrote:
> "empty type". An empty type is either an array of empty types or a
> class type where every member is of empty type.
Note that the term "empty type" is commonly used in type theory to
denote a (or the) type with no values. The closest thing C has wo
On 11 February 2016 at 11:53, H.J. Lu wrote:
> Since this isn't Plain Old Data (POD) for the purposes of layout, it
> isn't covered by my proposal for psABI. I leave this to C++ ABI.
You never define "POD for the purposes of layout", and I can only
interpret it as being equivalent to "standard-l
On 11 February 2016 at 13:58, H.J. Lu wrote:
> "POD for the purpose of layout" is defined in the Itanium C++ ABI here:
>
> http://mentorembedded.github.io/cxx-abi/abi.html#definitions
Sorry, I overlooked that.
I still stand by my viewpoint however that triviality of copying and
destruction is th
On 11 February 2016 at 15:00, H.J. Lu wrote:
> I intentionally exclude C++ specific features in my propose.
Yet you use a definition from the Itanium C++ ABI which itself depends
on multiple definitions in a particular version of the C++ standard,
which depend on C++ specific features.
This make
To avoid depending again on precise wording of definitions in C++
standard it may be worth being explicit about the requirement to be
trivially copyable *and* destructible, since although the former
implies the latter in the C++ standard this is not obvious from the
terminology (although you also n
On 11 February 2016 at 16:31, H.J. Lu wrote:
> struct A {
> static void foo (void) ();
> static int xxx;
> };
What about it? It's an empty struct. (And it declares a function and
a variable in the namespace of A, which however do not have any
relevant impact here.)
Matthijs van Duin
___
On 19 February 2016 at 16:27, H.J. Lu wrote:
> We want to include static member functions and exclude non-static member
> functions.
>
There's no reason to disallow non-static member functions in general; they
have no impact on being trivially copyable or not, only the presence of a
non-trivial
On 19 February 2016 at 14:35, Michael Matz wrote:
> struct S {
> S() {something();}
> };
>
> would be an empty type, and that's not what we want.
Why not? The default constructor is never invoked as part of passing
such an object around. Its copy constructor is a nop and requires no
reference t
On 20 February 2016 at 18:55, H.J. Lu wrote:
> struct dummy0
> {
> };
>
> struct dummy
> {
> dummy0 d[20];
>
> dummy0 * foo (int i);
> };
>
> dummy0 *
> dummy::foo (int i)
> {
> return &d[i];
> }
>
> dummy0 *
> bar (dummy d, int i)
> {
> return d.foo (i);
> }
1. This has undefined behavio
On 20 February 2016 at 20:34, H.J. Lu wrote:
> Is there a class, which meets the above definition, with a member function
> which can't be passed without a memory slot or a register?
The EmptyInt class in my first post in this thread. It has no
non-static data members, has standard layout, and h
On 20 February 2016 at 23:35, H.J. Lu wrote:
> Can a compiler tell if a copy constructor or destructor is trivial
> from the class declaration without function body?
Yes, the mere presence of the declaration suffices to render it
non-trivial (unless explicitly declared "= default" like I did with
11 matches
Mail list logo
