C++ vs. C#

[tonytech08]

You have the problem of standardizing hardware that was already
designed before your programming language. Some of these "odder"
platforms are really important, like this one:

http://www-03.ibm.com/systems/z/

Do you think they will abandon 40+ years of backward compatibility to
support a new programming language? That's one reason why C++ says
that some operations depend on the underlying hardware.

I think in terms of "a new language going forward" rather than
backward compatibility. C++ can maintain the old platforms then. It
can be like reproduction vintage parts manufacturing for vintage cars.
Yes, that suggests that some platforms will be relegated to the
"muscle car enthusiast" crowd and museums.

Because the hardware was there already. If you want the language
implementable on the widest range of platforms, you have to allow for
some variations of the hardware.

There is a tradeoff: the more "general purpose" a language is, the
more unwieldly it is to use.

Besides, as long as you stay within your own platform, the struct
layout doesn't have to be portable, just consistent.

That's what I'm currently relying on: a narrowly-defined deployment
platform. But I shouldn't have to rely on that to the degree that I
have to. Losing "guarantees" (say with layout of a struct within
memory) within a given platform is real bitch though.

 

[SG]

I use that terminology pretty much like it is used in the C# reference
documentation (but I have expounded on the concepts here in another
thread(s) recently).

JK and I went round-and-round on this topic in another thread recently
so review that first.

I read it but the only thing that stuck was the unfavourable
impression you gave. So, I checked it again and what I found was

lightweight = POD
heavyweight = non-POD

which is kind of silly. Why would you invent another terminology for
the same thing? We have PODs and non-PODs. The latter category can be
split further into non-polymorphic and polymorphic.

What is remaining is the "layout issue". What are the compelling
reasons for standardizing struct layouts again? The only situation
where this may seem to be of use is I/O. How far do you want this to
be restricted? Do you want to force all implementations to use a
certain kind of padding and/or endianness? What's your proposal?

Cheers!
SG

 

[tonytech08]

I read it but the only thing that stuck was the unfavourable
impression you gave.

About what?

So, I checked it again and what I found was

  lightweight = POD
  heavyweight = non-POD

which is kind of silly.

Well you didn't think about it enough. POD is what you are limited to
for the concept of "lightweight object" in C++. NOT the other way
around.


[snipped erroneous conclusion based upon erroneous assumption]

What is remaining is the "layout issue".  What are the compelling
reasons for standardizing struct layouts again?  

I won't reiterate those here again. (But I'm not claiming to have been
thorough in doing that in previous threads).

The only situation
where this may seem to be of use is I/O.  How far do you want this to
be restricted?  Do you want to force all implementations to use a
certain kind of padding and/or endianness?  What's your proposal?

Proposal? At this juncture, I feel I'm getting around the issue with C+
+ just fine (ignorance is bliss? time will tell!). Further out, I hope
to use or develop a language that works like I want it to (emphasizes
features that are important to me). I PAY/PAID for R&D. I may
investigate R&D grants in the future, but right now I still think I
can sustain incrementally by delivering software product soon. (Ha!).
(The "joke" is: I said that 10+ years ago too).

 

[SG]

About what?

About your understanding of things.

So, I checked it again and what I found was

  lightweight = POD
  heavyweight = non-POD

which is kind of silly.

Well you didn't think about it enough. POD is what you are limited to
for the concept of "lightweight object" in C++. NOT the other way
around.

[snipped erroneous conclusion based upon erroneous assumption]

I obviously don't know what you are talking about and I'm guessing I'm
not the only one. So in case you want this thread to have any
responses that are worth reading you might want to reconsider
explaining yourself (w.r.t. lightweight concept) "again" or at least
point to some resource containing the definitions you use.

I won't reiterate those here again. (But I'm not claiming to have been
thorough in doing that in previous threads).
Ok.


Proposal? At this juncture, I feel I'm getting around the issue with C+
+ just fine (ignorance is bliss? time will tell!). Further out, I hope
to use or develop a language that works like I want it to (emphasizes
features that are important to me). I PAY/PAID for R&D. I may
investigate R&D grants in the future, but right now I still think I
can sustain incrementally by delivering software product soon. (Ha!).
(The "joke" is: I said that 10+ years ago too).

Good luck with that.

Cheers!
SG

 

[tonytech08]

About what?

About your understanding of things.

Well you didn't think about it enough. POD is what you are limited to
for the concept of "lightweight object" in C++. NOT the other way
around.

[snipped erroneous conclusion based upon erroneous assumption]

I obviously don't know what you are talking about and I'm guessing I'm
not the only one. So in case you want this thread to have any
responses that are worth reading you might want to reconsider
explaining yourself (w.r.t. lightweight concept) "again" or at least
point to some resource containing the definitions you use.

