"Crosbie Fitch" wrote:
> "James Dennett" <jdennett@acm.org> wrote in message
> news:BhUpg.845$lv.10@fed1read12...
> > The thing is that it's *not* POD -- POD has a definition,
>
> Sorry, I've been assuming it's obvious: The definition of POD would be
> amended to include 'struct_pod'.

You seem to think of POD-ness as being defined in terms of  how it's
implemented; it isn't - it's defined in terms of which types qualify as
POD types. The implementation of POD types is constrained, but not
defined, by the many promises the standard makes about POD types that
it doesn't make about other types.

It's generally a bad idea to re-define an existing concept to apply to
things it didn't previously apply to. If it were modified, then every
one of the dozens of guarantees that the standard makes about  POD
types would have to be reviewed, and many of them would have to be
re-written to say that they apply only to POD types which aren't
struct_pod types. It's far simpler to re-write the descriptions of the
guarantees that would apply to struct_pod types, and specify that they
do apply to both PODs and struct_pod types. And, as I pointed out
earlier, if we take that approach, then struct_pod is a bad name for
the relevant keyword.

> >  I don't think there's any chance of something
> > like this being standardized until/unless it's implemented
> > in some compilers, so you might be better to work on getting
> > it used in the real world before trying to device the perfect
> > syntax for standardization.
>
> It is implemented in compilers. They currently have tests to disable the
> implementation that would otherwise occur, e.g. 'If class has assign-copy it
> is non-POD - disallow in situations where only POD may occur'.

Yes, but this isn't exactly what you're advocating. The first step
should be to get someone to implement exactly the thing that you're
advocating, as an extension, and get some real world experience with
using it. That experience will give you hard data to document that it
is a) efficiently implementable and b) sufficiently useful to justify
changing the standard, which are important things that the committee
wants to know before it changes the standard.

The standard isn't the place for experimentation with new features
(though it has been misused that way in the past). The stardard is the
place for writing in stone those features which have been tested
sufficiently thoroughly to justify making them permanent unalterable
features of the language. That's because the need for backwards
compatibility makes it very difficult, bordering upon the impossible,
to remove any feature from the language, once it's been added.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

""Crosbie Fitch"" <crosbie@digitalproductions.co.uk> skrev i
meddelandet news:26udncyqLZFvhTTZnZ2dnUVZ8t2dnZ2d@bt.com...
> "James Dennett" <jdennett@acm.org> wrote in message
> news:BhUpg.845$lv.10@fed1read12...
>> The thing is that it's *not* POD -- POD has a definition,
>
> Sorry, I've been assuming it's obvious: The definition of POD would
> be amended to include 'struct_pod'.

What exactly is the definition then?

>
>>  I don't think there's any chance of something
>> like this being standardized until/unless it's implemented
>> in some compilers, so you might be better to work on getting
>> it used in the real world before trying to device the perfect
>> syntax for standardization.
>
> It is implemented in compilers. They currently have tests to disable
> the implementation that would otherwise occur, e.g. 'If class has
> assign-copy it is non-POD - disallow in situations where only POD
> may occur'.

It is actually the other way round - the compiler can implement the
special functions, base classes and access specifiers any way it
wants. In the absence of such, there isn't very much to optimize, is
there?

The only restriction is that if all members are public, they have to
be allocated in the order they appear. That's all there is to PODs.
The compiler doesn't have to disable anything, beacuse there is
nothing to disable!

> Few use classes in POD situations precisely because being able to
> override the assign-copy operator is pretty essential. NB That
> doesn't mean that the class cannot be designed to survive memcpy.

The most common reason for adding a copy constructor and assignment
operator is precisely beacuse the struct is not a pod in the first
place. If it is, the compiler generated defaults just work.

>
> Alternatively, one could use explicit:
>
> struct MyPod
> {    int n;
>    explicit MyPod& operator=(const MyPod& m) { foo(); }
> };
>
> Because the assign-copy is marked 'explicit', it does not break the
> podness of MyPod.
>
> explicit would also be applicable in the same manner to default
> constructors, and destructors.

Explicit already has another meaning in some constructors, that can
work as a default constructor:

