C++ vs. C#
tonytech08
model. All that remains in my mind about that thread is: "why would
you want to do that?", and "it's not portable" and probably other
irrelevancy (read, no real answers). I spoke of "Lightweight" vs.
"Heavyweight" objects. And of "representation in memory of an object"
as important.
Well guess what? I stumbled upon some C# description pages of structs,
classes and the like. Guess what? What seems to be in this NG as
"don't do that" and "non-portable", a multi-billion dollar company is
implementing their language in seeming lockstep to my preponderances
here.
Look it up: C# recognizes "lightweight" classes (structs) as relevant.
C# recognizes struct layout as relevant.
I'm not saying "I told you so". I'm also not saying C# is the way to
go. Just like where I began, searching for that simply elegant
language that C++ is not. I hope for something better (I'd do it
myself if I was young).
alfps
C# is a great language for its purpose. It's the Turbo Pascal of our
times. Incidentally with the same main creator.
C++ serves different purposes.
I don't understand what you're talking about wrt. light-weight missing
in C++, because in terms of memory usage or overhead you can't get
more light-weight. I think what you're writing must be due to
confusion. And I'm sure that if you simply ask about how to do X or Y
in C++ you'll get better answers than "don't do that". :-)
Cheers & hth.,
- Alf
red floyd
> Look it up: C# recognizes "lightweight" classes (structs) as relevant.
> C# recognizes struct layout as relevant.
>
And so does C++. If you have a POD struct, the layout is relevant.
Ian Collins
> Very recently, I started a thread enquiring about the C++ object
> model. All that remains in my mind about that thread is: "why would
> you want to do that?", and "it's not portable" and probably other
> irrelevancy (read, no real answers). I spoke of "Lightweight" vs.
> "Heavyweight" objects. And of "representation in memory of an object"
> as important.
>
> Look it up: C# recognizes "lightweight" classes (structs) as relevant.
> C# recognizes struct layout as relevant.
>
So does C++, I couldn't write most of my code if it didn't.
> I'm not saying "I told you so". I'm also not saying C# is the way to
> go. Just like where I began, searching for that simply elegant
> language that C++ is not. I hope for something better (I'd do it
> myself if I was young).
So it runs on all of my embedded and non-windows targets, does it?
I can't see where using C# (about as non-portable as one can get)
differs from using platform specific features in C++.
--
Ian Collins
Bo Persson
> Very recently, I started a thread enquiring about the C++ object
> model. All that remains in my mind about that thread is: "why would
> you want to do that?", and "it's not portable" and probably other
> irrelevancy (read, no real answers). I spoke of "Lightweight" vs.
> "Heavyweight" objects. And of "representation in memory of an
> object" as important.
>
> Well guess what? I stumbled upon some C# description pages of
> structs, classes and the like. Guess what? What seems to be in this
> NG as "don't do that" and "non-portable", a multi-billion dollar
> company is implementing their language in seeming lockstep to my
> preponderances here.
C# is only "portable" to the .NET platform, so it is easy to document
the "representation in memory", as there is only one.
One goal for the C++ language is to be efficiently implementable on a
wide range on systems. This is, in part, achieved by not specifying
the exact size of an int, or the binary format of a float, or the
exact layout of a class.
>
> Look it up: C# recognizes "lightweight" classes (structs) as
> relevant. C# recognizes struct layout as relevant.
C# can prescribe the struct layout, as there is only one choice. :-)
>
> I'm not saying "I told you so". I'm also not saying C# is the way to
> go. Just like where I began, searching for that simply elegant
> language that C++ is not. I hope for something better (I'd do it
> myself if I was young).
No language is the best for all purposes.
Bo Persson
tonytech08
> On 19 Des, 06:06, tonytech08 <tonytec...@gmail.com> wrote:
>
>
>
>
>
> > Very recently, I started a thread enquiring about the C++ object
> > model. All that remains in my mind about that thread is: "why would
> > you want to do that?", and "it's not portable" and probably other
> > irrelevancy (read, no real answers). I spoke of "Lightweight" vs.
> > "Heavyweight" objects. And of "representation in memory of an object"
> > as important.
>
> > Well guess what? I stumbled upon some C# description pages of structs,
> > classes and the like. Guess what? What seems to be in this NG as
> > "don't do that" and "non-portable", a multi-billion dollar company is
> > implementing their language in seeming lockstep to my preponderances
> > here.
>
> > Look it up: C# recognizes "lightweight" classes (structs) as relevant.
> > C# recognizes struct layout as relevant.
>
> > I'm not saying "I told you so". I'm also not saying C# is the way to
> > go. Just like where I began, searching for that simply elegant
> > language that C++ is not. I hope for something better (I'd do it
> > myself if I was young).
>
> C# is a great language for its purpose. It's the Turbo Pascal of our
> times. Incidentally with the same main creator.
I equate C# to be like Java. And Turbo Pascal was Borland's thing
(still is).
>
> C++ serves different purposes.
But perhaps the features of the higher level C# under the microscope
herein are detrimentally ignored in C++.
>
> I don't understand what you're talking about wrt. light-weight missing
> in C++, because in terms of memory usage or overhead you can't get
> more light-weight.
C# distinguishes between structs ("Lightweight classes") and classes
whereas C++ does not.
> I think what you're writing must be due to
> confusion.
Not at all (not mine at least, that is). See D&E for the reasoning
behind NOT distinguishing between structs and classes and see the
reference manual for C# for their take on structs, classes and
"lightweight objects" (and object field layout control also).
> And I'm sure that if you simply ask about how to do X or Y
> in C++ you'll get better answers than "don't do that". :-)
All questions are not simple or simple to answer.
tonytech08
You quoted 2 lines and only responded to one of them. C++ does not
recognize any sort of "lightweight class" concept. And the layout
control is non-existent whereas in C# it is formally defined.
tonytech08
> tonytech08 wrote:
> > Very recently, I started a thread enquiring about the C++ object
> > model. All that remains in my mind about that thread is: "why would
> > you want to do that?", and "it's not portable" and probably other
> > irrelevancy (read, no real answers). I spoke of "Lightweight" vs.
> > "Heavyweight" objects. And of "representation in memory of an object"
> > as important.
>
> It's very important for us embedded and driver writers.
I think it is important at a higher level also.
>
> > Look it up: C# recognizes "lightweight" classes (structs) as relevant.
> > C# recognizes struct layout as relevant.
>
> So does C++, I couldn't write most of my code if it didn't.
Again, addressing only the second line of a 2 line quote (?). See my
response to red floyd above.
>
> > I'm not saying "I told you so". I'm also not saying C# is the way to
> > go. Just like where I began, searching for that simply elegant
> > language that C++ is not. I hope for something better (I'd do it
> > myself if I was young).
>
> So it runs on all of my embedded and non-windows targets, does it?
I was promoting the use of C#, I was just noting that that language is
addressing issues I have with C++ at the feature level. I still
consider C# as "Microsoft Java".
>
> I can't see where using C# (about as non-portable as one can get)
> differs from using platform specific features in C++.
Again, I'm not suggesting C# and C++ are in the same category (I
shouldn't have left out the fact that I view C# as "a Java killer
wannabe" in my original post).
tonytech08
> tonytech08 wrote:
> > Very recently, I started a thread enquiring about the C++ object
> > model. All that remains in my mind about that thread is: "why would
> > you want to do that?", and "it's not portable" and probably other
> > irrelevancy (read, no real answers). I spoke of "Lightweight" vs.
> > "Heavyweight" objects. And of "representation in memory of an
> > object" as important.
>
> > Well guess what? I stumbled upon some C# description pages of
> > structs, classes and the like. Guess what? What seems to be in this
> > NG as "don't do that" and "non-portable", a multi-billion dollar
> > company is implementing their language in seeming lockstep to my
> > preponderances here.
>
> C# is only "portable" to the .NET platform, so it is easy to document
> the "representation in memory", as there is only one.
I think that level of guarantee should be a goal of some sort (whether
that means less widely defined programming languages or more
standardization of hardware). It may be idealistic, but maybe not.
>
> One goal for the C++ language is to be efficiently implementable on a
> wide range on systems.
Understood: it bows to every whim of hardware engineers and to non-
standardization of hardware.
> This is, in part, achieved by not specifying
> the exact size of an int, or the binary format of a float, or the
> exact layout of a class.
I'm suggesting that is a problem to be solved.
> > Look it up: C# recognizes "lightweight" classes (structs) as
> > relevant. C# recognizes struct layout as relevant.
>
> C# can prescribe the struct layout, as there is only one choice. :-)
What about the "lightweight class" concept though? Address that.
>
> > I'm not saying "I told you so". I'm also not saying C# is the way to
> > go. Just like where I began, searching for that simply elegant
> > language that C++ is not. I hope for something better (I'd do it
> > myself if I was young).
>
> No language is the best for all purposes.
Not yet. Or, at least, that state of language technology could be much
better than it currently is.
Ian Collins
> On Dec 19, 1:42 am, Ian Collins <ian-n...@hotmail.com> wrote:
>> tonytech08 wrote:
>>> Very recently, I started a thread enquiring about the C++ object
>>> model. All that remains in my mind about that thread is: "why would
>>> you want to do that?", and "it's not portable" and probably other
>>> irrelevancy (read, no real answers). I spoke of "Lightweight" vs.
>>> "Heavyweight" objects. And of "representation in memory of an object"
>>> as important.
>> It's very important for us embedded and driver writers.
>
> I think it is important at a higher level also.
>
>>> Look it up: C# recognizes "lightweight" classes (structs) as relevant.
>>> C# recognizes struct layout as relevant.
>> So does C++, I couldn't write most of my code if it didn't.
>
> Again, addressing only the second line of a 2 line quote (?). See my
> response to red floyd above.
>
So? C++ recognises portability as relevant.
A POD struct in C++ is no different from a C struct and you can't get
much more lightweight than that.
>> I can't see where using C# (about as non-portable as one can get)
>> differs from using platform specific features in C++.
>
> Again, I'm not suggesting C# and C++ are in the same category (I
> shouldn't have left out the fact that I view C# as "a Java killer
> wannabe" in my original post).
>
Then what are you suggesting? If you want to get closer to an apples to
apples comparison, you have to consider all the platform specific
options offered by C++ compilers.
--
Ian Collins
Ian Collins
> On Dec 19, 12:07 pm, "Bo Persson" <b...@gmb.dk> wrote:
>
>> One goal for the C++ language is to be efficiently implementable on a
>> wide range on systems.
>
> Understood: it bows to every whim of hardware engineers and to non-
> standardization of hardware.
>
requirements have different solutions. Do you want a 125W quad core
monster in your toaster?
>> This is, in part, achieved by not specifying
>> the exact size of an int, or the binary format of a float, or the
>> exact layout of a class.
>
> I'm suggesting that is a problem to be solved.
No it isn't. What use is a 64 bit int on an 8 bit PIC?
C++ is a general purpose programming language, C# isn't.
--
Ian Collins
tonytech08
> tonytech08 wrote:
> > On Dec 19, 1:42 am, Ian Collins <ian-n...@hotmail.com> wrote:
> >> tonytech08 wrote:
> >>> Very recently, I started a thread enquiring about the C++ object
> >>> model. All that remains in my mind about that thread is: "why would
> >>> you want to do that?", and "it's not portable" and probably other
> >>> irrelevancy (read, no real answers). I spoke of "Lightweight" vs.
> >>> "Heavyweight" objects. And of "representation in memory of an object"
> >>> as important.
> >> It's very important for us embedded and driver writers.
>
> > I think it is important at a higher level also.
>
> Specifying a memory layout and portability are pretty much orthogonal.
I more than suggest that you are wrong. I suggest that is the problem
to be solved.
>
> >>> Look it up: C# recognizes "lightweight" classes (structs) as relevant.
> >>> C# recognizes struct layout as relevant.
> >> So does C++, I couldn't write most of my code if it didn't.
>
> > Again, addressing only the second line of a 2 line quote (?). See my
> > response to red floyd above.
>
> So? C++ recognises portability as relevant.
Say it right: it's a bitch to the hardware wielding.
>
> A POD struct in C++ is no different from a C struct
Duh, that's the definition of a POD struct.
> and you can't get
> much more lightweight than that.
Extremism does not mean practicalism or "nicely correct" (akin to
"simply elegant").
>
> >> I can't see where using C# (about as non-portable as one can get)
> >> differs from using platform specific features in C++.
>
> > Again, I'm not suggesting C# and C++ are in the same category (I
> > shouldn't have left out the fact that I view C# as "a Java killer
> > wannabe" in my original post).
>
> Then what are you suggesting?
I'm taxing you to heavily with what I consider fundamental? (No
offense intended). I'm not going to take this conversation to "the
meaning of life" level. Recognize the removal of C++ from the concepts
I think should be fundamental (or "guaranteed" or <something>..
something is missing). I gave examples of independed thought (ha!) by
Microsoft (:P). Tony says the world is not flat, so be it.
> If you want to get closer to an apples to
> apples comparison, you have to consider all the platform specific
> options offered by C++ compilers.
I DO consider platforms. I'm quick to this: designed by committee is a
false leader.
>
> --
> Ian Collins
tonytech08
> tonytech08 wrote:
> > On Dec 19, 12:07 pm, "Bo Persson" <b...@gmb.dk> wrote:
>
> >> One goal for the C++ language is to be efficiently implementable on a
> >> wide range on systems.
>
> > Understood: it bows to every whim of hardware engineers and to non-
> > standardization of hardware.
>
> Don't be a fool,
Don't be an extremist hoping I would fall for your propoganda/
opression. Are you a simpleton?! It's hardly one thing or the other
(the VERY first principle of engineering.. if you don't have it by age
3, then give it up), there is always AT LEAST a range (spherical
thinkers take heart)
> how can hardware be standardised?
Now we're talkin!! (Why did it take so long is the more relevant
question).
> Different
> requirements have different solutions.
Oh yeah, "everything, all the time". That's short term thinking and
that kind of thinking is good in appropriate context. "operations
manager" or "project manager". Most things built are upon that, and it
is wrong (see stock market crash of 2008).
> Do you want a 125W quad core
> monster in your toaster?
>
That's why short term thinkers shouldn't be in charge of anything long
term.
> >> This is, in part, achieved by not specifying
> >> the exact size of an int, or the binary format of a float, or the
> >> exact layout of a class.
>
> > I'm suggesting that is a problem to be solved.
>
> No it isn't.
Yes it is.
> What use is a 64 bit int on an 8 bit PIC?
You proved my case.
>
> C++ is a general purpose programming language, C# isn't.
Oh, now at the end of the post? k. Like I said, I recognize C# as
proprietary Java wannabe. I don't program at that level. But I don't
do device drivers or OSes either. But I would do both of those if I
had enough time left. Stop making it hard.
Bo Persson
> On Dec 19, 12:07 pm, "Bo Persson" <b...@gmb.dk> wrote:
>> tonytech08 wrote:
>>> Very recently, I started a thread enquiring about the C++ object
>>> model. All that remains in my mind about that thread is: "why
>>> would you want to do that?", and "it's not portable" and probably
>>> other irrelevancy (read, no real answers). I spoke of
>>> "Lightweight" vs. "Heavyweight" objects. And of "representation
>>> in memory of an object" as important.
>>
>>> Well guess what? I stumbled upon some C# description pages of
>>> structs, classes and the like. Guess what? What seems to be in
>>> this NG as "don't do that" and "non-portable", a multi-billion
>>> dollar company is implementing their language in seeming lockstep
>>> to my preponderances here.
>>
>> C# is only "portable" to the .NET platform, so it is easy to
>> document the "representation in memory", as there is only one.
>
> I think that level of guarantee should be a goal of some sort
> (whether that means less widely defined programming languages or
> more standardization of hardware). It may be idealistic, but maybe
> not.
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.
>>
>> One goal for the C++ language is to be efficiently implementable
>> on a wide range on systems.
>
> Understood: it bows to every whim of hardware engineers and to non-
> standardization of hardware.
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.
Besides, as long as you stay within your own platform, the struct
layout doesn't have to be portable, just consistent. If you write
programs for embedded platforms, and I write transaction intensive
applications for the mainframe, portability isn't a problem in
practice, because it is not there. Bet you don't have DB2 on your
platform anyway. :-)
Bo Persson
SG
you strike me as someone with a mindset heavily influenced by
languages like C# and Java. Let me bring a quote by B. Stroustrup to
your attention:
"Language comparisons are rarely meaningful and even less often
fair. A good comparison of major programming languages requires
more effort than most people are willing to spend, experience in
a wide range of application areas, a rigid maintenance of a
detached and impartial point of view, and a sense of fairness."
IMHO, this is very well put. You can find it in his FAQ. The reason
why I brought this up is because I think you don't (yet) qualify as
someone being able to do a fair comparison. No offense, I don't even
see myself in this position. Though, I have a fairly good Java
background and switched "recently" (2 years ago) to C++. Guess why: I
appreciate C++ for being better suited for number chrunching tasks.
I don't have a problem with some things left implementation-defined.
The headers <climits> and <limits> are there to query certain
properties at compile-time.
Also, you're using words like leightweight and heavyweight which I
don't attach much meaning to in the context of structs/classes. C++
has the idea of PODs (plain old data structures). What is it about
PODs that you don't find "lightweight" enough? In case you already
axplained what you mean exactly by lightweight and heavyweight forgive
me for missing that.
Cheers!
SG
emin...@googlemail.com
obviosly some people like certain lingos more than other.
oh, yes i could say "i'm being impartial and not favoring one or the
other, its just one is plain better...."
but no one would believe me because you'd know that one or the other
is better(except those who think like me.
everyone is biased even if you don't admit it
Mr 3l1t3
James Kanze
> Hello tonytech08,
> you strike me as someone with a mindset heavily influenced by
> languages like C# and Java. Let me bring a quote by B.
> Stroustrup to your attention:
> "Language comparisons are rarely meaningful and even less
> often fair. A good comparison of major programming
> languages requires more effort than most people are willing
> to spend, experience in a wide range of application areas, a
> rigid maintenance of a detached and impartial point of view,
> and a sense of fairness."
> IMHO, this is very well put. You can find it in his FAQ. The
> reason why I brought this up is because I think you don't
> (yet) qualify as someone being able to do a fair comparison.
More to the point, a comparison between languages only makes
sense if you specify why and according to what criteria you are
comparing them. I use several different languages in my day to
day work---each is better than the others for what I use it for.
No one language is perfect for everything. (I just finished a
project completely in AWK:-). I could have written it in C++,
but for what I was doing, AWK was a lot easier.)
--
James Kanze (GABI Software) email:james...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
tonytech08
> Hello tonytech08,
>
> you strike me as someone with a mindset heavily influenced by
> languages like C# and Java.
Not at all. I've never used either. But in seeing C# addressing some
issues/desires I have, it gives me confirmation that I'm on the right
track.
[ "Appeal to a higher authority" noted and snipped ]
> Also, you're using words like leightweight and heavyweight which I
> don't attach much meaning to in the context of structs/classes.
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).
> C++
> has the idea of PODs (plain old data structures). What is it about
> PODs that you don't find "lightweight" enough? In case you already
> axplained what you mean exactly by lightweight and heavyweight forgive
> me for missing that.
JK and I went round-and-round on this topic in another thread recently
so review that first.
tonytech08
> B.S was right its no use comparing languages because
> obviosly some people like certain lingos more than other.
That's like saying: "Languages stagnate at some point and any further
"competitive analysis" is useless". Time for some people to get away
from the "everything that isn't already in the standard is a threat"
mentality.
tonytech08
> On Dec 21, 12:45 pm, SG <s.gesem...@gmail.com> wrote:
>
> > Hello tonytech08,
> > you strike me as someone with a mindset heavily influenced by
> > languages like C# and Java. Let me bring a quote by B.
> > Stroustrup to your attention:
> > "Language comparisons are rarely meaningful and even less
> > often fair. A good comparison of major programming
> > languages requires more effort than most people are willing
> > to spend, experience in a wide range of application areas, a
> > rigid maintenance of a detached and impartial point of view,
> > and a sense of fairness."
> > IMHO, this is very well put. You can find it in his FAQ. The
> > reason why I brought this up is because I think you don't
> > (yet) qualify as someone being able to do a fair comparison.
>
> More to the point, a comparison between languages only makes
> sense if you specify why and according to what criteria you are
> comparing them. I use several different languages in my day to
> day work---each is better than the others for what I use it for.
> No one language is perfect for everything. (I just finished a
> project completely in AWK:-). I could have written it in C++,
> but for what I was doing, AWK was a lot easier.)
The post wasn't meant to be a language comparison but rather a look at
some very specific features and to compare/contrast/evaluate/discuss
them. An industry driving toward more platform commonality would be a
good thing IMO. And maybe that's one of the knowledges we can get by
studying the "higher level" languagues such as C# and Java.
tonytech08
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.
>
>
>
> >> One goal for the C++ language is to be efficiently implementable
> >> on a wide range on systems.
>
> > Understood: it bows to every whim of hardware engineers and to non-
> > standardization of hardware.
>
> 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
> On Dec 21, 5:45 am, SG <s.gesem...@gmail.com> wrote:
> > Also, you're using words like leightweight and heavyweight which I
> > don't attach much meaning to in the context of structs/classes.
>
> 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).
>
> 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
> On 24 Dez., 17:23, tonytech08 <tonytec...@gmail.com> wrote:
>
> > On Dec 21, 5:45 am, SG <s.gesem...@gmail.com> wrote:
> > > Also, you're using words like leightweight and heavyweight which I
> > > don't attach much meaning to in the context of structs/classes.
>
> > 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.
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
> On Dec 27, 6:40 pm, SG <s.gesem...@gmail.com> wrote:
> > On 24 Dez., 17:23, tonytech08 <tonytec...@gmail.com> wrote:
> > > 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.
> 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.
> > 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).
Ok.
> > 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).
Good luck with that.
Cheers!
SG
tonytech08
> On 28 Dez., 06:02, tonytech08 <tonytec...@gmail.com> wrote:
>
> > On Dec 27, 6:40 pm, SG <s.gesem...@gmail.com> wrote:
> > > On 24 Dez., 17:23, tonytech08 <tonytec...@gmail.com> wrote:
> > > > 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.
> > 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.
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
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
> On Dec 30, 3:41 pm, tonytech08 <tonytec...@gmail.com> wrote:
>
> > 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.
'no' what?
> You're the guy making the claims.
Oh? What claims am I making?
> Summarize the
> description here. *CLEARLY*.
Funny guy.
tonytech08
> On 31 Dez., 00:41, tonytech08 <tonytec...@gmail.com> wrote:
>
> > On Dec 28, 2:28 am, SG <s.gesem...@gmail.com> wrote:
> > > 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'.
>
> 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.
>
> > 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?
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
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
> On 31 Dez., 00:41, tonytech08 <tonytec...@gmail.com> wrote:
> > On Dec 28, 2:28 am, SG <s.gesem...@gmail.com> wrote:
> > > 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'.
> 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.
> > 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?
No. The layout of fields is totally irrelevant. This is just
the usual troll.
James Kanze
> On Dec 30, 8:01 pm, SG <s.gesem...@gmail.com> wrote:
> > 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).
You mean that you're not going to let anyone know what you mean.
> > 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.
So what is yours. You refuse to tell us (or you're incapable of
telling us).
> > > 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?
> 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
> On Dec 30, 8:01 pm, SG <s.gesem...@gmail.com> wrote:
> 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.
> > 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?
They aren't part of the language, but an extension for the .NET
environment.
James Kanze
> On Dec 30, 8:01 pm, SG <s.gesem...@gmail.com> wrote:
> 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.
> > 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?
They aren't part of the language, but an extension for the .NET
SG
> On Dec 30, 8:01 pm, SG <s.gesem...@gmail.com> wrote:
> > You have to do better than saying "look up the C# documentation".
> 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.
> > 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.
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
> On Dec 31, 3:01 am, SG <s.gesem...@gmail.com> wrote:
> > 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.
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
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
> On Dec 31, 5:28 am, tonytech08 <tonytec...@gmail.com> wrote:
>
>
>
>
>
> > On Dec 30, 8:01 pm, SG <s.gesem...@gmail.com> wrote:
> > > 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).
>
> 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.
>
> > > 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.
>
> 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.
tonytech08
> On Dec 31 2008, 1:57 pm, SG <s.gesem...@gmail.com> wrote:
>
> > On 31 Dez., 09:19, James Kanze <james.ka...@gmail.com> wrote:
> > > On Dec 31, 3:01 am, SG <s.gesem...@gmail.com> wrote:
> > > > 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.
> > 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.
Explicit layout control.
tonytech08
> On 31 Dez., 05:28, tonytech08 <tonytec...@gmail.com> wrote:
>
> > On Dec 30, 8:01 pm, SG <s.gesem...@gmail.com> wrote:
> > > 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.
>
> [layout control] supposedly serves two purposes:
> - emulating C/C++ unions
> - interfacing with native code
Those were just 2 examples they gave. Surely they thought that the
obviousness didn't warrant any simpler examples.
tonytech08
>
In C#, one can derive from an interface and still have a lightweight
class whereas doing the same derivation in C++ results in a
heavyweight class.
Bo Persson
Now we are back to the fact that C# only runs on the .NET platform,
and therefore can document the exact layout of the underlying data.
C++ wants to be more flexible, to allow implementations to target
other kinds of platforms.
Is this flexibility really an advantage or a disadvantage? :-)
A similar example is C99 which has a typedef int32_t for those
platforms where this is possible, and lacks this typedef for platforms
where it is not possible. C# only targets platforms where an int32_t
type is possible. Does that make it a better language?!
Bo Persson
SG
> On Dec 31 2008, 1:57 pm, SG <s.gesem...@gmail.com> wrote:
> > On 31 Dez., 09:19, James Kanze <james.ka...@gmail.com> wrote:
> > > On Dec 31, 3:01 am, SG <s.gesem...@gmail.com> wrote:
> > > > 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.
> > 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.
I thought I made it clear that I'm only talking about the value/
reference semantics aspect.
Cheers!
SG
Erik Wikström
Of course, because either you have a variable of the struct-type in
which case you know at compile-time that the object supports the
interface derived from. Or you box the struct (allocate memory on the
heap, generate a vptr, and all that stuff) at which point it works just
like a C++ class with virtual functions.
While the struct might seem quite lightweight from a programming
perspective you should be aware that when boxing comes into play it is
quite heavyweight for the implementation/application. If you find
yourself in a situation where you need to do a lot of boxing/unboxing
you should probably use a class instead of a struct, it will make things
much faster.
--
Erik Wikström
Thomas J. Gritzan
That's wrong. In C# you don't have control over the layout of classes or
structs, you have control over the marshalled representation.
You can do the same in C++, you would only have to code it yourself (or
use a library).
--
Thomas
Grizlyk
>
> On Dec 21, 12:11 am, Ian Collins wrote:
> >
> > how can hardware be standardised?
> > Different requirements have different solutions.
> > Do you want a 125W quad core monster in your toaster?
>
> Now we're talkin!!
Take in account, that you can not write any program, that will be
successfully executed on "125W quad core monster" and on "toaster", at
least there are no useful programs like this.
> On Jan 1, 2009 11:59 pm, Bo Persson wrote:
> >
> > A similar example is C99 which has a typedef int32_t for those
> > platforms where this is possible, and lacks this typedef for platforms
> > where it is not possible. C# only targets platforms where an int32_t
> > type is possible. Does that make it a better language?!
There is no easy way to unify hardware, but in general (undepended
from any language) case, there is a way to be portable and to be
compiled exactly to hardware simultaneously. To do it your program
must not refer to hardware directly, but refer to abstract types from
levels of portabibity, for example:
//exactly 16 bit of memory
typename int_p16
- in systems where CPU can not use the cluster compiler will do slow
runtime workaround
- useful for binary protability between different hardware
//at least 16 bit of memory
typename int_u16
- in systems where CPU can not use the clusters compiler will extend
memory up to nearest CPU block, if there is no the block compiler will
do slow runtime workaround
- useful to keep data range with fast CPU access
//fastest CPU block
typename int
- can be usless type due to overhead or overflow
And so on. While programming, you need to select correct type. The
problem of "only one type to select" can be resolved by object-
oriented methods.
> > Does that make it a better language?!
It is evidently, some even low-level properties of C++ mus be
improved, but this is not easy to do.
grizlyk
tonytech08
At least it tries to reach for the ideal and improve things rather
than "that's just the way things are" (however bizarre that may sound
to anyone).
tonytech08
I don't have a handle on the MS terminology "box/unboxing" yet (last
week I thought I did, but obviously I didn't put it in long term
memory, maybe because it seemed like somthing dumb). I'm not sure that
it doesn't have to do with the rather curious decision to make structs
stack-only things and classes heap-only things. (Which further
obfuscates the lightweight/heavyweight designations).
tonytech08
wrote:
I don't think that is correct (but I can't refute it either). If C#
indeed operates within a VM, then as long as you stay in it, I think
you have that layout control. It's only when you bounce out of it that
you lose the guarantees. (?).
tonytech08
I think I can say it much more concisely if I grok'd your post
overall:
People don't program to a standard (such as std C++), they program to
a platform. (Yes, yes, if you're a masochist, you decide that you will
target ALL platforms with one codebase and in doing so you will find
the holy grail of "portability").
Thomas J. Gritzan
You can only specify object layout, when you pass these objects to
unmanaged code. When you call an unmanaged function, the VM copies C#
structs to another place (marshalled to the specified representation)
and pass the copies to the function.
It's written in the docs:
"Controls the layout of an object when exported to unmanaged code."
"The members of the object are laid out sequentially, in the order in
which they appear when exported to unmanaged memory."
http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.layoutkind.aspx
"This attribute is used [...] to specify the offset of each non- static
or constant member within the unmanaged representation of that class or
structure."
http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.fieldoffsetattribute.aspx
Or do you know other ways of control C# struct layout?
--
Thomas
tonytech08
> tonytech08 wrote:
> > On Jan 1, 10:52 pm, "Thomas J. Gritzan" <phygon_antis...@gmx.de>
> > wrote:
> >> tonytech08 schrieb:
> >>> On Jan 1, 4:50 am, James Kanze <james.ka...@gmail.com> wrote:
> >>>> C# doesn't support anything that C++ doesn't.
> >>> Explicit layout control.
> >> That's wrong. In C# you don't have control over the layout of classes or
> >> structs, you have control over the marshalled representation.
>
> > I don't think that is correct (but I can't refute it either). If C#
> > indeed operates within a VM, then as long as you stay in it, I think
> > you have that layout control. It's only when you bounce out of it that
> > you lose the guarantees. (?).
>
> You can only specify object layout, when you pass these objects to
> unmanaged code. When you call an unmanaged function, the VM copies C#
> structs to another place (marshalled to the specified representation)
> and pass the copies to the function.
> It's written in the docs:
>
> "Controls the layout of an object when exported to unmanaged code."
>
> "The members of the object are laid out sequentially, in the order in
> which they appear when exported to unmanaged memory."
>
>
> "This attribute is used [...] to specify the offset of each non- static
> or constant member within the unmanaged representation of that class or
>
> Or do you know other ways of control C# struct layout?
I'm not a C# user though.
Grizlyk
>
> > There is no easy way to unify hardware, but in general (undepended
> > from any language) case, there is a way to be portable and to be
> > compiled exactly to hardware simultaneously. To do it your program
> > must not refer to hardware directly, but refer to abstract types from
> > levels of portabibity
>
> overall:
>
> People don't program to a standard (such as std C++), they program to
> a platform. (Yes, yes, if you're a masochist, you decide that you will
> target ALL platforms with one codebase and in doing so you will find
> the holy grail of "portability").
What? Speak easy in english, who will translate all of these? I guess
only, that you do not like masochists. This is interesting, but what
about "must not refer to hardware directly"?
If wou will hide hardware by abstract types you will get "ALL
platforms with one codebase".
Thomas J. Gritzan
>> "Controls the layout of an object when exported to unmanaged code."
>>
>> "The members of the object are laid out sequentially, in the order in
>> which they appear when exported to unmanaged memory."
>>
>> http://msdn.microsoft.com/en-us/library/system.runtime.interopservice...
>>
>> "This attribute is used [...] to specify the offset of each non- static
>> or constant member within the unmanaged representation of that class or
>> structure."http://msdn.microsoft.com/en-us/library/system.runtime.interopservice...
>>
>> Or do you know other ways of control C# struct layout?
>
>
> http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.structlayoutattribute(VS.71).aspx
>
> I'm not a C# user though.
But you do know, that StructLayoutAttribute is used together with
LayoutKind (my first link) and FieldOffsetAttribute (my second link),
don't you?
They all are part of the InteropServices namespace, which suggest that
they are made to support interoperability with other languages / non
.NET code.
Since all of it doesn't belong to the language C# but to the .NET
framework, you can do the same with Visual Basic or C++/CLI.
As with C++, the memory layout is not a language issue. The platform
defines the memory layout. Every C++ compiler has extensions to affect
the memory layout of objects to some extent. But when do you need to
control it explicitly? If you need your data in a specific format, you
can serialize it, as everyone else does.
--
Thomas
tonytech08
> On Jan 6, 9:19 am, tonytech08 <tonytec...@gmail.com> wrote:
>
>
>
> > > There is no easy way to unify hardware, but in general (undepended
> > > from any language) case, there is a way to be portable and to be
> > > compiled exactly to hardware simultaneously. To do it your program
> > > must not refer to hardware directly, but refer to abstract types from
> > > levels of portabibity
>
> > I think I can say it much more concisely if I grok'd your post
> > overall:
>
> > People don't program to a standard (such as std C++), they program to
> > a platform. (Yes, yes, if you're a masochist, you decide that you will
> > target ALL platforms with one codebase and in doing so you will find
> > the holy grail of "portability").
>
> What? Speak easy in english,
I do.
> who will translate all of these?
What needs translation?
> I guess
> only, that you do not like masochists. This is interesting, but what
> about "must not refer to hardware directly"?
I wasn't the one who wrote "must not refer to hardware directly".
>
> If wou will hide hardware by abstract types you will get "ALL
> platforms with one codebase".
You are erroneously taking two posters posts and combining them.
tonytech08
wrote:
> tonytech08 schrieb:> On Jan 6, 5:55 am, "Thomas J. Gritzan" <phygon_antis...@gmx.de> wrote:
>
> [about explicit memory layout]
>
>
>
>
>
> >> "Controls the layout of an object when exported to unmanaged code."
>
> >> "The members of the object are laid out sequentially, in the order in
> >> which they appear when exported to unmanaged memory."
>
> >>http://msdn.microsoft.com/en-us/library/system.runtime.interopservice...
>
> >> "This attribute is used [...] to specify the offset of each non- static
> >> or constant member within the unmanaged representation of that class or
> >> structure."http://msdn.microsoft.com/en-us/library/system.runtime.interopservice...
>
> >> Or do you know other ways of control C# struct layout?
>
>
> > I'm not a C# user though.
>
> But you do know, that StructLayoutAttribute is used together with
> LayoutKind (my first link) and FieldOffsetAttribute (my second link),
> don't you?
>
> They all are part of the InteropServices namespace, which suggest that
> they are made to support interoperability with other languages / non
> .NET code.
>
> Since all of it doesn't belong to the language C# but to the .NET
> framework, you can do the same with Visual Basic or C++/CLI.
>
> As with C++, the memory layout is not a language issue. The platform
> defines the memory layout. Every C++ compiler has extensions to affect
> the memory layout of objects to some extent. But when do you need to
> control it explicitly? If you need your data in a specific format, you
> can serialize it, as everyone else does.
>
Serialization should not be necessary (and indeed it isn't, but it's
more pervasive than it should be because of layout issues for one
thing).
tonytech08
OK, I think I know what you meant now.
I was saying: that the C++ language doesn't address portability
concerns other than by providing the standard library. (Do you have
threads available? 64-bit integers? IEEE floating point? Little
endian? Struct layout control? Etc.) Rather it leaves that as an
exercise for the developer to do. Given that, the developer will find
that chore of creating some kind of portability layer (and that
doesn't necessarily mean, nor primarily mean, "finding abstractions")
easier if he defines fewer target platforms (Wintel, for example)
rather than playing the "gotta be portable everywhere game" (a.k.a,
"searching for the holy grail of portability") which is
"massochistic". The developer programs to a higher level (the target
platform set) via the portability layer rather than just using raw C++
("the standard").
goo...@dalvander.com
wrote:
> You can only specify object layout, when you pass these objects to
> unmanaged code. When you call an unmanaged function, the VM copies C#
> structs to another place (marshalled to the specified representation)
> and pass the copies to the function.
The following program outputs 34567800 which would suggest that the
object layout is in effect in managed code as well:
[StructLayout(LayoutKind.Explicit)]
struct ExplicitType
{
[FieldOffset(0)]
public uint i1;
[FieldOffset(1)]
public uint i2;
}
class Program
{
static void Main()
{
ExplicitType o = new ExplicitType();
o.i2 = 0x12345678;
Console.WriteLine("{0:x}", o.i1);
}
}
Also see the IL:
.method private hidebysig static void Main() cil managed
{
.entrypoint
.maxstack 2
.locals init (
[0] valuetype InternalTestConsoleApplication1.ExplicitType o)
L_0000: ldloca.s o
L_0002: initobj InternalTestConsoleApplication1.ExplicitType
L_0008: ldloca.s o
L_000a: ldc.i4 0x12345678
L_000f: stfld uint32
InternalTestConsoleApplication1.ExplicitType::i2
L_0014: ldstr "{0:x}"
L_0019: ldloca.s o
L_001b: ldfld uint32
InternalTestConsoleApplication1.ExplicitType::i1
L_0020: box uint32
L_0025: call void [mscorlib]System.Console::WriteLine(string,
object)
L_002a: ret
}
Regards,
Anders Dalvander
Bo Persson
There are two sides of this, portability of an application and
language implementability on a platform.
Here is one platform that does not have 64 bit integers,
http://unisys.com/products/mainframes/os__2200__mainframes/index.htm
but it does have 36 and 72 bit integers. Should it be disqualified?
Here is another one that does have 32 and 64 bit integers, but it is
big-endian, non-IEEE and has an EBCDIC character set:
http://www-03.ibm.com/systems/z/
It does run C++ though, very well. Most of the applications written
for it is not portable to a PC or a cell phone anyway, so struct
layout doesn't matter. PC games on the other hand, possibly written in
C++, isn't portable to the mainframe because it doesn't have a
graphics device.
> Given that, the developer will
> find that chore of creating some kind of portability layer (and that
> doesn't necessarily mean, nor primarily mean, "finding
> abstractions") easier if he defines fewer target platforms (Wintel,
> for example) rather than playing the "gotta be portable everywhere
> game" (a.k.a, "searching for the holy grail of portability") which
> is "massochistic". The developer programs to a higher level (the
> target platform set) via the portability layer rather than just
> using raw C++ ("the standard").
Very few applications run everywhere, whether the struct layout is
compatible or not. Possibly you can have an "abstraction layer" to
hide the differences between a PC, a PS3 and a Wii, but you can never
abstract away the difference between a Nokia cell phone and an IBM
mainframe. You can use C++ though!
Bo Persson
tonytech08
The real question is whether it is one of your target platforms or
not. No need to address it if not. Treat special cases as special
cases.
> > Given that, the developer will
> > find that chore of creating some kind of portability layer (and that
> > doesn't necessarily mean, nor primarily mean, "finding
> > abstractions") easier if he defines fewer target platforms (Wintel,
> > for example) rather than playing the "gotta be portable everywhere
> > game" (a.k.a, "searching for the holy grail of portability") which
> > is "massochistic". The developer programs to a higher level (the
> > target platform set) via the portability layer rather than just
> > using raw C++ ("the standard").
>
> Very few applications run everywhere, whether the struct layout is
> compatible or not. Possibly you can have an "abstraction layer" to
> hide the differences between a PC, a PS3 and a Wii, but you can never
> abstract away the difference between a Nokia cell phone and an IBM
> mainframe. You can use C++ though!
Well thanks for reiterating part of my point.
Bo Persson
In a software project, that is the question. In a language design,
perhaps it should not be.
This hardware is one reason why the C++ language standard says that
integers can use ones complement, and doesn't have to be exactly 16 or
32 bits wide. The floating point hardware here also uses 72 bits, and
is definitely not IEEE compliant - because the initial design is much,
much older than the standard.
However, the C++ language standard allows a native implementation for
such hardware. The Java and C# standards do not.
In this particular case, the machine contains extra Xeon processors to
execute the Java VM. So much for platform independence! :-)
Bo Persson