Alex Oren <response@myrealbox.com> wrote:
[...]
: I mentioned in another thread that I'd like to see separation of classes
: and structs such that only PODs can be structs.

Prohibiting references in structs would break a lot of my code.

: While I like the terseness of the "struct" notation when posting
: semi-trivial examples, I submit that classes and POD structs are
: different concepts and should be treated as such by the language.

So in addition to eliminating non-POD structs, you'd also elminiate
POD classes?  Very radical!

What would happen if we dropped the notion of POD altogether and required
the stricter layouts for all struct or class objects?

Tom Payne

---
[ 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                       ]

On Tue, 28 May 2002 17:47:37 GMT, Tom Puverle wrote in
<ad09g0$mqj$1@pegasus.csx.cam.ac.uk>:

> One of the things that might be nice would be to make an abstraction
> distinction between structs and classes. Structs could be made POD only,
> while classes could be used for user defined data types. One of the
> advantages of this would be to say that struct members may not be reordered
> while the compiler may choose to reorder the members of a class to improve
> size/alignment. I guess there might be some problems when using third party
> precompiled binaries but that isn't unresolvable.
>
> IMHO the two most significant reasons for using POD structs are the
> following:
>                     - Interfacing to C APIs
>                     - Structs dictated by OS/Hardware

I mentioned in another thread that I'd like to see separation of classes
and structs such that only PODs can be structs.

While I like the terseness of the "struct" notation when posting
semi-trivial examples, I submit that classes and POD structs are
different concepts and should be treated as such by the language.


Best regards,
Alex.

--
To email me, replace "myrealbox" with "alexoren".
Sorry for the inconvenience.  Blame the spammers.

---
[ 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                       ]

One of the things that might be nice would be to make an abstraction
distinction between structs and classes. Structs could be made POD only,
while classes could be used for user defined data types. One of the
advantages of this would be to say that struct members may not be reordered
while the compiler may choose to reorder the members of a class to improve
size/alignment. I guess there might be some problems when using third party
precompiled binaries but that isn't unresolvable.

IMHO the two most significant reasons for using POD structs are the
following:
                    - Interfacing to C APIs
                    - Structs dictated by OS/Hardware

Perhaps we could generalise this slightly: When writing high level
applications in C++ one rarely uses things like unions, POD structs, bit
fields (ever?) and other low level features. It might be good to be able to
dissable those as a compiler option. (or rather enable them!) I guess this
could be further extended to elimitate pointers: Dissalow pointers and
C-like arrays and provide a form of "rebindable reference to class" type
(rebind using e.g. a "set" keyword). There are several immediate advantage
to this:
                    - Rebindable references to could provide the mechanism
to use garbage collection in C++
                        (please note that I am not making a statement of
whether this is good or bad)
                    - Users would be forced to use object-like containers
like std::vector instead of plain arrays.

This IMHO would provide a "Java" like facilities for people who don't care
about the low level features while still maintaining the ability to provide
all the "advanced" functionality to OS/library/Device driver writers.

Ready for flame,

Tom



---
[ 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                       ]

Tom Puverle wrote:

> One of the things that might be nice would be to make an abstraction
> distinction between structs and classes. Structs could be made POD only,
> while classes could be used for user defined data types. One of the
> advantages of this would be to say that struct members may not be reordered
> while the compiler may choose to reorder the members of a class to improve
> size/alignment. I guess there might be some problems when using third party
> precompiled binaries but that isn't unresolvable.
>
> IMHO the two most significant reasons for using POD structs are the
> following:
>                     - Interfacing to C APIs
>                     - Structs dictated by OS/Hardware


   and inter-address-space communications such as PDU/datagram formats or such
as message-formats in RTOS (multi)producer-(multi)consumer message-queues.  The
implied pointer to virtual table for classes with at least one virtual function
is almost certainly the wrong address in another address-space.  The implied
pointer for virtual inheritance is almost certainly the wrong address in another
address-space.

   See the following for a demonstration of how typecasted POD structs can be
used efficiently in realtime embedded systems:

http://groups.google.com/groups?dq=&hl=en&lr=&frame=right&th=b38fe00374c83f54&seekm=3CF1E7D6.DA292461%40sea.ericsson.se#link6

   PDU = protocol data unit
   RTOS = realtime operating system


> Perhaps we could generalise this slightly: When writing high level
> applications in C++ one rarely uses things like unions, POD structs, bit
> fields (ever?) and other low level features. It might be good to be able to
> dissable those as a compiler option.


   And thus disable C++'s usefulness in realtime embedded systems and in
device-drivers by relegating such engineers to some sort of rejected weird
special-case fringe.  If ideas such as these ever-more-abstracted,
ever-more-inefficient, ever-more-luxurious proposals were ever to be seriously
entertained by standards bodies or by compiler vendors, then C++'s usefulness as
a medium-level language are seriously compromised.  Then it becomes C++ for the
purely-academic computer scientists instead of C++ for a wide variety of
efficiency-minded engineers including realtime embedded systems and writers of
device-drivers.

> (or rather enable them!) I guess this
> could be further extended to elimitate pointers: Dissalow pointers


   Disable pointers *everywhere*?  I think not.  Even under the harshest of
restrictions on pointers common in the various C++ subcommunities still boils
down to having pointers in private member data of certain template-based
smart-pointer classes and then permitting only smart-pointers to be used elsewhere.

> and
> C-like arrays and provide a form of "rebindable reference to class" type
> (rebind using e.g. a "set" keyword). There are several immediate advantage
> to this:
>                     - Rebindable references to could provide the mechanism
> to use garbage collection in C++
>                         (please note that I am not making a statement of
> whether this is good or bad)
>                     - Users would be forced to use object-like containers
> like std::vector instead of plain arrays.

 >

> This IMHO would provide a "Java" like facilities for people who don't care
> about the low level features while still maintaining the ability to provide
> all the "advanced" functionality to OS/library/Device driver writers.


   That would split the C++ community into two portions: one portion with that
compiler flag on and one portion with that compiler flag off.  Those portions
would evolve separately to the point of wanting different standards content.  In
some respects that would be advantageous.  In other respects that would be
disadvantageous.  It comes down to:  should humankind have:

   1) one amalgamated C++ spectrum of subcommunities all getting along with a
compromised language feature-set under the philosophy that each end of the wide
spectrum of philosophies helps trim off the extreme/radical/unwise thinking of
the other end of the spectrum or

   2) two more-highly-focused clusterings of communities, each with its own
language & language standard & library standard, where 2A) one cluster focuses
on pushing C++ abstractions ever higher into ever more expansive territory
(possibly going so far as to dump C compatibility over-board) and 2B) the other
cluster fine-tunes the original school-of-thought of the Stroustrup-era/C++1998
improved-C/multiparadigm-C middle-level language?

---
[ 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                       ]

>    And thus disable C++'s usefulness in realtime embedded systems and in
> device-drivers by relegating such engineers to some sort of rejected weird
> special-case fringe.

Not the case I believe - I just think that the day to day application
programmer
doesn't need to worry about such things - why should she?

> If ideas such as these ever-more-abstracted,
> ever-more-inefficient,

I think you will find that most of the things I suggested allowed for MORE
efficiency rather
than less. E.g.
                    - Reordering of data: - space/access speed improvement
                    - No pointers => no/minimal aliasing => better
optimisation

> ever-more-luxurious

luxurious? I would consider language support for MultiMethods luxurious.
Optimisation? No,
I call that a necessity.
OTOH, why not allow yourself this luxury? If you want to code in hex, why
don't you?

> proposals were ever to be seriously
> entertained by standards bodies or by compiler vendors, then C++'s
usefulness as
> a medium-level language are seriously compromised.

Personally I don't believe my idea (as to distinguish it from a PROPOSAL)
would do
any of that.

> Then it becomes C++ for the
> purely-academic computer scientists instead of C++ for a wide variety of
> efficiency-minded engineers including realtime embedded systems and
writers of
> device-drivers.

1) Academia is not always bad. Remember it gave you computers in the first
place. There are some
    very good ideas out there.
2) Another distinction in academia is that researchers offen try to come up
with a proof of concept
    rather than a generally applicable method (Remember this? THERE
EXISTS... an infinite number of
    primes... )

>    Disable pointers *everywhere*?  I think not.

Neither do I. Library implementers etc. who provide e.g. smart pointers will
obviously
need to work with them. Very likely the implementors of std::vector, too
which I mentioned
in the post.

> Even under the harshest of
> restrictions on pointers common in the various C++ subcommunities still
boils
> down to having pointers in private member data of certain template-based
> smart-pointer classes and then permitting only smart-pointers to be used
elsewhere.

Yes but the idea was not to prohibit them completely, but to restrict their
use to a
few well defined places (e.g. smart pointer libraries, low level components)

>    That would split the C++ community into two portions:

But surelly I wouldn't take it that far. That sounds almost like the first
intra-language
war :)

> one portion with that
> compiler flag on and one portion with that compiler flag off.

And why not? Why allow the inexpirienced programmer to use complicated
constructs
that he doesn't need to accomplish his task? There are library writers and
application
writers and device drivers writers each with a different set of skills and
expertise...

Tom


---
[ 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                       ]