struct notpod
{
   explicit notpod(int x = 0);
};

You suggestion would change that.


Bo Persson


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Chris Jefferson wrote:
> "Crosbie Fitch" wrote:
> > So, how about a new keyword 'struct_pod'?
> >
> > This is equivalent to struct except that struct_pod explicitly requires
> > implementation as POD, except of course where this is impossible.
>
> If type traits gets into C++03 (and I would be suprised if it didn't),
> there will be the compile time type-trait is_pod. This will let users
> check at compile time if a particular structure is a pod. I would
> assume that this value will have to be the same over all compilers? I
> was unaware there were cases where the compiler had a choice.

POD types are strictly defined by the standard; compilers don't get a
choice in the matter. However, there are a couple of dozen guarantees
that the standard makes for POD types, which it doesn't make for
non-POD types. The choice that implementations do have is how to
implement a particular non-POD type. Depending upon the type, it may be
possible to implement it in such a way that some (and maybe even all)
of those guarantees could be extended to cover that non-POD type, as
well.

What Crosbie Fitch is asking for could be fitted into the current
framework of the standard by specifying that some (probably not all) of
the guarantees that currently apply only to POD types must also apply
to types declared with a new keyword. In order for such guarantees to
be efficiently implementable on all platforms, restrictions will need
to be imposed on the types declared with that keyword. The more
guarantees that apply to such types, the more restrictions will have to
be imposed. If the list of guarantees is the same as currently apply to
POD types, the restrictions will also have to be essentially identical
to the current ones. Therefore, the concept only makes sense if the set
of guarantees that apply to objects declared with the new keyword is
weaker than the set that currently applies to POD types. Therefore, I
don't think that struct_pod is a good choice for that keyword.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

"Chris Jefferson" <4zumanga@gmail.com> wrote in message
news:1151661177.729655.216320@p79g2000cwp.googlegroups.com...
> If type traits gets into C++03 (and I would be suprised if it didn't),
> there will be the compile time type-trait is_pod. This will let users
> check at compile time if a particular structure is a pod. I would
> assume that this value will have to be the same over all compilers? I
> was unaware there were cases where the compiler had a choice.

In some cases a struct is defined by the standard as non-POD in order to
permit the compiler liberties that it would not be able to exploit were it
POD. However, some of these liberties come at the expense of sacrifices in
functionality, e.g. no non-default assign-copy operator.

Nevertheless, there are many classes of object with non-default assign-copy
operators that the programmer would prefer to be classed as POD - wholly
cognisant of the consequences.

> I'm thought that a copy constructor wasn't allowed on pods? I've
> previously written code in which I assumed I could memcpy pods...

That's precisely why we introduce 'struct_pod' - to remove this restriction.

And yes, it's a sharp knife - just as sharp as 'union' or 'goto' or
'void**'. You wouldn't want novices to play with these things, but that's no
reason to keep them out of the box.

So, struct_pod can be used to define any struct that presents no difficulty
for a compiler to classify and represent as it would any other POD struct,
except that no non-default operators are prohibited.

And yes, the very fact of using struct_pod rather than struct is taken to
indicate that the programmer knows full well that instances of the struct
will be treated as if POD, e.g. they must withstand memcpy, will not
necessarily be initialised, will not necessarily be destroyed. This
obviously means the situations in which they can be used safely are the ones
in which the programmer takes full responsibility for guaranteeing that
safety.


struct_pod
As usual:
Has no non-static data members of type pointer to member, non-POD-struct,
non-POD-uinion (or array of) or reference.
But, unusually:
1) must be a member of a class or union (though may of course be defined
outside it)
2) may have a single non-virtual POD base (which may itself have such a
base)
3) has no virtual methods
4) may have member access specifiers
5) may have user defined default constructor, copy constructor, copy
assignment operator, destructor, and any other operator.
6) must not be anonymous
7) has no default implementation of any constructor, destructor or other
operator
8) is copied by memcpy unless copied explicitly or its container has a user
defined copy operator.
9) is not constructed unless this is done explicitly or its container has a
user defined constructor
10) is not destroyed unless this is done explicitly or its container has a
user defined destructor

Microsoft's anonymous struct seems to operate somewhat similar to this in
that it PODifies what would otherwise be non-POD, e.g. wrap a non-pod struct
within anonymous struct and suddenly the whole thing's POD.


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

"Crosbie Fitch" posted:

> So, how about a new keyword 'struct_pod'?


If traits come in, maybe we can do something like:

struct MyStruct {


    /* All members here */


    BOOST_STATIC_ASSERT( MyStruct::is_pod == true );

};



--

Frederick Gotham

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Chris Jefferson wrote:
> "Crosbie Fitch" wrote:
> > So, how about a new keyword 'struct_pod'?
> >
> > This is equivalent to struct except that struct_pod explicitly requires
> > implementation as POD, except of course where this is impossible.
>
> If type traits gets into C++03 (and I would be suprised if it didn't),
> there will be the compile time type-trait is_pod. This will let users
> check at compile time if a particular structure is a pod. I would
> assume that this value will have to be the same over all compilers? I
> was unaware there were cases where the compiler had a choice.

I believe you probably meant the forthcoming C++0X standard - otherwise
you're three years too late. But there's no need to wait for type
traits at all, the Technical Report 1 (TR1) already has them. So much
for the good news. The bad news is that the is_pod type trait cannot be
used to test for a POD-struct.

A POD-struct is a struct (not a POD) and so (like all structs) is a
compound type. Since is_pod tests only for a POD types, the expression:

    std::tr1::is_pod<MyPodStruct>::value

evaluates to false.

To implement a type trait to detect a POD-struct would need some
"inside" help from the compiler. C++ does not have the necessary type
reflection support needed to implement a type test on each struct
member in a generic manner.

Greg

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

<kuyper@wizard.net> wrote in message
news:1151681206.051788.261780@p79g2000cwp.googlegroups.com...
> Therefore, the concept only makes sense if the set
> of guarantees that apply to objects declared with the new keyword is
> weaker than the set that currently applies to POD types.

Well, yes, the idea is to have a struct that defines an otherwise non-POD
class that the programmer can force to be treated as POD (pragmatic
restrictions remaining), knowing that certain guarantees do not apply, i.e.
user defined constructors, copy operators, and destructors are not
necessarily called in all cases - and hence the programmer must cater for
those cases or ensure the struct is safe in those cases.

> Therefore, I don't think that struct_pod is a good choice for that
> keyword.

struct_pod_but_unguaranteed ?
struct_unguaranteed_pod
struct_unsafe_pod
struct explicit


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Crosbie Fitch wrote:
> <kuyper@wizard.net> wrote in message
> news:1151681206.051788.261780@p79g2000cwp.googlegroups.com...
>> Therefore, the concept only makes sense if the set
>> of guarantees that apply to objects declared with the new keyword is
>> weaker than the set that currently applies to POD types.
>
> Well, yes, the idea is to have a struct that defines an otherwise non-POD
> class that the programmer can force to be treated as POD (pragmatic
> restrictions remaining), knowing that certain guarantees do not apply, i.e.
> user defined constructors, copy operators, and destructors are not
> necessarily called in all cases - and hence the programmer must cater for
> those cases or ensure the struct is safe in those cases.
>
>> Therefore, I don't think that struct_pod is a good choice for that
>> keyword.
>
> struct_pod_but_unguaranteed ?
> struct_unguaranteed_pod
> struct_unsafe_pod
> struct explicit

The thing is that it's *not* POD -- POD has a definition,
and it's not what you want.  So that rules out the first
three.  "unchecked_struct" might be closer, as what you're
asking for is that certain rules that are normally checked
for classes used in certain contexts be ignored.

Some languages would prefer to do that with a pragma, and
that might also be a reasonable way to do it for a C++
compiler.  I don't think there's any chance of something
like this being standardized until/unless it's implemented
in some compilers, so you might be better to work on getting
it used in the real world before trying to device the perfect
syntax for standardization.

-- James

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

"James Dennett" <jdennett@acm.org> wrote in message
news:BhUpg.845$lv.10@fed1read12...
> The thing is that it's *not* POD -- POD has a definition,

Sorry, I've been assuming it's obvious: The definition of POD would be
amended to include 'struct_pod'.

> Some languages would prefer to do that with a pragma, and
> that might also be a reasonable way to do it for a C++
> compiler.

Well, no. This is a significant change.

struct_pod MyPod
{    int n;
    MyPod& operator=(int n) { bar(); }    // Valid in POD today
    MyPod& operator=(const MyPod& m) { foo(); }    // Would become valid
};

union U
{    int x;
    MyPod m;
};

U a,b;

a.x=2;
b.x=5;
b.m=6;    // bar() is called
a.m=b.m;    // foo() is called

This could not be done without struct_pod.

>  I don't think there's any chance of something
> like this being standardized until/unless it's implemented
> in some compilers, so you might be better to work on getting
> it used in the real world before trying to device the perfect
> syntax for standardization.

It is implemented in compilers. They currently have tests to disable the
implementation that would otherwise occur, e.g. 'If class has assign-copy it
is non-POD - disallow in situations where only POD may occur'.

Few use classes in POD situations precisely because being able to override
the assign-copy operator is pretty essential. NB That doesn't mean that the
class cannot be designed to survive memcpy.

Alternatively, one could use explicit:

struct MyPod
{    int n;
    explicit MyPod& operator=(const MyPod& m) { foo(); }
};

Because the assign-copy is marked 'explicit', it does not break the podness
of MyPod.

explicit would also be applicable in the same manner to default
constructors, and destructors.


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

So, how about a new keyword 'struct_pod'?

This is equivalent to struct except that struct_pod explicitly requires
implementation as POD, except of course where this is impossible.

So, you can keep all the existing IMPLICIT rules that govern when a compiler
must implement structures as POD, but the use of struct_pod enables a
programmer to express this requirement explicitly - which consequently
enables them to define ANY operators for that struct, especially
constructors, assignment, and destructors. In other words, where a compiler
would otherwise have the discretional option to decide whether to implement
a struct as POD or not, struct_pod requires the choice of POD.

One could still have some limitations, e.g. that a struct_pod can't have
virtual functions, multiple inheritance, or references as members (though
one may be able to effectively oblige the compiler to implement refs as
pointers).

struct_pod Data   // All operators permitted
{
    double r;
    Data(double rr):r(rr) { }
    Data& operator=(const Data& d) { r=d.r; return *this; }
 };

struct_pod M: Data, Z    // Error - MI disallowed
{...
};

class M: Data, Z    // Fine - non-pod can inherit from pod
{...
};

struct_pod R: Data
{    float& f;    // Possible error - if we cannot require R.f to be
implemented as float*
    Data():f(...) { }    // Constructor would be mandatory
};

class R: Data    // Fine - implicit non-pod can inherit from pod
{    float& f;
    R():f(...) { } // Constructor is mandatory
};

struct_pod V: Data
{        virtual ~Data() { }    // Error: struct_pod cannot have virtual
methods
};

class V: Data    // Fine: non-pod can inherit from pod
{        virtual ~Data() { }
};

class X
{
    Data d;    // Encapsulation fine
    virtual int M() const { }
};

struct_pod P: Data    // Fine: explicit pod P can inherit from pod
{    int j;
};

class P: Data    // implicit pod P is also pod
{    int j;
};

struct_pod S: X    // Error: pod cannot inherit from non-pod
{
};

struct_pod Y    // Fine, despite non-trivial constructor requirement
{
    Y() { ... }
    union
    {    double m;
           Data d;    // Explicit pod, so fine - despite assign-copy
operator
    };
};

class Q: Data    // All members pod, so Q is pod
{    P p;
        Y y;
};

If you ask me, struct_pod is what struct should have been in the first
place, i.e. the layout and representation of data is important, but
functionality must not be consequently sacrificed in the name of safety.



---
[ 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.comeaucomputing.com/csc/faq.html                      ]

"Crosbie Fitch" wrote:
> So, how about a new keyword 'struct_pod'?
>...where a compiler would otherwise have the discretional option
> to decide whether to implement a struct as POD or not,
> struct_pod requires the choice of POD.

Very short response: I cannot find this discretional option. What part
of the Standard definition of PODs do you mean?

As I read it, a POD is a POD if and only if it abides by every rule for
PODs, no compiler freedom allowed.

Regards,
Michiel Salters

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

"Crosbie Fitch" wrote:
> So, how about a new keyword 'struct_pod'?
> <snip>
> If you ask me, struct_pod is what struct should have been in the first
> place, i.e. the layout and representation of data is important, but
> functionality must not be consequently sacrificed in the name of safety.

I concur heartily: the language would been better if PODness was
implied directly by "struct" and "union" and all non-class types,
rather than wasting the keyword "struct" merely on the convenience of
the implied "public:".  PODness being implied by a complex series of
rules is really unfortunate, and unnecessary for compatibility with C.
The rules should have been the other way around: If the declared struct
does cannot be implemented as a POD, the compiler should reject the
code.

Having said this, I think it is going to be an uphill battle to
introduce a fresh keyword to fix what IMHO was a mistake made in the
transition from C to C++...

Manfred

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

<Michiel.Salters@tomtom.com> wrote in message >
> Very short response: I cannot find this discretional option. What part
> of the Standard definition of PODs do you mean?
>
> As I read it, a POD is a POD if and only if it abides by every rule for
> PODs, no compiler freedom allowed.

The standard does not place any requirement on an implementation as to how
it represents non-POD objects. Therefore it is at the compiler's discretion
as to how certain non-POD objects are represented.

It simply lists the circumstances in which objects MUST be represented as
POD, and circumstances in which only POD objects may appear.

We can add to those circumstances defining POD to include objects defined
using struct_pod. struct_pod will be defined to exclude situations where it
would clearly be an arduous imposition, e.g. virtual methods.

At the moment we have compilers quite able to implement objects as POD, but
the standard excludes them, indeed requires the compiler to classify them as
non-POD in order to be considered compliant.


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Crosbie Fitch wrote:
> <Michiel.Salters@tomtom.com> wrote in message >
>> Very short response: I cannot find this discretional option. What part
>> of the Standard definition of PODs do you mean?
>>
>> As I read it, a POD is a POD if and only if it abides by every rule for
>> PODs, no compiler freedom allowed.
>
> The standard does not place any requirement on an implementation as to how
> it represents non-POD objects. Therefore it is at the compiler's discretion
> as to how certain non-POD objects are represented.
>
> It simply lists the circumstances in which objects MUST be represented as
> POD, and circumstances in which only POD objects may appear.

POD is not a way of representing objects; POD is a set
of constraints on properties of objects, intended to
arrange that those objects are implemented as dumb
bunches of bytes.

POD objects *must* be represented in a way which allows
certain operations that are not required to work for
non-PODs.  That's all.

I think what you're saying is that you'd like these
operations to be permitted for some categories of types
that do not meet the standard's definition of POD.

If you'd like to write a formal proposal for exactly
which types you want the guarantees to apply to, along
with any necessary syntax for promising that a type
will obey those rules, situations in which diagnostics
are required, and a good argument for why your change
would be worthwhile (i.e., justify its cost), then I
imagine the committee would read with interest, though
my guess is that such a proposal has little chance of
success and wouldn't be considered for C++0x in any
case.

-- James

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

"Crosbie Fitch" wrote:
> So, how about a new keyword 'struct_pod'?
>
> This is equivalent to struct except that struct_pod explicitly requires
> implementation as POD, except of course where this is impossible.

If type traits gets into C++03 (and I would be suprised if it didn't),
there will be the compile time type-trait is_pod. This will let users
check at compile time if a particular structure is a pod. I would
assume that this value will have to be the same over all compilers? I
was unaware there were cases where the compiler had a choice.

>
> struct_pod Data   // All operators permitted
> {
>     double r;
>     Data(double rr):r(rr) { }
>     Data& operator=(const Data& d) { r=d.r; return *this; }
>  };
>

I'm thought that a copy constructor wasn't allowed on pods? I've
previously written code in which I assumed I could memcpy pods...

Chris

---
[ 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.comeaucomputing.com/csc/faq.html                      ]