At this point, after having read up on C#'s usage of the terminology,
I'll refer the reader there. While it's not necessarily my take or
whole take on the concept, it should suffice to introduce the
unitiated. Look at the C# documentation for the definition that MS
gives to 'struct', 'class' and note the use of the term 'lightweight'.
Also, then do a search within that documentation for facilities that
give the developer strict control over the layout of fields within
structs/lightweight classes.

 

[red floyd]

At this point, after having read up on C#'s usage of the terminology,
I'll refer the reader there. While it's not necessarily my take or
whole take on the concept, it should suffice to introduce the
unitiated. Look at the C# documentation for the definition that MS
gives to 'struct', 'class' and note the use of the term 'lightweight'.
Also, then do a search within that documentation for facilities that
give the developer strict control over the layout of fields within
structs/lightweight classes.

Actually, no. You're the guy making the claims. Summarize the
description here. *CLEARLY*.

 

[SG]

At this point, after having read up on C#'s usage of the terminology,
I'll refer the reader there. While it's not necessarily my take or
whole take on the concept, it should suffice to introduce the
unitiated. Look at the C# documentation for the definition that MS
gives to 'struct', 'class' and note the use of the term 'lightweight'.

You have to do better than saying "look up the C# documentation". I
didn't find any definition of "lightweight". But the way this word is
used suggests that Microsoft likes to call value types "lightweight":

"The struct type is suitable for representing lightweight objects
such as Point, Rectangle, and Color. Although it is possible to
represent a point as a class, a struct is more efficient in some
scenarios. For example, if you declare an array of 1000 Point
objects, you will allocate additional memory for referencing each
object. In this case, the struct is less expensive."

"In C#, a struct is like a lightweight class; it is a stack-
allocated type that can implement interfaces but does not support
inheritance."

In case you havn't noticed in C++ neither structs nor classes define
types that behave like references and thus would qualify as being
lightweight.

Also, then do a search within that documentation for facilities that
give the developer strict control over the layout of fields within
structs/lightweight classes.

Can you provide more specific pointers? BTW: What do you care about
the layout of fields? C# (at first glance) doesn't support accessing
the raw data of objects. So there's no way to tell how the fields are
laid out in memory, is there?


Cheers!
SG

 

[SG]

You have to do better than saying "look up the C# documentation".  I
didn't find any definition of "lightweight".  But the way this word is
used suggests that Microsoft likes to call value types "lightweight":

  "The struct type is suitable for representing lightweight objects
   such as Point, Rectangle, and Color. Although it is possible to
   represent a point as a class, a struct is more efficient in some
   scenarios. For example, if you declare an array of 1000 Point
   objects, you will allocate additional memory for referencing each
   object. In this case, the struct is less expensive."

  "In C#, a struct is like a lightweight class; it is a stack-
   allocated type that can implement interfaces but does not support
   inheritance."

After reading it again I think "lightweight" just seems to refer to
"small" objects that can be easily copied without too much runtime
overhead. There is no clear definition of "lightweight" just as there
is no one for "small" or "too much runtime overhead". Vague terms. Of
course it makes sense to have value semantics for many "lightweight
objects". That use of the word lightweight would render reference
counting smart pointers as "lightweight objects" for example -- even
though they are non-PODs and regardlessly of such an objects lives in
the free store or is an automatic variable.

Cheers!
SG

 

[tonytech08]

Actually, no.  

'no' what?

You're the guy making the claims.  

Oh? What claims am I making?

Summarize the
description here.  *CLEARLY*.

Funny guy.

 

[tonytech08]

You have to do better than saying "look up the C# documentation".

You're wrong: I don't HAVE to do anything.

 I
didn't find any definition of "lightweight".  But the way this word is
used suggests that Microsoft likes to call value types "lightweight":

  "The struct type is suitable for representing lightweight objects
   such as Point, Rectangle, and Color. Although it is possible to
   represent a point as a class, a struct is more efficient in some
   scenarios. For example, if you declare an array of 1000 Point
   objects, you will allocate additional memory for referencing each
   object. In this case, the struct is less expensive."

  "In C#, a struct is like a lightweight class; it is a stack-
   allocated type that can implement interfaces but does not support
   inheritance."

Yeah, you're on the correct pages on the MS site. That's what I was
reading a few days ago also. Again, the documentation is just AKIN to
what I was alluding to as being relevant and important going forward.
(I'm not gonna spoon feed anyone).

In case you havn't noticed in C++ neither structs nor classes define
types that behave like references and thus would qualify as being
lightweight.

You're free to make your own definition of "lightweight" if you choose
to. The above that you wrote does not match mine.

Can you provide more specific pointers?

Probably... hang on...  Here's a good jumping off point:
http://msdn.microsoft.com/en-us/library/aa288471(VS.71).aspx. It's the
tutorial on C# structs. Note the "StructLayoutAttribute Class" under
"Further Reading". I'm not promoting that as a suggested
implementation, but rather pointing out that layout control is
important sometimes and that C# recognizes (and is able to "exploit"
it) that also.

