I am new to C# and to structs so this could be easy or just not
possible.
I have a struct defined called Branch
If I use Branch myBranch = new Branch(i); // everything works
If I use Branch (myBranch + x) = new Branch(i); // it doesn't
x is a loop iterator, i is an int for the constructor to define an
array.
What am I doing wrong here.
May 10 '06
61  3673 
On Sat, 13 May 2006 16:50:04 -0400, Rick Lones
<Wr******@YcharterZ.net> wrote: This is just silly, Chris. Structures in programming languages have been around
for longer than C, longer than object orientation, longer than C++, and WAY
longer than Microsoft. M/S did not "introduce" structs - and if anything the C#
usage perverts the concept.
When I say "Microsoft introduced structs" I obviously mean "Microsoft
introduced value types to .NET, aka C# structs" because that's the
context of this discussion. I can't believe I have to explain this.
There is nothing holy about the name "struct". They are obviously not
identical with "structures" in older languages, and the historical
meaning of "structure" is so vague anyway that there is hardly a
pre-existing "concept" to "pervert" here.
Not everybody comes to C# from C++. Some may come from C.
Yes, thank you, I had been programming in C before I moved on to C++,
too. I also know Pascal and Fortran and x86 assembler. But I never
expect one concept in one programming language to work identically to
another concept in another programming language just because of a
similar name.
We're talking exclusively in the concept of C# and .NET here. Your
knowledge of PL/1 and whatnot is completely irrelevant, and I suspect
you must get confused a lot if you always try to understand one
language in terms defined by a different language. It's this habit
that's the source of your confusion, not Microsoft's naming decisions.
Anyhow, although it's surely *historically* inaccurate to call a structure a
"lightweight class" this is not the real difficulty.
Good thing nobody calls "a structure a lightweight class", then.
Instead, we call the specific C# construct known as "struct", aka
value type, a lightweight class.
If I describe classes as
"structures extended with methods", have I conveyed anything useful about what a
class is or how objects are used?
Yes, you have. If you pick up any OOP book you'll see that "data plus
operations" is in fact the standard introductory description for
classes. Shall I list a bunch of citations for that, too?
C# structs look confusingly too much like classes as it is IMO
Gee, maybe that's because they are in fact a variant of classes, eh?
Please read an OOP book instead of relying on your knowledge of PL/1
for the rest of your professional carreer!
-- http://www.kynosarges.de
There is an OOP concept known as "class". This OOP concept comprises
the C# constructs "class" and "interface" and "struct", all of which
are different implementations of the OOP concept known as "class".
Furthermore, since the C# "class" is the most commonly used
implementation of the OOP concept "class" (which is why it got the
same name!), it is also appropriate to introduce the C# "interface"
and "struct" as variants of the C# "class". Which they actually are
if you look at the IL or the base class of System.ValueType.
Of course there are differences, otherwise there wouldn't be different
concepts in the first place, now would there? That's no reason to act
as if those concepts were somehow incomparable.
-- http://www.kynosarges.de
On Sun, 14 May 2006 08:24:04 +0100, Jon Skeet [C# MVP]
<sk***@pobox.com> wrote: Except when you use them as parameters, return values, or use
assignment.
As long as your struct is no larger than an IntPtr it's no more
expensive than a class. Smaller structs may be less expensive, even.
I would agree if you'd just said that structs are lighter weight
allocation and release, and can use less memory when a single value is
only used in one place. However, just calling them "lightweight
classes" implies (to me at least) that they're lighter *in general*
which clearly isn't true in reality. There are plenty of ways in which
using them is "heavier" than using classes, so the generalisation isn't
accurate IMO.
To me, the term "lightweight" already implies that this construct is
to be used for small amounts of data which negates the potential cost
of copying on calls & assignments.
As for the references, I'm not going to discuss them. You asked
incredulously where this term came from, and I showed you. Your
arguing that all those sources are incorrect is just a rehash of the
rest of the discussion -- needless to say, I disagree.
I agree that they're commonly introduced as lightweight types. Now, do
you want me to find you a similar number of posts from people who have
been confused by that terminology? Just because lots of people use a
certain description doesn't make it accurate or useful. Heck, lots of
people talk about ASCII as if it had 256 characters in it. Are they
right too, just because there are lots of them?
Don't be ridiculous. This discussion is about a conceptual term, not
about a technical statement that can be true or false. And the
sources I gave were MSDN, Microsoft employees, and published authors,
not random Usenet posters.
It's accurate when the "lightweight" bit is qualified to allocation.
It's possibly helpful when it's in the context of a wider description.
On newsgroups, however, it's often left as the *whole* of the
description of structs, which is what I really object to.
And you may well object but that's a specific problem with those
newsgroup posts that fail to highlight the quirks and costs of
structs. It doesn't affect the usefulness of "lightweight" per se.
When a standard OOP book says that classes are data plus operations
that's not an exhaustive description of classes either, but it's still
a great introduction to the concept. That's how I feel about the term
"lightweight classes", too.
So you're happy to confuse people by using an overly simplistic
description, knowing that some people *will* take that as sufficient
evidence to base decisions on? I prefer to do my utmost to make sure I
won't leave people with the wrong impression.
Some people are always confused. Rather than spending my time on
elaborate explanations I'd rather they crash and burn with their hasty
decisions. Perhaps that will eventually teach them to improve their
decision-making process. Basing an implementation on a soundbite is a
ridiculous and unacceptable attitude towards programming.
-- http://www.kynosarges.de
"Chris Nahr" <ch************@kynosarges.de> wrote in message
news:c2********************************@4ax.com...
| On Sat, 13 May 2006 16:50:04 -0400, Rick Lones
| <Wr******@YcharterZ.net> wrote:
|
| Good thing nobody calls "a structure a lightweight class", then.
| Instead, we call the specific C# construct known as "struct", aka
| value type, a lightweight class.
|
Chris, I could live with it when it was consistently refered to as "a
lightweight type", 'class' is way too specific in C#, as it (wrongly)
implies reference type semantics.
Willy.
"Chris Nahr" <ch************@kynosarges.de> wrote in message
news:h3********************************@4ax.com...
<snip> To me, the term "lightweight" already implies that this construct is
to be used for small amounts of data which negates the potential cost
of copying on calls & assignments.
Perhaps that is the reason for the disagreement. Traditionally
speaking, the term "lightweight class" has NOTHING to do with the actual
data in the "lightweight class". The phrase tends to refer to the bells
and whistles that comes along with your object (Heap allocation,
inheritance, etc). The fact that small objects are a better fit for
structs is a by-product of the way they are implemented in C#.
A very common use for structs in C++ is when your object is little
more than a data holder. Few, if any methods. No need for inheritance.
So they create a struct with no virtual methods and the create it on the
stack and not the heap. The net result is a more efficient
implementation for their needs. The fact that the actual data may have
some girth, rarely enters the picture. Why? because they don't intend to
copy it all over the place. If they have to, they can pass it as a
pointer.
<snip> Some people are always confused. Rather than spending my time on
elaborate explanations I'd rather they crash and burn with their hasty
decisions. Perhaps that will eventually teach them to improve their
decision-making process. Basing an implementation on a soundbite is a
ridiculous and unacceptable attitude towards programming.
Wow, that's a pretty crappy attitude you have there.
I, personally, attempt to help other people if I can.
> When I say "Microsoft introduced structs" I obviously mean "Microsoft introduced value types to .NET, aka C# structs" because that's the
context of this discussion. I can't believe I have to explain this.
Hey, I had to explain that when I said that I had never found a
situation so compelling that I decided to
use a "struct" for efficiency reasons, that I wasn't talking about
native types. Live by the sword, die by the sword. :-)
Chris Nahr <ch************@kynosarges.de> wrote:
<snip>
I think we've reached the end of any productive discussion. Probably
best to just leave it there. I can't see us agreeing about this any
time in the near future.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
<snip>
Some people are always confused. Rather than spending my time on
elaborate explanations I'd rather they crash and burn with their hasty
decisions. Perhaps that will eventually teach them to improve their
decision-making process. Basing an implementation on a soundbite is a
ridiculous and unacceptable attitude towards programming.
</snip>
I agree. This is a good summation of the issue. Jon expects to eliminate
this entirely for each and every confused programmer case. It's not
possible. If you make a decision to use a structure in an application based
on a soundbyte, you deserve what you get for being irresponsible - assuming
code reviewers don't catch the problem and inform you of it before it hits
production.
--
________________________
Warm regards,
Alvin Bruney [MVP ASP.NET]
[Shameless Author plug]
Professional VSTO.NET - Wrox/Wiley
The O.W.C. Black Book with .NET www.lulu.com/owc, Amazon
Blog: http://www.msmvps.com/blogs/alvin
-------------------------------------------------------
"Chris Nahr" <ch************@kynosarges.de> wrote in message
news:h3********************************@4ax.com... On Sun, 14 May 2006 08:24:04 +0100, Jon Skeet [C# MVP]
<sk***@pobox.com> wrote:
Except when you use them as parameters, return values, or use
assignment.
As long as your struct is no larger than an IntPtr it's no more
expensive than a class. Smaller structs may be less expensive, even.
I would agree if you'd just said that structs are lighter weight
allocation and release, and can use less memory when a single value is
only used in one place. However, just calling them "lightweight
classes" implies (to me at least) that they're lighter *in general*
which clearly isn't true in reality. There are plenty of ways in which
using them is "heavier" than using classes, so the generalisation isn't
accurate IMO.
To me, the term "lightweight" already implies that this construct is
to be used for small amounts of data which negates the potential cost
of copying on calls & assignments.
As for the references, I'm not going to discuss them. You asked
incredulously where this term came from, and I showed you. Your
arguing that all those sources are incorrect is just a rehash of the
rest of the discussion -- needless to say, I disagree.
I agree that they're commonly introduced as lightweight types. Now, do
you want me to find you a similar number of posts from people who have
been confused by that terminology? Just because lots of people use a
certain description doesn't make it accurate or useful. Heck, lots of
people talk about ASCII as if it had 256 characters in it. Are they
right too, just because there are lots of them?
Don't be ridiculous. This discussion is about a conceptual term, not
about a technical statement that can be true or false. And the
sources I gave were MSDN, Microsoft employees, and published authors,
not random Usenet posters.
It's accurate when the "lightweight" bit is qualified to allocation.
It's possibly helpful when it's in the context of a wider description.
On newsgroups, however, it's often left as the *whole* of the
description of structs, which is what I really object to.
And you may well object but that's a specific problem with those
newsgroup posts that fail to highlight the quirks and costs of
structs. It doesn't affect the usefulness of "lightweight" per se.
When a standard OOP book says that classes are data plus operations
that's not an exhaustive description of classes either, but it's still
a great introduction to the concept. That's how I feel about the term
"lightweight classes", too.
So you're happy to confuse people by using an overly simplistic
description, knowing that some people *will* take that as sufficient
evidence to base decisions on? I prefer to do my utmost to make sure I
won't leave people with the wrong impression.
Some people are always confused. Rather than spending my time on
elaborate explanations I'd rather they crash and burn with their hasty
decisions. Perhaps that will eventually teach them to improve their
decision-making process. Basing an implementation on a soundbite is a
ridiculous and unacceptable attitude towards programming.
--
http://www.kynosarges.de
> <snip>
I think we've reached the end of any productive discussion. Probably
best to just leave it there. I can't see us agreeing about this any
time in the near future.
ah but the discussion has been very spirited.
I think we can agree that
1. The existing literature establishes the ground rules.
2. It's too late to change the established ground rules even without regard
to the fact that they may or may not be correct.
3. Concepts defined within the C# language should not be viewed within the
context of other languages.
4. Programmers must understand language facets in detail before using these
constructs in production code especially where these constructs may have
have performance consequences or may be used in time-sensitive applications.
5. Happy mother's day to the ladies on the list with child. (we all can
surely agree on that one in particular)
--
________________________
Warm regards,
Alvin Bruney [MVP ASP.NET]
[Shameless Author plug]
Professional VSTO.NET - Wrox/Wiley
The O.W.C. Black Book with .NET
www.lulu.com/owc, Amazon
Blog: http://www.msmvps.com/blogs/alvin
-------------------------------------------------------
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Chris Nahr <ch************@kynosarges.de> wrote:
<snip>
I think we've reached the end of any productive discussion. Probably
best to just leave it there. I can't see us agreeing about this any
time in the near future.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
"Alvin Bruney" <www.lulu.com/owc> wrote: 5. Happy mother's day to the ladies on the list with child. (we all can
surely agree on that one in particular)
UK - "Mothering Sunday" not Mother's Day - March 26th
Norway - second sunday in February
Spain - first sunday in May
Argentina - second sunday in october
Panama - December 8th
!!!
from wikipedia.org
--
Lucian
<"Alvin Bruney" <www.lulu.com/owc>> wrote: I think we've reached the end of any productive discussion. Probably
best to just leave it there. I can't see us agreeing about this any
time in the near future.
ah but the discussion has been very spirited.
That's certainly true.
I think we can agree that
1. The existing literature establishes the ground rules.
Well, I don't think I'd call them "ground rules". I'd agree that the
existing literature uses the word "lightweight" in discussions of
structs with varying degrees of accuracy.
2. It's too late to change the established ground rules even without regard
to the fact that they may or may not be correct.
I don't agree with that. In the Java world, many early books
incorrectly stated that Java passed objects by reference. This caused a
great deal of confusion. Are you saying you think those books shouldn't
have been corrected, and the correct terminology used? As another
example, are you suggesting that MSDN shouldn't have been fixed to
correctly describe System.Decimal as a floating point type instead of a
fixed point type? Are you suggesting that people should go along with
the idea that ASCII has 256 values, just because lots of web pages (and
some MSDN pages) claim that it has?
If something is incorrect, it should be pointed out as being incorrect.
Pretending that something is correct just because it's widely
stated/believed is a really bad idea.
How about the whole universe going round the earth, by the way? That
was one of the "established ground rules" before it was challenged...
3. Concepts defined within the C# language should not be viewed within the
context of other languages.
Well, they can be compared with other languages, but only carefully.
4. Programmers must understand language facets in detail before using these
constructs in production code especially where these constructs may have
have performance consequences or may be used in time-sensitive applications.
I don't think performance is actually the key concern here - that's one
of the things that bothers me about simply describing structs as
"lightweight classes" - it ignores the most important part (value type
semantics) and concentrates on the efficiency part (and overgeneralises
that too).
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
> I think we can agree that 1. The existing literature establishes the ground rules.
No, not ground rules as such. The existing literature is always the
existing literature, and can not be discarded as such, but parts of the
existing literature will always be more or less inaccurate.
The quality of the existing literature can be viewed using chaos theory. :)
Any section of the literature that is regarded as generally correct will
always contain parts that are incorrect. If you reduce the size of the
section to isolate a part that is absolutely correct, the section will
be so small that it's practically unusable.
2. It's too late to change the established ground rules even without regard
to the fact that they may or may not be correct.
It's never too late to change the general conception of the rules. The
history is full of examples on this...
3. Concepts defined within the C# language should not be viewed within the
context of other languages.
So true. Still, people will always compare elements of new languages to
similar elements in languages they already know. The syntax of C# is
very similar to C, C++ and Java, so anyone coming from any of those
platforms will naturally use their previous knowledge, and for the most
part that will work fine as many aspects of the languages work exactly
the same. There is no problem until you come to aspects of the language
that works differently from previous similar languages. That's why it's
important that those apsects are explained in a way that doesn't imply
similarities with other languages that aren't true.
4. Programmers must understand language facets in detail before using these
constructs in production code especially where these constructs may have
have performance consequences or may be used in time-sensitive applications.
Yes, that would be the ideal situation. Still, there are a lot of
programmers out there who use things that they barely know enough about
to make them work, much less have detailed knowledge about... This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Edward Gregor |
last post by:
In C, if I want similar names for typename and variable,
is there any good way you can recommend me to do that?
For example, I have a struct containing a region, which
I have named it,...
|
by: Jyrgen |
last post by:
Hi
I have problems giving my structs good names, I usually name
them after what they are (of course) so if I have, say, a
window struct, I name it struct window, I usually don't bother
typedefing...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |
