Why can't PODs have constructors?

[JohnQ]

There must be something at the implementation level that makes the standard
disallow constructors in PODs (?). What is that? Don't most implementations
just break out the constructor member functions into construct_obj_x
non-member functions taking a 'this' ptr?

It sure would be convenient to initialize structs with constructors and
still having them be PODs.

John

[Ian Collins]

JohnQ wrote:

There must be something at the implementation level that makes the
standard disallow constructors in PODs (?). What is that? Don't most
implementations just break out the constructor member functions into
construct_obj_x non-member functions taking a 'this' ptr?

It sure would be convenient to initialize structs with constructors and
still having them be PODs.

It would rule out static initialisation.

--
Ian Collins.

[Roland Pibinger]

On Thu, 26 Jul 2007 05:44:28 -0500, "JohnQ" wrote:

>There must be something at the implementation level that makes the standard
disallow constructors in PODs (?). What is that?
It sure would be convenient to initialize structs with constructors and
still having them be PODs.

Built-in types have constructors (e.g. int i(3);) and you can write
constructors for POD structs.
--
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch

[Victor Bazarov]

Roland Pibinger wrote:

On Thu, 26 Jul 2007 05:44:28 -0500, "JohnQ" wrote:

>There must be something at the implementation level that makes the
standard disallow constructors in PODs (?). What is that?
It sure would be convenient to initialize structs with constructors
and still having them be PODs.

Built-in types have constructors (e.g. int i(3);) and you can write
constructors for POD structs.

I believe the reason for the question is that as soon as you write
a constructor for a POD struct, it stops being a POD struct. Just
something you might want to keep in mind.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Roland Pibinger]

On Thu, 26 Jul 2007 09:13:09 -0400, "Victor Bazarov" wrote:

>Roland Pibinger wrote:

>Built-in types have constructors (e.g. int i(3);) and you can write
constructors for POD structs.

I believe the reason for the question is that as soon as you write
a constructor for a POD struct, it stops being a POD struct.

Why? A constructed POD behaves the same way as a 'C struct' (almost),
it's just initialized properly, e.g.

struct Point {
Point(): x(0), y(0) {}
Point (int xcoord, int ycoord): x(xcoord), y(ycoord) {}
int x;
int y;
};
int main() {
Point p1, p2 (7, 9);
p2 = p1;
Point p3 (p2);
// Point p4 = { 1, 2 }; // error
Point a[99];
}
--
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch

[Marcus Kwok]

Roland Pibinger <rp*****@yahoo.comwrote:

On Thu, 26 Jul 2007 09:13:09 -0400, "Victor Bazarov" wrote:

>>I believe the reason for the question is that as soon as you write
a constructor for a POD struct, it stops being a POD struct.

Why? A constructed POD behaves the same way as a 'C struct' (almost),
it's just initialized properly, e.g.

Because the Standard says so. This post summarizes it:
http://groups.google.com/group/comp....ee32178ad11b2c
--
Marcus Kwok
Replace 'invalid' with 'net' to reply

[Victor Bazarov]

Marcus Kwok wrote:

Roland Pibinger <rp*****@yahoo.comwrote:

>On Thu, 26 Jul 2007 09:13:09 -0400, "Victor Bazarov" wrote:

>>I believe the reason for the question is that as soon as you write
a constructor for a POD struct, it stops being a POD struct.

Why? A constructed POD behaves the same way as a 'C struct' (almost),
it's just initialized properly, e.g.

Because the Standard says so. This post summarizes it:
http://groups.google.com/group/comp....ee32178ad11b2c

Of course, if Roland wants to know why the Standard says so (i.e. what
the rationale behind that definition in the Standard), he should ask
in comp.std.c++, where all rationales for the Standard are discussed.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Jerry Coffin]

In article <wT******************@newssvr23.news.prodigy.net >,
jo***********************@yahoo.com says...

There must be something at the implementation level that makes the standard
disallow constructors in PODs (?). What is that? Don't most implementations
just break out the constructor member functions into construct_obj_x
non-member functions taking a 'this' ptr?

It sure would be convenient to initialize structs with constructors and
still having them be PODs.

The definition of PODs was _intended_ to support two separate things: 1)
static initialization, and 2) layout compatibility with C.

Allowing ctors wouldn't (at least as things are normally implemented)
affect layout compatibility with C. It could, however, remove the
possibility of static initialization.

OTOH, I think this requirement could be loosened somewhat without any
problem: at the very least, I believe a ctor that contained only an
intialization list (no body) and all the initialization values were
constant expressions could still support static initialization. A body
that did essentially the same things (simple assignments, rvalues are
all constant expressions) would be easy to support as well.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Victor Bazarov]

Jerry Coffin wrote:

In article <wT******************@newssvr23.news.prodigy.net >,
jo***********************@yahoo.com says...

>There must be something at the implementation level that makes the
standard disallow constructors in PODs (?). What is that? Don't most
implementations just break out the constructor member functions into
construct_obj_x non-member functions taking a 'this' ptr?

It sure would be convenient to initialize structs with constructors
and still having them be PODs.

The definition of PODs was _intended_ to support two separate things:
1) static initialization, and 2) layout compatibility with C.

Allowing ctors wouldn't (at least as things are normally implemented)
affect layout compatibility with C. It could, however, remove the
possibility of static initialization.

OTOH, I think this requirement could be loosened somewhat without any
problem: at the very least, I believe a ctor that contained only an
intialization list (no body) and all the initialization values were
constant expressions could still support static initialization. A body
that did essentially the same things (simple assignments, rvalues are
all constant expressions) would be easy to support as well.

I guess that introducing such a requirement (to analyse the constructor
for containing constant expressions only, both in the initialiser list
and on the right-hand side of assignments in the body, and no side
effects in the body as well) would put an undue strain on the compiler
implementors.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Zeppe]

JohnQ wrote:

There must be something at the implementation level that makes the
standard disallow constructors in PODs (?). What is that? Don't most
implementations just break out the constructor member functions into
construct_obj_x non-member functions taking a 'this' ptr?

It sure would be convenient to initialize structs with constructors and
still having them be PODs.

IMHO, because of this:

struct Foo
{
Foo(int x, int y) x(x), y(y) {}
int x, y;
};

int main()
{
Foo f; // ERROR!
}

So, no constructors.

Regards,

Zeppe

[Victor Bazarov]

Zeppe wrote:

JohnQ wrote:

>There must be something at the implementation level that makes the
standard disallow constructors in PODs (?). What is that? Don't most
implementations just break out the constructor member functions into
construct_obj_x non-member functions taking a 'this' ptr?

It sure would be convenient to initialize structs with constructors
and still having them be PODs.

IMHO, because of this:

struct Foo
{
Foo(int x, int y) x(x), y(y) {}

There is colon missing there somewhere...

int x, y;
};

int main()
{
Foo f; // ERROR!

Yes, because class 'Foo' has no default c-tor. But how is that
an explanation why it's not a POD any more?

}

So, no constructors.

???

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Zeppe]

Victor Bazarov wrote:

Zeppe wrote:

>int x, y;
};

int main()
{
Foo f; // ERROR!

Yes, because class 'Foo' has no default c-tor. But how is that
an explanation why it's not a POD any more?

Well, to me it was obvious that I should be able to create any POD with
the empty constructor.

>

>}

So, no constructors.

???

Otherwise it would be required to have an empty constructor available,
which would be pretty bad.

Regards,

Zeppe

[Victor Bazarov]

Zeppe wrote:

Victor Bazarov wrote:

>Zeppe wrote:

>>int x, y;
};

int main()
{
Foo f; // ERROR!

Yes, because class 'Foo' has no default c-tor. But how is that
an explanation why it's not a POD any more?

Well, to me it was obvious that I should be able to create any POD
with the empty constructor.

Ah... By "empty constructor" you mean "using default initialisation
semantics". OK.

>[..]

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Howard Hinnant]

In article <wT******************@newssvr23.news.prodigy.net >,
"JohnQ" <jo***********************@yahoo.comwrote:

There must be something at the implementation level that makes the standard
disallow constructors in PODs (?). What is that? Don't most implementations
just break out the constructor member functions into construct_obj_x
non-member functions taking a 'this' ptr?

It sure would be convenient to initialize structs with constructors and
still having them be PODs.

John

Fwiw, a slight revision of
http://www.open-std.org/jtc1/sc22/wg...007/n2294.html was
voted into the C++0X working draft last week. This paper includes the
following rationale:

The proposed changes decompose the current POD requirements into trivial type
requirements and standard-layout type requirements, and remove the dependency
on the definition of aggregates. Because these decomposed requirements are
somewhat less restrictive than the requirements for aggregates, the effect is
to make POD's more broadly useful and solve the problems identified in the
Introduction and Motivating examples. It also opens up the possibility of
designing useful classes that meet one or the other, but not both, of the new
trivial and standard-layout requirements.

-Howard

[Jerry Coffin]

In article <f8**********@news.datemas.de>, v.********@comAcast.net
says...

[ ... ]

I guess that introducing such a requirement (to analyse the constructor
for containing constant expressions only, both in the initialiser list
and on the right-hand side of assignments in the body, and no side
effects in the body as well) would put an undue strain on the compiler
implementors.

I rather doubt it'd be much strain at all -- I'm pretty sure virtually
every reasonably self-respecting compiler's optimizer already detects
such things anyway.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Jerry Coffin]

In article <ho**********************************@johnf2.biosc i.ohio-
state.edu>, ho************@gmail.com says...

[ ... ]

Fwiw, a slight revision of
http://www.open-std.org/jtc1/sc22/wg...007/n2294.html was
voted into the C++0X working draft last week. This paper includes the
following rationale:

Very nice. I can't speak for anybody else, but I would like to say
"Thank you!" to everybody who worked on this for what had to be a lot of
hard work that (unfortunately) will probably go unnoticed by far too
many.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[BobR]

JohnQ <jo***********************@yahoo.comwrote in message...

There must be something at the implementation level that makes the

standard

disallow constructors in PODs (?). What is that? Don't most

implementations

just break out the constructor member functions into construct_obj_x
non-member functions taking a 'this' ptr?

PODs do have Ctor, copy-Ctor, and assignment operators. Otherwise you would
not be able to use them in std containers (like std::vector). You just can't
write your own and keep it a POD ('C'). (IMHO.)

It sure would be convenient to initialize structs with constructors and
still having them be PODs.
John

A little extra step can do that.
This uses a 'RECT' from windows. It's a POD 'C' struct with 4 longs.
Try this with your own POD struct.

struct MyRect : public virtual RECT{
MyRect( long x1 = 0, long y1 = 0, long x2 = 10, long y2 = 10 ){
left = x1; // init the RECT members
bottom = y1;
right = x2;
top = y2;
}
~MyRect(){ this->RECT::~RECT();}
RECT Rect(){ return *this;}
};

{ // main or ?
using std::cout; // for NG post
MyRect rect( 10, 12, 22, 42 );
cout<<" MyRect rect.bottom="<< rect.bottom << std::endl;
RECT rect1 = rect.Rect();
cout<<" RECT rect1.bottom="<< rect1.bottom << std::endl;

cout<<" sizeof(rect)="<<sizeof( rect )<<std::endl;
cout<<" sizeof(rect1)="<<sizeof( rect1 )<<std::endl;
}
/* - output -
MyRect rect.bottom=12
RECT rect1.bottom=12
sizeof(rect)=20
sizeof(rect1)=16 // sliced back to POD
// (sixeof long == 4 on my sys)
*/

Of course it would take something a little more complex to justify the extra
layer, or you would just do:
RECT rect2 = { 14, 19, 25, 55};

[ corrections, comments welcome. ]
--
Bob R
POVrookie

[Ian Collins]

Roland Pibinger wrote:

On Thu, 26 Jul 2007 09:13:09 -0400, "Victor Bazarov" wrote:

>Roland Pibinger wrote:

>>Built-in types have constructors (e.g. int i(3);) and you can write
constructors for POD structs.

I believe the reason for the question is that as soon as you write
a constructor for a POD struct, it stops being a POD struct.

Why? A constructed POD behaves the same way as a 'C struct' (almost),
it's just initialized properly, e.g.

struct Point {
Point(): x(0), y(0) {}
Point (int xcoord, int ycoord): x(xcoord), y(ycoord) {}
int x;
int y;
};
int main() {

Try adding

Point points[2] = {{1,2},{3,4}};

Point p1, p2 (7, 9);
p2 = p1;
Point p3 (p2);
// Point p4 = { 1, 2 }; // error
Point a[99];
}

--
Ian Collins.

[JohnQ]

"Howard Hinnant" <ho************@gmail.comwrote in message
news:ho**********************************@johnf2.b iosci.ohio-state.edu...

In article <wT******************@newssvr23.news.prodigy.net >,
"JohnQ" <jo***********************@yahoo.comwrote:

>There must be something at the implementation level that makes the
standard
disallow constructors in PODs (?). What is that? Don't most
implementations
just break out the constructor member functions into construct_obj_x
non-member functions taking a 'this' ptr?

It sure would be convenient to initialize structs with constructors and
still having them be PODs.

John

Fwiw, a slight revision of
http://www.open-std.org/jtc1/sc22/wg...007/n2294.html was
voted into the C++0X working draft last week. This paper includes the
following rationale:

>The proposed changes decompose the current POD requirements into trivial
type
requirements and standard-layout type requirements, and remove the
dependency
on the definition of aggregates. Because these decomposed requirements
are
somewhat less restrictive than the requirements for aggregates, the
effect is
to make POD's more broadly useful and solve the problems identified in
the
Introduction and Motivating examples. It also opens up the possibility of
designing useful classes that meet one or the other, but not both, of the
new
trivial and standard-layout requirements.