BTW: What do you care about
the layout of fields?  C# (at first glance) doesn't support accessing
the raw data of objects.  So there's no way to tell how the fields are
laid out in memory, is there?

It wouldn't make much sense to have a thing like StructLayoutAttribute
Class then would it?

 

[tonytech08]

After reading it again I think "lightweight" just seems to refer to
"small" objects that can be easily copied without too much runtime
overhead.  There is no clear definition of "lightweight" just as there
is no one for "small" or "too much runtime overhead". Vague terms.  Of
course it makes sense to have value semantics for many "lightweight
objects".  That use of the word lightweight would render reference
counting smart pointers as "lightweight objects" for example -- even
though they are non-PODs and regardlessly of such an objects lives in
the free store or is an automatic variable.

The "definition" as used there is gotten from the usage of the term in
the context given. (And the surrounding concepts and issues have
probably not yet evolved or surfaced there yet (?)). I don't think
they were focusing on the time concerns exclusively (did they?)
because that really is not "the issue". It's kind of a delicate
situation because sometimes (many times) both time and space issues
exist.

 

[James Kanze]

You have to do better than saying "look up the C#
documentation". I didn't find any definition of
"lightweight". But the way this word is used suggests that
Microsoft likes to call value types "lightweight":

Unlike C++, C# very definitely divides what C++ calls "class
types" into three categories: structs, which have value
semantics and a language defined copy assignment operator,
classes, which have reference semantics and do not support
assignment, and interfaces, which can only be used as a base
class for one of the other two. All three categories are easily
emulated in C++, and a typical application will use all
three---what C# calls are more often called entity types.

At one point, James Gosling had a proposal for something similar
for Java.

Of course, because C++ leaves such definition of categories up
to the user, you get far more possibilities, when you need them:
C# doesn't support things like mixins, nor POD's nor, say, an on
stack object which implements the template method pattern.

"The struct type is suitable for representing lightweight objects
such as Point, Rectangle, and Color. Although it is possible to
represent a point as a class, a struct is more efficient in some
scenarios. For example, if you declare an array of 1000 Point
objects, you will allocate additional memory for referencing each
object. In this case, the struct is less expensive."

"In C#, a struct is like a lightweight class; it is a stack-
allocated type that can implement interfaces but does not support
inheritance."

In case you havn't noticed in C++ neither structs nor classes
define types that behave like references and thus would
qualify as being lightweight.

More or less. The categorical distinctions of C# don't really
apply to C++, since in C++, the programmer can more or less do
whatever he wants.

Can you provide more specific pointers? BTW: What do you care
about the layout of fields? C# (at first glance) doesn't
support accessing the raw data of objects. So there's no way
to tell how the fields are laid out in memory, is there?

No. The layout of fields is totally irrelevant. This is just
the usual troll.

 

[James Kanze]

Yeah, you're on the correct pages on the MS site. That's what
I was reading a few days ago also. Again, the documentation is
just AKIN to what I was alluding to as being relevant and
important going forward. (I'm not gonna spoon feed anyone).

You mean that you're not going to let anyone know what you mean.

You're free to make your own definition of "lightweight" if
you choose to. The above that you wrote does not match mine.

So what is yours. You refuse to tell us (or you're incapable of
telling us).

Probably... hang on... Here's a good jumping off point:http://msdn.microsoft.com/en-us/library/aa288471(VS.71).aspx. It's the
tutorial on C# structs. Note the "StructLayoutAttribute Class" under
"Further Reading". I'm not promoting that as a suggested
implementation, but rather pointing out that layout control is
important sometimes and that C# recognizes (and is able to "exploit"
it) that also.

C# allows explicit user defined layout. I'm not sure what the
consequences are, however (except when used to simulate a
union---and it's a very awkward way of simulating a union). The
results certainly can't be portable; I suspect that the intent
is only to be able to force compatibility with some legacy
interface on a specific system.

 

[James Kanze]

Probably... hang on... Here's a good jumping off point:http://msdn.microsoft.com/en-us/library/aa288471(VS.71).aspx. It's the
tutorial on C# structs. Note the "StructLayoutAttribute Class" under
"Further Reading". I'm not promoting that as a suggested
implementation, but rather pointing out that layout control is
important sometimes and that C# recognizes (and is able to "exploit"
it) that also.

Note that this is a extension, and not part of the standard
language. And that according to the specification, "The
attribute has no affect on the managed layout of the members of
the type." Whatever that means? Beyond that, I've not found
enough documentation to know what it really does.