Which sounds like I might get the guarantee I want someday. It also implies
that I can do it now and chances are that it will work.

I have a question, based upon the link you gave. Wouldn't it be easier to
enforce structs to be PODs? That is, just disallow anything in a struct that
is a party spoiler in regards to layout and size. In still other words,
don't allow structs to be classes and let the compiler warn when an attempt
is made to declare or derive or compose illegally. As long as structs are
allowed to evolve into classes, a lot of programmer productivity goes out
the window.

John

[JohnQ]

"BobR" <re***********@worldnet.att.netwrote in message
news:yG*****************@bgtnsc05-news.ops.worldnet.att.net...

>
JohnQ <jo***********************@yahoo.comwrote in message...

>There must be something at the implementation level that makes the

standard

>disallow constructors in PODs (?). What is that? Don't most

implementations

>just break out the constructor member functions into construct_obj_x
non-member functions taking a 'this' ptr?

PODs do have Ctor, copy-Ctor, and assignment operators. Otherwise you
would
not be able to use them in std containers (like std::vector). You just
can't
write your own and keep it a POD ('C'). (IMHO.)

>It sure would be convenient to initialize structs with constructors and
still having them be PODs.
John

A little extra step can do that.
This uses a 'RECT' from windows. It's a POD 'C' struct with 4 longs.
Try this with your own POD struct.

struct MyRect : public virtual RECT{

Why the virtual inheritance?

MyRect( long x1 = 0, long y1 = 0, long x2 = 10, long y2 = 10 ){

Defining all the default args will lead to ambiguity errors being produced
by the compiler.

left = x1; // init the RECT members
bottom = y1;
right = x2;
top = y2;
}
~MyRect(){ this->RECT::~RECT();}

Ooo, that destructor doesn't look good at all there the way you defined it.
(Wouldn't be allowed in a POD either).

RECT Rect(){ return *this;}

You were _trying_ to define a conversion operator, but you don't have to
because MyRect IS a RECT. If you were to embed the RECT into MyRect instead
of derive from it, then you'd need a conversion operator. Currently I'm
doing the derivation from RECT rather than composition (embedding) with
RECT, but it escapes me why I decided that in this case derivation was
better than composition (probably so I don't have to provide accessor
functions and the conversion operator)..

};

That's kind of what I've been doing to get compatibility of MyRect and RECT
(I do something a little different, but for practical discussion, it
suffices to say that). But it doesn't solve the problem since you can't
create an array of MyRects and get the desired layout (a contiguous array of
16-byte RECT-like things). It should be possible to define a MyRect so that
it is 16-bytes and still allows initializing constructors.

Of course it would take something a little more complex to justify the
extra
layer, or you would just do:
RECT rect2 = { 14, 19, 25, 55};

Well consider that you might want to construct a MyRect with 2 MyPoint
objects:

MyRect(MyPoint& origin, MyPoint& extent);

MyRect will (again/still) not FORMALLY be a POD if you define the above
constructor.

John

[Zeppe]

Victor Bazarov wrote:

Zeppe wrote:

>Victor Bazarov wrote:

>>Zeppe wrote:
int x, y;
};

int main()
{
Foo f; // ERROR!
Yes, because class 'Foo' has no default c-tor. But how is that
an explanation why it's not a POD any more?

Well, to me it was obvious that I should be able to create any POD
with the empty constructor.

Ah... By "empty constructor" you mean "using default initialisation
semantics". OK.

Not necessarily, but it could be. I meant that providing a constructor
with arguments in C++ gives the developer the possibility of forbidding
the creation of a class or a struct with the empty constructor, which
can be not desirable when we are handling with POD.

Regards,

Zeppe

[Victor Bazarov]

JohnQ wrote:

"BobR" <re***********@worldnet.att.netwrote in message
news:yG*****************@bgtnsc05-news.ops.worldnet.att.net...

>[..]
struct MyRect : public virtual RECT{

[..]

> ~MyRect(){ this->RECT::~RECT();}

Ooo, that destructor doesn't look good at all there the way you
defined it. (Wouldn't be allowed in a POD either).

Actually, regardless of whether 'RECT' implements a d-tor or not,
this would actually give the code undefined behaviour. In any
situation the destructors of base class subobjects are called
right after the body of the destructor of this class, so here BobR
would actually cause the RECT d-tor to be called twice, which is
a VERY BAD THING(tm).

>[..]

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Howard Hinnant]

In article <UJ******************@newssvr11.news.prodigy.net >,
"JohnQ" <jo***********************@yahoo.comwrote:

Fwiw, a slight revision of
http://www.open-std.org/jtc1/sc22/wg...007/n2294.html was
voted into the C++0X working draft last week. This paper includes the
following rationale:

The proposed changes decompose the current POD requirements into trivial
type
requirements and standard-layout type requirements, and remove the
dependency
on the definition of aggregates. Because these decomposed requirements
are
somewhat less restrictive than the requirements for aggregates, the
effect is
to make POD's more broadly useful and solve the problems identified in
the
Introduction and Motivating examples. It also opens up the possibility of
designing useful classes that meet one or the other, but not both, of the
new
trivial and standard-layout requirements.

Which sounds like I might get the guarantee I want someday. It also implies
that I can do it now and chances are that it will work.

I have a question, based upon the link you gave. Wouldn't it be easier to
enforce structs to be PODs? That is, just disallow anything in a struct that
is a party spoiler in regards to layout and size. In still other words,
don't allow structs to be classes and let the compiler warn when an attempt
is made to declare or derive or compose illegally. As long as structs are
allowed to evolve into classes, a lot of programmer productivity goes out
the window.

I'd probably vote for that in a new language. But not in a revision to
C++. It would break too much code.

-Howard

[JohnQ]

"Howard Hinnant" <ho************@gmail.comwrote in message
news:ho**********************************@johnf2.b iosci.ohio-state.edu...

In article <UJ******************@newssvr11.news.prodigy.net >,
"JohnQ" <jo***********************@yahoo.comwrote:

Fwiw, a slight revision of
http://www.open-std.org/jtc1/sc22/wg...007/n2294.html was
voted into the C++0X working draft last week. This paper includes the
following rationale:

The proposed changes decompose the current POD requirements into
trivial
type
requirements and standard-layout type requirements, and remove the
dependency
on the definition of aggregates. Because these decomposed requirements
are
somewhat less restrictive than the requirements for aggregates, the
effect is
to make POD's more broadly useful and solve the problems identified in
the
Introduction and Motivating examples. It also opens up the possibility
of
designing useful classes that meet one or the other, but not both, of
the
new
trivial and standard-layout requirements.

Which sounds like I might get the guarantee I want someday. It also
implies
that I can do it now and chances are that it will work.

I have a question, based upon the link you gave. Wouldn't it be easier to
enforce structs to be PODs? That is, just disallow anything in a struct
that
is a party spoiler in regards to layout and size. In still other words,
don't allow structs to be classes and let the compiler warn when an
attempt
is made to declare or derive or compose illegally. As long as structs are
allowed to evolve into classes, a lot of programmer productivity goes out
the window.

I'd probably vote for that in a new language. But not in a revision to
C++. It would break too much code.

Well how about leaving 'struct' alone and defining a new keyword:
'PODStruct'? Then even "no padding or aligning allowed" could be also
included in the spec making for some nice IO scenarios. Slowly, 'struct'
would be deprecated.

John

[JohnQ]

"Victor Bazarov" <v.********@comAcast.netwrote in message
news:f8**********@news.datemas.de...

JohnQ wrote:

>"BobR" <re***********@worldnet.att.netwrote in message
news:yG*****************@bgtnsc05-news.ops.worldnet.att.net...

>>[..]
struct MyRect : public virtual RECT{

[..]

>> ~MyRect(){ this->RECT::~RECT();}

Ooo, that destructor doesn't look good at all there the way you
defined it. (Wouldn't be allowed in a POD either).

Actually, regardless of whether 'RECT' implements a d-tor or not,
this would actually give the code undefined behaviour. In any
situation the destructors of base class subobjects are called
right after the body of the destructor of this class, so here BobR
would actually cause the RECT d-tor to be called twice, which is
a VERY BAD THING(tm).

I didn't think a compiler-supplied destructor (does it supply one for POD
structs?) could be called.

John

[Victor Bazarov]

JohnQ wrote:

Well how about leaving 'struct' alone and defining a new keyword:
[..]
Slowly, 'struct' would be deprecated.

I vote for "very slowly". Maybe even "very very extremely slowly".
Like, in the span of fifty years or more...

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Victor Bazarov]

JohnQ wrote:

"Victor Bazarov" <v.********@comAcast.netwrote in message
news:f8**********@news.datemas.de...

>JohnQ wrote:

>>"BobR" <re***********@worldnet.att.netwrote in message
news:yG*****************@bgtnsc05-news.ops.worldnet.att.net...
[..]
struct MyRect : public virtual RECT{

[..]

>>> ~MyRect(){ this->RECT::~RECT();}

Ooo, that destructor doesn't look good at all there the way you
defined it. (Wouldn't be allowed in a POD either).

Actually, regardless of whether 'RECT' implements a d-tor or not,
this would actually give the code undefined behaviour. In any
situation the destructors of base class subobjects are called
right after the body of the destructor of this class, so here BobR
would actually cause the RECT d-tor to be called twice, which is
a VERY BAD THING(tm).

I didn't think a compiler-supplied destructor (does it supply one for
POD structs?) could be called.

What happens if later somebody rewrites 'RECT' and gives it a user-
defined destructor?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[JohnQ]

"Victor Bazarov" <v.********@comAcast.netwrote in message
news:f8**********@news.datemas.de...

JohnQ wrote:

>Well how about leaving 'struct' alone and defining a new keyword:
[..]
Slowly, 'struct' would be deprecated.

I vote for "very slowly". Maybe even "very very extremely slowly".
Like, in the span of fifty years or more...

Even "never" would be fine. _New_ development would/should just avoid the
use of 'struct' in favor of 'class' and 'podstruct'.

John

[JohnQ]

"Victor Bazarov" <v.********@comAcast.netwrote in message
news:f8**********@news.datemas.de...

JohnQ wrote:

>"Victor Bazarov" <v.********@comAcast.netwrote in message
news:f8**********@news.datemas.de...

>>JohnQ wrote:
"BobR" <re***********@worldnet.att.netwrote in message
news:yG*****************@bgtnsc05-news.ops.worldnet.att.net...
[..]
struct MyRect : public virtual RECT{
[..]
~MyRect(){ this->RECT::~RECT();}

Ooo, that destructor doesn't look good at all there the way you
defined it. (Wouldn't be allowed in a POD either).

Actually, regardless of whether 'RECT' implements a d-tor or not,
this would actually give the code undefined behaviour. In any
situation the destructors of base class subobjects are called
right after the body of the destructor of this class, so here BobR
would actually cause the RECT d-tor to be called twice, which is
a VERY BAD THING(tm).

I didn't think a compiler-supplied destructor (does it supply one for
POD structs?) could be called.

What happens if later somebody rewrites 'RECT' and gives it a user-
defined destructor?

Then all the Windows code gets mucked up. ('RECT' is a Windows-ism).

John

[BobR]

JohnQ <jo***********************@yahoo.comwrote in message...

>
"BobR" wrote in message...

struct MyRect : public virtual RECT{

Why the virtual inheritance?

Oops.
I was cleaning out my 'TestBench' program, and removed the wrong code
(had about 5 versions).
Here is the one I meant to post:

struct Rect : RECT{
Rect( long x1 = 0, long y1 = 0, long x2 = 10, long y2 = 10 ){
left = x1; bottom = y1; right = x2; top = y2;}
};

{ // main() or ?
using std::cout // for NG post
Rect rect( 10, 12, 22, 42 );
RECT rect1( rect );
RECT rect1a( Rect( 7, 14, 27, 34 ) );
Rect rect2;
cout<<" Rect rect.bottom="<< rect.bottom <<'\n'
<<" RECT rect1.bottom="<< rect1.bottom <<'\n'
<<" RECT rect1a.bottom="<< rect1a.bottom <<'\n'
<<" Rect rect2.top="<< rect2.top <<'\n'
<<" sizeof(rect)="<<sizeof(rect)<<'\n'
<<" sizeof(rect1)="<<sizeof(rect1)<<std::endl;
}
/* - output -
Rect rect.bottom=12
RECT rect1.bottom=12
RECT rect1a.bottom=14
Rect rect2.top=10
sizeof(rect)=16
sizeof(rect1)=16
*/

Sorry about that.

[ I don't remember what I was 'testing' with the 'virtual inherit',
something to do with "vector<RECT*vRec(10, new MyRect(1,2,3,4));". ]
--
Bob R
POVrookie

[JohnQ]

"BobR" <re***********@worldnet.att.netwrote in message
news:W6****************@bgtnsc05-news.ops.worldnet.att.net...

>
JohnQ <jo***********************@yahoo.comwrote in message...

>>
"BobR" wrote in message...

struct MyRect : public virtual RECT{

Why the virtual inheritance?

Oops.
I was cleaning out my 'TestBench' program, and removed the wrong code
(had about 5 versions).
Here is the one I meant to post:

struct Rect : RECT{
Rect( long x1 = 0, long y1 = 0, long x2 = 10, long y2 = 10 ){
left = x1; bottom = y1; right = x2; top = y2;}

How will the compiler be able to distinguish between using the default
constructor and the one above where you gave default values to all the
arguments? (This is a minor note that is off-topic for the thread).

};

{ // main() or ?
using std::cout // for NG post
Rect rect( 10, 12, 22, 42 );

Fine. Now how about:

Rect rect8(); // ambiguous

RECT rect1( rect );

Can't do that because RECT has not constructor taking a Rect arg. Are you
suggesting that initializing a struct with a struct (from the RECT& operator
of Rect) works? (My C-ismness, or forgetfulness thereof may be apparent).

RECT rect1a( Rect( 7, 14, 27, 34 ) );

Same question as above (and excuse me if I am at times unpedantic).

Rect rect2;
cout<<" Rect rect.bottom="<< rect.bottom <<'\n'
<<" RECT rect1.bottom="<< rect1.bottom <<'\n'
<<" RECT rect1a.bottom="<< rect1a.bottom <<'\n'
<<" Rect rect2.top="<< rect2.top <<'\n'
<<" sizeof(rect)="<<sizeof(rect)<<'\n'
<<" sizeof(rect1)="<<sizeof(rect1)<<std::endl;
}
/* - output -
Rect rect.bottom=12
RECT rect1.bottom=12
RECT rect1a.bottom=14
Rect rect2.top=10
sizeof(rect)=16
sizeof(rect1)=16
*/

Sorry about that.

What you should be sorry for is making me decipher your examples rather than
just stating the obvious (which I think I "summed up" in a near previous
post in this thread (kind of))! :P ;)

John

[BobR]

JohnQ <jo***********************@yahoo.comwrote in message...

>
"BobR" <re***********@worldnet.att.netwrote in messaget...

struct Rect : RECT{
Rect( long x1 = 0, long y1 = 0, long x2 = 10, long y2 = 10 ){
left = x1; bottom = y1; right = x2; top = y2;}

How will the compiler be able to distinguish between using the default
constructor and the one above where you gave default values to all the
arguments? (This is a minor note that is off-topic for the thread).

The one above is the only constructor (once you declare/define one, the
compiler does not). It seconds as the default constructor (can be called
with no args).

};

{ // main() or ?
using std::cout // for NG post
Rect rect( 10, 12, 22, 42 );

Fine. Now how about:

Rect rect8(); // ambiguous

Declaration of function 'rect8' which takes no parameters, and returns an
'Rect'.
You meant:
Rect rect8; // default construct, like below (rect2)

Same with built-in types:
int number();
number = 43;
// error: assignment of function `int number()'
// error: cannot convert `int' to `int ()()' in assignment

int number2( 34 ); // or: int number2;
number2 = 43; // ok

>

RECT rect1( rect );

Can't do that because RECT has not constructor taking a Rect arg. Are you
suggesting that initializing a struct with a struct (from the RECT&

operator

of Rect) works? (My C-ismness, or forgetfulness thereof may be apparent).

Remember it's an POD, the compiler supplied copy-ctor is fine.
And destructor, assignment operator. As soon as you define one of the three,
you should supply all three.

>

RECT rect1a( Rect( 7, 14, 27, 34 ) );

Same question as above (and excuse me if I am at times unpedantic).

Same answer as above.

>

Rect rect2;
cout<<" Rect rect.bottom="<< rect.bottom <<'\n'
<<" RECT rect1.bottom="<< rect1.bottom <<'\n'
<<" RECT rect1a.bottom="<< rect1a.bottom <<'\n'
<<" Rect rect2.top="<< rect2.top <<'\n'
<<" sizeof(rect)="<<sizeof(rect)<<'\n'
<<" sizeof(rect1)="<<sizeof(rect1)<<std::endl;
}
/* - output -
Rect rect.bottom=12
RECT rect1.bottom=12
RECT rect1a.bottom=14
Rect rect2.top=10
sizeof(rect)=16
sizeof(rect1)=16
*/
Sorry about that.

What you should be sorry for is making me decipher your examples rather

than

just stating the obvious (which I think I "summed up" in a near previous
post in this thread (kind of))! :P ;)
John

"summed up", the answer is "no".

You seem reluctant to believe that POD struct/class have the guts supplied.
Try this:

#include <iostream>

struct Bint{ int x; }; // don't come much 'plainer'

int main(){
Bint bint1; // default construct
bint1.x = 3;
Bint bint2;
bint2 = bint1; // assignment
Bint bint3( bint1 ); // copy-ctor
std::cout<<"bint1.x="<<bint1.x<<'\n';
std::cout<<"bint2.x="<<bint2.x<<'\n';
std::cout<<"bint3.x="<<bint3.x<<'\n';
return 0;
}
/* -out-
bint1.x=3
bint2.x=3
bint3.x=3
*/

--
Bob R
POVrookie

[JohnQ]

"BobR" <re***********@worldnet.att.netwrote in message
news:E_*****************@bgtnsc05-news.ops.worldnet.att.net...

>
JohnQ <jo***********************@yahoo.comwrote in message...

>>
"BobR" <re***********@worldnet.att.netwrote in messaget...

>
struct Rect : RECT{
Rect( long x1 = 0, long y1 = 0, long x2 = 10, long y2 = 10 ){
left = x1; bottom = y1; right = x2; top = y2;}

How will the compiler be able to distinguish between using the default
constructor and the one above where you gave default values to all the
arguments? (This is a minor note that is off-topic for the thread).

The one above is the only constructor (once you declare/define one, the
compiler does not). It seconds as the default constructor (can be called
with no args).

A compiler won't generate a default constructor if any other constructor is
defined? That's news to me. And the constructor with args can serve as the
default constructor. News to me again.

>

};

{ // main() or ?
using std::cout // for NG post
Rect rect( 10, 12, 22, 42 );

Fine. Now how about:

Rect rect8(); // ambiguous

Declaration of function 'rect8' which takes no parameters, and returns an
'Rect'.
You meant:
Rect rect8; // default construct, like below (rect2)

Yes, I meant that.
I'll digest the rest of the post after the weekend. (Dang my head hurts.. I
better go get a glass of wine (aka, hair of the dog). ;) )

John

[BobR]

JohnQ <jo***********************@yahoo.comwrote in message...

>
I'll digest the rest of the post after the weekend. (Dang my head hurts..

I

better go get a glass of wine (aka, hair of the dog). ;) )
John

Remember, it's white wine with printed hard copy code(stains less), and red
wine with C++ (computer)(keep it away from keyboards. hard experience.).

--
Bob R
POVrookie

[James Kanze]

On Jul 26, 10:55 pm, Jerry Coffin <[e-mail]:

In article <f8acm5$[e-mail]>, [e-mail]
says...

[ ... ]

I guess that introducing such a requirement (to analyse the constructor
for containing constant expressions only, both in the initialiser list
and on the right-hand side of assignments in the body, and no side
effects in the body as well) would put an undue strain on the compiler
implementors.

I rather doubt it'd be much strain at all -- I'm pretty sure virtually
every reasonably self-respecting compiler's optimizer already detects
such things anyway.

It's a little bit tricker. Consider something like:

class Point {
public:
Point( int x, int y ) : myX( x ), myY( y ) {}
int myX ;
int myY ;
} ;
extern int f() ;
int i = f() ;
Point p( 2, 3 ) ;

int
f()
{
return p.myX ;
}

This code is guaranteed to initialize i with 0. If the compiler
converts the initialization of p to static initialization, it
most likely would initialize i with 2.

--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jul 27, 5:06 pm, "JohnQ" <[e-mail]>
wrote:

"Howard Hinnant" <[e-mail] in message

[...]

I have a question, based upon the link you gave. Wouldn't
it be easier to enforce structs to be PODs? That is, just
disallow anything in a struct that is a party spoiler in
regards to layout and size. In still other words, don't
allow structs to be classes and let the compiler warn when
an attempt is made to declare or derive or compose
illegally. As long as structs are allowed to evolve into
classes, a lot of programmer productivity goes out the
window.

I'd probably vote for that in a new language. But not in a
revision to C++. It would break too much code.

I seem to remember once seeing an explination by Stroustrup of
why he didn't do this. I've forgotten where, and all of the
details, but it did seem clear to me that the current situation
is the result of a careful and reasoned decision. One may not
agree with the decision (I'm not sure I do either), but there's
certainly nothing unreasonable about it; it's one of those cases
where there are arguments on both sides, and either choice is,
in some ways, right.

Well how about leaving 'struct' alone and defining a new keyword:
'PODStruct'? Then even "no padding or aligning allowed" could be also
included in the spec making for some nice IO scenarios. Slowly, 'struct'
would be deprecated.

You certainly don't want to ban padding. That would make C++
unacceptably slow on just about every modern machine.

And of course, the layout in a struct or a class in C++ has
absolutely nothing to do with IO, in any way, shape, form or
fashion.

--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jul 27, 2:49 pm, "Victor Bazarov" <[e-mail]:

JohnQ wrote:

"BobR" <[e-mail] in message
news:yG*****************@bgtnsc05-news.ops.worldnet.att.net...

[..]
struct MyRect : public virtual RECT{

[..]

~MyRect(){ this->RECT::~RECT();}

Ooo, that destructor doesn't look good at all there the way you
defined it. (Wouldn't be allowed in a POD either).

Actually, regardless of whether 'RECT' implements a d-tor or not,
this would actually give the code undefined behaviour. In any
situation the destructors of base class subobjects are called
right after the body of the destructor of this class, so here BobR
would actually cause the RECT d-tor to be called twice, which is
a VERY BAD THING(tm).

Except that in this case, we know that RECT has a trivial
destructor, so "calling" it has no effect.

--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[BobR]

JohnQ wrote in message...

>
"BobR" wrote in message...

struct Rect : RECT{
Rect( long x1 = 0, long y1 = 0, long x2 = 10, long y2 = 10 ){
left = x1; bottom = y1; right = x2; top = y2;}
};
[snip]

A compiler won't generate a default constructor if any other constructor

is

defined? That's news to me. And the constructor with args can serve as the
default constructor. News to me again.

struct MyRect2{ // test compiler supplied default Ctor
long x, y;
MyRect2( long x1, long y1 ): x(x1), y(y1){}
// MyRect2( long x1=0, long y1=0 ): x(x1), y(y1){} // no error
// (only (un-)comment one at a time)(or comment both to test)
};

MyRect2 Rect2;
// error: no matching function for call to `MyRect2::MyRect2()'
// error: candidates are: MyRect2::MyRect2(const MyRect2&)
// : MyRect2::MyRect2(long int, long int)

MyRect2 Rect2a(1,2); // ok (either Ctor shown )

So, that shows you that once *you* declare/define anything that can be taken
as a constructor, the compiler will *not* supply one.
Try it, experiment.

--
Bob R
POVrookie

[James Kanze]

On Jul 28, 9:11 am, "BobR" <[e-mail]:

JohnQ <[e-mail] in message...

"BobR" <[e-mail] in messaget...

struct Rect : RECT{
Rect( long x1 = 0, long y1 = 0, long x2 = 10, long y2 = 10){
left = x1; bottom = y1; right = x2; top = y2;}

How will the compiler be able to distinguish between using the default
constructor and the one above where you gave default values to all the
arguments? (This is a minor note that is off-topic for the thread).

The one above is the only constructor (once you declare/define one, the
compiler does not).

Not quite. There's also a compiler generated copy constructor.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[BobR]

James Kanze wrote in message...

/* """ quote
On Jul 28, 9:11 am, "BobR" wrote:

JohnQ wrote in message...

"BobR" <[e-mail] in messaget...

struct Rect : RECT{
Rect( long x1 = 0, long y1 = 0, long x2 = 10, long y2 = 10 ){
left = x1; bottom = y1; right = x2; top = y2;}

How will the compiler be able to distinguish between using the default
constructor and the one above where you gave default values to all the
arguments? (This is a minor note that is off-topic for the thread).

The one above is the only constructor (once you declare/define one, the
compiler does not).

Not quite. There's also a compiler generated copy constructor.
""" */

Thanks James. I posted late night, and started to re-post an addition, but,
was talking about constructors only. Copy-constructors are, to me, an
separate column. Like the old Chinese restaurant menu, one from column A,
one from column B, etc. (Ctor, CCtor, op=, Dtor). (what, two from column A?
that will be another $2.75! only one in col D, the Dessert-tor (when you
finish that, the meal is over.)).

Without an constructor, a copy-constructor seems pretty useless (how would
you get an instance to copy? <G>).

--
Bob R
POVrookie

[JohnQ]

"BobR" <re***********@worldnet.att.netwrote in message
news:E_*****************@bgtnsc05-news.ops.worldnet.att.net...

>
JohnQ <jo***********************@yahoo.comwrote in message...

>>
"BobR" <re***********@worldnet.att.netwrote in messaget...

You seem reluctant to believe that POD struct/class have the guts
supplied.

I don't use structs like that much (at all?). When I need that kind of
functionality, I think "class".

Try this:

I believe you.

John

[James Kanze]

On Jul 30, 6:21 pm, "BobR" <[e-mail]:

James Kanze wrote in message...

On Jul 28, 9:11 am, "BobR" wrote:

JohnQ wrote in message...
"BobR" <[e-mail] in messaget...
struct Rect : RECT{
Rect( long x1 = 0, long y1 = 0, long x2 = 10, long y2 = 10 ){
left = x1; bottom = y1; right = x2; top = y2;}
How will the compiler be able to distinguish between using the default
constructor and the one above where you gave default values to all the
arguments? (This is a minor note that is off-topic for the thread).
The one above is the only constructor (once you declare/define one, the
compiler does not).

Not quite. There's also a compiler generated copy constructor.

Thanks James. I posted late night, and started to re-post an
addition, but, was talking about constructors only.
Copy-constructors are, to me, an separate column.

I know what you mean. From a language point of view, it may
always be a constructor, but from a logical point of view, I,
too, tend to think of creating a new object as somehow different
from creating a copy. I even have a few special cases where I
keep count of the copies, and the "real" destruction---something
like freeing the resource in RAII---only takes place when the
last copy is destructed. (Boost::shared_ptr is a special case
of this particular idiom.)

Like the old Chinese restaurant menu, one from column A,
one from column B, etc. (Ctor, CCtor, op=, Dtor).

More likely, either everything from column B, or nothing:-).

(what, two from column A?
that will be another $2.75! only one in col D, the Dessert-tor (when you
finish that, the meal is over.)).

Without an constructor, a copy-constructor seems pretty
useless (how would you get an instance to copy? <G>).

Quite. If you have a user defined copy-constructor (which
inhibits the automatic generation of a default constructor),
you'd better have at least one other user defined constructor as
well.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Geo]

On 27 Jul, 16:06, "JohnQ" <[e-mail]:

"Howard Hinnant" <[e-mail] in message

news:ho**********************************@johnf2.b iosci.ohio-state.edu...

In article <UJhqi.24629$[e-mail] >,
"JohnQ" <[e-mail]:

Fwiw, a slight revision of
http://www.open-std.org/jtc1/sc22/wg.../n2294.htmlwas
voted into the C++0X working draft last week. This paper includes the
following rationale:

The proposed changes decompose the current POD requirements into
trivial
type
requirements and standard-layout type requirements, and remove the
dependency
on the definition of aggregates. Because these decomposed requirements
are
somewhat less restrictive than the requirements for aggregates, the
effect is
to make POD's more broadly useful and solve the problems identified in
the
Introduction and Motivating examples. It also opens up the possibility
of
designing useful classes that meet one or the other, but not both, of
the
new
trivial and standard-layout requirements.

Which sounds like I might get the guarantee I want someday. It also
implies
that I can do it now and chances are that it will work.

I have a question, based upon the link you gave. Wouldn't it be easier to
enforce structs to be PODs? That is, just disallow anything in a struct
that
is a party spoiler in regards to layout and size. In still other words,
don't allow structs to be classes and let the compiler warn when an
attempt
is made to declare or derive or compose illegally. As long as structs are
allowed to evolve into classes, a lot of programmer productivity goes out
the window.

I'd probably vote for that in a new language. But not in a revision to
C++. It would break too much code.

Well how about leaving 'struct' alone and defining a new keyword:
'PODStruct'? Then even "no padding or aligning allowed" could be also
included in the spec making for some nice IO scenarios. Slowly, 'struct'
would be deprecated.

John

'no padding or aligning allowed', would that be a requirement, if so
it ain't gonna be very portable !!!!

[JohnQ]

"Geo" <[e-mail] in message
news:11**********************@57g2000hsv.googlegro ups.com...

On 27 Jul, 16:06, "JohnQ" <[e-mail]:

>"Howard Hinnant" <[e-mail] in message

news:ho**********************************@johnf2. biosci.ohio-state.edu...

In article <UJhqi.24629$[e-mail] >,
"JohnQ" <[e-mail]:

Fwiw, a slight revision of
http://www.open-std.org/jtc1/sc22/wg.../n2294.htmlwas
voted into the C++0X working draft last week. This paper includes
the
following rationale:

>The proposed changes decompose the current POD requirements into
trivial
type
requirements and standard-layout type requirements, and remove the
dependency
on the definition of aggregates. Because these decomposed
requirements
are
somewhat less restrictive than the requirements for aggregates, the
effect is
to make POD's more broadly useful and solve the problems identified
in
the
Introduction and Motivating examples. It also opens up the
possibility
of
designing useful classes that meet one or the other, but not both,
of
the
new
trivial and standard-layout requirements.

>Which sounds like I might get the guarantee I want someday. It also
implies
that I can do it now and chances are that it will work.

>I have a question, based upon the link you gave. Wouldn't it be easier
to
enforce structs to be PODs? That is, just disallow anything in a
struct
that
is a party spoiler in regards to layout and size. In still other
words,
don't allow structs to be classes and let the compiler warn when an
attempt
is made to declare or derive or compose illegally. As long as structs
are
allowed to evolve into classes, a lot of programmer productivity goes
out
the window.

I'd probably vote for that in a new language. But not in a revision to
C++. It would break too much code.

Well how about leaving 'struct' alone and defining a new keyword:
'PODStruct'? Then even "no padding or aligning allowed" could be also
included in the spec making for some nice IO scenarios. Slowly, 'struct'
would be deprecated.

John

'no padding or aligning allowed', would that be a requirement, if so
it ain't gonna be very portable !!!!

It will be when hardware vendors get their acts together. Until then, I'll
just byte-align on WinTel and not worry about Sparcs and Crays. Anyways, if
you want to give the compiler free reign to do what it wants, use the
'class' keyword instead of PODStruct, as they are different animals for
different purposes (in the hypothetical scenario given).

John

[James Kanze]

On Aug 1, 1:29 am, "JohnQ" <[e-mail]>
wrote:

"Geo" <[e-mail] in message

[...]

'no padding or aligning allowed', would that be a
requirement, if so it ain't gonna be very portable !!!!

It will be when hardware vendors get their acts together.

They have their acts together. It's you that don't seem to
understand.

Until then, I'll just byte-align on WinTel

And pay an extremely high performance penalty for it. More than
a few applications can't afford that.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[JohnQ]

"James Kanze" <ja*********@gmail.comwrote in message
news:11*********************@d55g2000hsg.googlegro ups.com...
On Aug 1, 1:29 am, "JohnQ" <[e-mail]>
wrote:

"Geo" <[e-mail] in message

[...]

'no padding or aligning allowed', would that be a
requirement, if so it ain't gonna be very portable !!!!

It will be when hardware vendors get their acts together.

"They have their acts together. It's you that don't seem to
understand."

I won't be buying that Brooklyn bridge either, thank you.

Until then, I'll just byte-align on WinTel

"And pay an extremely high performance penalty for it."

You're assuming that byte-aligning struct members implies non-optimum
alignment. That's a wrong assumption. And perhaps you're thinking that
everything has to be byte-aligned or not, which isn't the case either.

"More than a few applications can't afford that."

There is no penalty if you define your stucts correctly so that the data
members align. Secondly, the vast majority of applications are not
performance constrained. Indeed, they are IO constrained if anything, so not
having to marshal will speed up the program (on the "native" platform).

John

[James Kanze]

On Aug 1, 12:58 pm, "JohnQ" <[e-mail]>
wrote:

"James Kanze" <[e-mail] in message
news:11*********************@d55g2000hsg.googlegro ups.com...
On Aug 1, 1:29 am, "JohnQ" <[e-mail]>
wrote:

"Geo" <[e-mail] in message

[...]

'no padding or aligning allowed', would that be a
requirement, if so it ain't gonna be very portable !!!!

It will be when hardware vendors get their acts together.

"They have their acts together. It's you that don't seem to
understand."

I won't be buying that Brooklyn bridge either, thank you.

You won't be writing any good software, either.

Until then, I'll just byte-align on WinTel

"And pay an extremely high performance penalty for it."

You're assuming that byte-aligning struct members implies non-optimum
alignment. That's a wrong assumption. And perhaps you're thinking that
everything has to be byte-aligned or not, which isn't the case either.

"More than a few applications can't afford that."

There is no penalty if you define your stucts correctly so that the data
members align.

Which, of course, depends on the machine.

Secondly, the vast majority of applications are not
performance constrained. Indeed, they are IO constrained if
anything, so not having to marshal will speed up the program
(on the "native" platform).

You always have to marshall. Objects aren't just arrays of
bytes, regardless of what you think.

(FWIW: our applications are very IO bound. That's why we use
Sparc's, and not PC's.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[JohnQ]

"James Kanze" <ja*********@gmail.comwrote in message
news:11**********************@22g2000hsm.googlegro ups.com...
On Aug 1, 12:58 pm, "JohnQ" <[e-mail]>
wrote:

"James Kanze" <[e-mail] in message
news:11*********************@d55g2000hsg.googlegro ups.com...
On Aug 1, 1:29 am, "JohnQ" <[e-mail]>
wrote:

"Geo" <[e-mail] in message

[...]

'no padding or aligning allowed', would that be a
requirement, if so it ain't gonna be very portable !!!!

It will be when hardware vendors get their acts together.

"They have their acts together. It's you that don't seem to
understand."

I won't be buying that Brooklyn bridge either, thank you.

"You won't be writing any good software, either."

More propoganda.

Until then, I'll just byte-align on WinTel

"And pay an extremely high performance penalty for it."

You're assuming that byte-aligning struct members implies non-optimum
alignment. That's a wrong assumption. And perhaps you're thinking that
everything has to be byte-aligned or not, which isn't the case either.

"More than a few applications can't afford that."

There is no penalty if you define your stucts correctly so that the data
members align.

"Which, of course, depends on the machine."

Designate one as primary.

Secondly, the vast majority of applications are not
performance constrained. Indeed, they are IO constrained if
anything, so not having to marshal will speed up the program
(on the "native" platform).

"You always have to marshall. Objects aren't just arrays of
bytes, regardless of what you think."

"Objects" has too much connotation. You can make something that is "just an
array of bytes". Indeed, that is fundamental and any language that doesn't
facilitate that is defficient (or trying to sell compilers).

John

[James Kanze]

On Aug 2, 8:21 pm, "JohnQ" <[e-mail]>
wrote:

"James Kanze" <[e-mail] in message

news:11**********************@22g2000hsm.googlegro ups.com...
On Aug 1, 12:58 pm, "JohnQ" <[e-mail]>
wrote:

"James Kanze" <[e-mail] in message
>news:11*********************@d55g2000hsg.googlegr oups.com...
On Aug 1, 1:29 am, "JohnQ" <[e-mail]>
wrote:
"Geo" <[e-mail] in message
[...]
'no padding or aligning allowed', would that be a
requirement, if so it ain't gonna be very portable !!!!
It will be when hardware vendors get their acts together.
"They have their acts together. It's you that don't seem to
understand."
I won't be buying that Brooklyn bridge either, thank you.

"You won't be writing any good software, either."

More propoganda.

More reality. I've been at this business long enough to
recognize incompetence when I see it. If you don't understand
the necessity of marshalling, or of different processor
architectures, you're never going to write any quality software.

Until then, I'll just byte-align on WinTel
"And pay an extremely high performance penalty for it."
You're assuming that byte-aligning struct members implies non-optimum
alignment. That's a wrong assumption. And perhaps you're thinking that
everything has to be byte-aligned or not, which isn't the case either.
"More than a few applications can't afford that."
There is no penalty if you define your stucts correctly so that the data
members align.

Which, of course, depends on the machine.

Designate one as primary.

Primary what? Different people have different requirements, so
there are different architectures out there to solve them. I
work mainly on large scale servers, and I certainly don't want
to be forced to use an ARM architecture, just because it's the
most widespread. (I don't even really know the ARM
architecture, so little is it relevant to my field of work,
where Sparc is by far the dominant architecture.)

Secondly, the vast majority of applications are not
performance constrained. Indeed, they are IO constrained if
anything, so not having to marshal will speed up the program
(on the "native" platform).

You always have to marshall. Objects aren't just arrays of
bytes, regardless of what you think.

"Objects" has too much connotation. You can make something
that is "just an array of bytes".

Not really. Not anything very useful, anyway.

Indeed, that is fundamental and any language that doesn't
facilitate that is defficient (or trying to sell compilers).

Or trying to support users who are writing real applications,
and need to manage complexity.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[JohnQ]

"James Kanze" <ja*********@gmail.comwrote in message
news:11**********************@22g2000hsm.googlegro ups.com...
On Aug 2, 8:21 pm, "JohnQ" <[e-mail]>
wrote:

"James Kanze" <[e-mail] in message

news:11**********************@22g2000hsm.googlegro ups.com...
On Aug 1, 12:58 pm, "JohnQ" <[e-mail]>
wrote:

"James Kanze" <[e-mail] in message
>news:11*********************@d55g2000hsg.googlegr oups.com...
On Aug 1, 1:29 am, "JohnQ" <[e-mail]>
wrote:
"Geo" <[e-mail] in message
[...]
'no padding or aligning allowed', would that be a
requirement, if so it ain't gonna be very portable !!!!
It will be when hardware vendors get their acts together.
"They have their acts together. It's you that don't seem to
understand."
I won't be buying that Brooklyn bridge either, thank you.

"You won't be writing any good software, either."

More propoganda.

"More reality. I've been at this business long enough to
recognize incompetence when I see it. If you don't understand
the necessity of marshalling, or of different processor
architectures, you're never going to write any quality software."

You're marshalling everywhere, all the time and calling me stupid? Have you
considered getting some bran in your diet? Maybe you wouldn't be so ornery
then. :P

Until then, I'll just byte-align on WinTel
"And pay an extremely high performance penalty for it."
You're assuming that byte-aligning struct members implies non-optimum
alignment. That's a wrong assumption. And perhaps you're thinking that
everything has to be byte-aligned or not, which isn't the case either.
"More than a few applications can't afford that."
There is no penalty if you define your stucts correctly so that the
data
members align.

Which, of course, depends on the machine.

Designate one as primary.

"Primary what? Different people have different requirements, so
there are different architectures out there to solve them. I
work mainly on large scale servers, and I certainly don't want
to be forced to use an ARM architecture, just because it's the
most widespread. (I don't even really know the ARM
architecture, so little is it relevant to my field of work,
where Sparc is by far the dominant architecture.)"

Nevermind, you don't get it.

Secondly, the vast majority of applications are not
performance constrained. Indeed, they are IO constrained if
anything, so not having to marshal will speed up the program
(on the "native" platform).

You always have to marshall. Objects aren't just arrays of
bytes, regardless of what you think.

"Objects" has too much connotation. You can make something
that is "just an array of bytes".

"Not really. Not anything very useful, anyway."

You fo right ahead and keep maintaining the complexity. That's your
perogative.

Indeed, that is fundamental and any language that doesn't
facilitate that is defficient (or trying to sell compilers).

"Or trying to support users who are writing real applications,
and need to manage complexity."

Broken record.

John