It wouldn't make much sense to have a thing like StructLayoutAttribute
Class then would it?

They aren't part of the language, but an extension for the .NET
environment.

 

[James Kanze]

Probably... hang on... Here's a good jumping off point:http://msdn.microsoft.com/en-us/library/aa288471(VS.71).aspx. It's the
tutorial on C# structs. Note the "StructLayoutAttribute Class" under
"Further Reading". I'm not promoting that as a suggested
implementation, but rather pointing out that layout control is
important sometimes and that C# recognizes (and is able to "exploit"
it) that also.

Note that this is a extension, and not part of the standard
language. And that according to the specification, "The
attribute has no affect on the managed layout of the members of
the type." Whatever that means? Beyond that, I've not found
enough documentation to know what it really does.

It wouldn't make much sense to have a thing like StructLayoutAttribute
Class then would it?

They aren't part of the language, but an extension for the .NET
environment.

 

[SG]

You're wrong: I don't HAVE to do anything.

Well, provided that you want to discuss this further, of course.
Expecting people to find the information themselves (which i tried) is
counter productive. Clearly, you want to discuss something.
Otherwise you wouldn't have started this thread.

Yeah, you're on the correct pages on the MS site. That's what I was
reading a few days ago also. Again, the documentation is just AKIN to
what I was alluding to as being relevant and important going forward.
(I'm not gonna spoon feed anyone).

Unless you point me to a definition of "lightweight" I will stick to
my interpretation. My interpretation of "lightweight" is that as far
as the C# languages is concerned there is no distinction between
"lightweight" and "heavyweight" in terms of syntax or semantics.
"Weight" is a non-binary vaguely defined property.

Probably... hang on...  Here's a good jumping off point:
http://msdn.microsoft.com/en-us/library/aa288471(VS.71).aspx.
It's the tutorial on C# structs. Note the "StructLayoutAttribute
Class" under "Further Reading". I'm not promoting that as a suggested
implementation, but rather pointing out that layout control is
important sometimes and that C# recognizes (and is able to "exploit"
it) that also.

It supposedly serves two purposes:
- emulating C/C++ unions
- interfacing with native code

(Note: These are things C++ is already good at.)

Unfortunately you have to make assumptions about the underlying
architecture. If you want to call some native library function
(written in plain C) you have to make sure that the explicit layout
matches the layout of the C struct which is implementation-defined.
On different hardware platforms you might have to use different
explicit layouts (or even different types) to make it work.
Interfacing with native code requires more attention in C# than you
need in C++ because .NET is its own platform.

Cheers!
SG

 

[SG]

More or less.  The categorical distinctions of C# don't really
apply to C++, since in C++, the programmer can more or less do
whatever he wants.

Always nitpicking. Let me rephrase:
"In C++ neither structs nor classes define types that behave like
references
UNLESS the programmer explicitly designs them to do so logically.
Still, they are "value types" in C# terminology."

Cheers!
SG

 

[James Kanze]

Always nitpicking. Let me rephrase:
"In C++ neither structs nor classes define types that behave
like references UNLESS the programmer explicitly designs them
to do so logically. Still, they are "value types" in C#
terminology."

It's not really nitpicking this time. C++ and C# have radically
different object models, and trying apply the languages
supported distinctions made by C# to C++ doesn't apply. The
important point (which I do think you made), of course, is that
for all of the categories in C#, you can effectively do the same
thing with a class type in C++; C# doesn't support anything that
C++ doesn't.

 

[tonytech08]

You mean that you're not going to let anyone know what you mean.

Given the responses in this and other threads of similar nature, I'll
just hold on to the concepts as trade secrets.

So what is yours.  You refuse to tell us (or you're incapable of
telling us).

If everyone wasn't so (seemingly?) perplexed by it I might explain
further, but as it stands, I'd feel abused to, as it seems to be much
more esoteric than I thought. I'll continue to recognize the
differences between lightweight and heavyweight "classes" and even
evolve the distinction, but I won't be doing that here in public
forum. If someone prefers to recognize just one type of class, or a
diversity and voluminous amount of class "types" to where none "stick
out", rather than two with distinct applicability that fundamentally
partition the language's canvas of class design machinery, that's fine
with me. YMMV.

 

[tonytech08]

C# allows explicit user defined layout.  I'm not sure what the
consequences are, however (except when used to simulate a
union---and it's a very awkward way of simulating a union).  The
results certainly can't be portable; I suspect that the intent
is only to be able to force compatibility with some legacy
interface on a specific system.

The emulation of a union example they gave (at
http://msdn.microsoft.com/en-us/library/aa288471(VS.71).aspx) was just
that: an (one) example that showed that layout can be controlled and
how.