C# and other OOP languages

[Stonent]

I'm currently taking a C# class that is part of a degree in database administration that I'm working on.  The degree required a programming credit but none of the programming classes I took 13+ years ago were transferable, so I had to take an introductory programming course to fill that credit need. Years back when I took programming classes, the introductory class was Turbo Pascal and the next semester, you had a choice of "Programming I" which was C, or VB 6.  I decided on VB since I had learned BASIC as a kid and eventually took C later, but have had no experience working with Object Oriented languages and until now never really understood what an object really was.  I had just assumed it was a fancy way of saying function or subprogram.

Since a lot of you guys do program maybe you could answer some questions about a few things that have been gnawing at my mind, but I don't know if they are specific to C# or object oriented languages in general, since as of this point I'm not really sure where one ends and the other begins.

Here goes:

I feel like I do a lot of unnecessary type conversions to avoid compiler errors.  Does the compiler/IDE (Visual Studio 2012 in my case) realize when they are not necessary and not bother to do a wasted type conversion or does it go through the motions of converting a type when not needed? This example I just created out of thin air to be an extremely obvious waste of a conversion.

Code: [Select]

string string1 = "This is a string";
string string2;
string2 = Convert.ToString(string1);
I could have simply said string2 = string1 and it have been functionally the same.  Is that optimized out during the compile stage?


I also see that I can do a lot of crazy things that I find myself saying "well this seems logical but there's no way it would work" but it does work.

Example:
This is a line from a program I'm working on (no I'm not asking for homework help on this). The line is just there to give me some status as to what my variables are doing as I'm working on part of it.

wordGuess is an array of chars and I'm outputting it is a string.  I had tried to use the ToString method but apparently you can't do that for whatever reason with an array of chars. So I did some research and found out about using "new string" but the example was something like:

Code: [Select]

string s = new string(c);
In my case I didn't need to assign it to anything, I just wanted to monitor its status my program did its thing, so I thought, what if I just omit the assignment?

So here I create a new string out of thin air with no variable for it to go into, and it works. 

Code: [Select]

Console.WriteLine("{0} {1} {2}", wordList[rndNum], index, new string (wordGuess));
Is this some kind of on the fly thing that disappears or does it actually take a small snip of memory that it doesn't give back.  If I ran it through an infinite loop, would the program eventually crash because of eating up too much resources?

I guess I think about wasted resources a lot more because playing with microcontrollers has made me appreciate the skills and forethought needed to make a fairly complex program work on a platform with maybe 128 bytes of RAM and 512 bytes of flash and then you learn things like storing things in the flash to avoid them being in RAM.

So were my examples above just C#-isms or do other OO languages give you the power to do these odd things?

[c4757p]

The specifics depend on the language, but most of this is typical. Disclaimer: I've done lots of OO languages, but not C#.

Code: [Select]

string string1 = "This is a string";
string string2;
string2 = Convert.ToString(string1);
I could have simply said string2 = string1 and it have been functionally the same.  Is that optimized out during the compile stage?

No, it's not optimized out, and it might not be equivalent. I don't know how Convert.ToString() responds when given something that's already a string - whether it makes a copy, or just returns the original. Check the documentation. But either way, the call is unlikely to be optimized out.

Most people would just say string2 = string1; unless they needed a copy, in which case they'd use new string.

Of course, all of this copy business depends on whether strings in C# are even mutable. If they're not, then it doesn't even make sense to make a copy.

So here I create a new string out of thin air with no variable for it to go into, and it works. 

Code: [Select]

Console.WriteLine("{0} {1} {2}", wordList[rndNum], index, new string (wordGuess));
Is this some kind of on the fly thing that disappears or does it actually take a small snip of memory that it doesn't give back.  If I ran it through an infinite loop, would the program eventually crash because of eating up too much resources?

Also depends on the language. C# is a garbage-collected language, like Java. This means that the new strings are created somewhere in memory and left there - and occasionally, a garbage collector comes along and frees resources that aren't in use anymore. It's a bit unpredictable - I really don't like it, myself - but common in OO languages and a bit easier. Something like C++ would create the object specifically for the duration of the function call and then immediately destroy it when the function returns.**

I wouldn't spend too much time worrying about efficiency in general. As Knuth said, "premature optimization is the root of all evil". Let the garbage collector do its job, and if you start having memory problems, be more clever about memory usage or do that bit in a language like C where you do the memory management yourself. Creating a string out of thin air for the purpose of displaying it is hardly excessive on a PC.

**Edit: Not if you said "new string". The new keyword has a subtly different meaning in C++ - if you create something with new, you're expected to destroy it with delete. But instances can be created in other ways too, and anything created as part of a variable or argument declaration is destroyed when that variable or argument goes out of scope.

[IanB]

Concerning OO in general (all languages, not just C#). Objects are user defined data types that represent the properties and behavior of the things your program is dealing with. All objects have a type. A type represents common properties and behaviors shared by objects of the same type, but each individual object may contain unique data (or state). The OO programming approach allows you to organize your program logic in a more convenient way using principles like abstraction and encapsulation.

Concerning C# in particular, you really need to spend some time on introductory principles of C# and the .NET programming environment. In particular you need to know the difference between value types and reference types. That's absolutely fundamental to C# programming.

If the compiler gives you type conversion errors it is trying to save you from making a mistake. You need to understand what mistake you were making and not try to find a way around it. If you do things the right way the compiler won't (normally) complain.

Creating an array of chars is a somewhat unusual thing to be doing in C# (although completely normal in C). If you are doing that it is possible you are not using the features of C# in the most natural way.

In your example, when you say "new string(wordGuess)" you are creating a new string object using one of the string constructors. If you don't keep a reference to this object anywhere then it will have a temporary lifetime and the memory will be recovered by the system for re-use after you have finished with it.

[poorchava]

you can create variables like int, string, byte, char and so on same as you would in C. There is no 'new' keyword needed. Nevertheless those types are also objects of particular class (press '.' or ctrl+space after variable name and you'll see that those types have public methods. Basic types liek strings, chars, ints and so on also have a helper static class that contains some useful methods (like for example Int32.Parse).

[amyk]

Classes in OOP are just a way of grouping together data and some functions that operate on that data. If you know what C structures are and have written functions that do things with them then you're basically doing some OOP even if you don't realise it.

[Stonent]

The reasoning behind the array of chars was I tried to manipulate the chars in the string by using an index but it won't let you address it that way. So I have to copy the string into an array of chars make my changes and move it in to a string by using new string on the array of char.

So (at least in C#)  myString[index] = 'g'; will not work as the string is considered immutable.

I ended up using something like this: (wordList is an array of strings, wordGuess is an array of chars)

Code: [Select]

rndNum = ranNumberGenerator.Next(0, 8);     // Generate a random number from 0 to 7 to be used to select a word in the array
wordLength = wordList[rndNum].Length;       // Get the length of that word
wordGuess = wordList[rndNum].ToCharArray(0, wordLength);    // Load that word into a char array for manipulation

// Now that the word is loaded, manipulate the data
for (index = 0; index < wordLength; ++index)
{
 /* Changes to the char array happen here */
}

wordGuessString = new string(wordGuess);    // Load the char array into wordGuessString for display purposes

[Stonent]

Classes in OOP are just a way of grouping together data and some functions that operate on that data. If you know what C structures are and have written functions that do things with them then you're basically doing some OOP even if you don't realise it.

I remember doing structures in my C class 13-ish years ago, but haven't had the need to use them in any of my microcontroller projects yet, so I had essentially forgotten about them.

Initially I had hoped to learn C++ instead of C# since C++ wasn't Microsoft centric. So I figured they're both object oriented and related to C so I should be able to make some sense of C++ after learning some C#, right? Nope, C++ looks even more confusing to me now than it ever did before, but on the plus side (I guess it's a plus...) I can now read Java for the most part.  I can't speak it, but I can look at it and figure out what's going on.

[dekra54]

Hi

Have you tried the String.Remove and String.Insert methods ?

wordList[rndNum].Remove(INT32 value start of remove , INT32 Value end of remove);

and then insert the new chars with String.Insert

wordList[rndNum].Insert(INT32 start Index of Insertion, STRING String value to insert);

http://msdn.microsoft.com/de-de/library/d8d7z2kk%28v=vs.110%29.aspx
http://msdn.microsoft.com/de-de/library/system.string.insert%28v=vs.110%29.aspx

[nctnico]

From a C++ background that seems weird to me. In C++ you can write string1=string2 which puts a copy of string2 into string1 (similar to many high level languages). I can't believe the same operation is so obfustigated in C#.

[c4757p]

From a C++ background that seems weird to me. In C++ you can write string1=string2 which puts a copy of string2 into string1 (similar to many high level languages). I can't believe the same operation is so obfustigated in C#.

It's quite simple, actually, no obfuscation anywhere. C++ makes you manage memory yourself, so naturally it has separate value, pointer, and reference modes. A variable string s1 is a direct string whose data is stored on the stack; a variable of type string *s1 isn't a string, but a pointer whose value is stored on the stack, which points to a string whose data is stored on the heap.

C# and Java still make that distinction, but differently. All types are stored on the stack always - but class types are actually stored as references. A variable string s1 isn't a string, it's a reference to one. It can be 'null' just like a C++ pointer, and can point to any string anywhere in the heap. The only difference between these and pointers is that pointer arithmetic is not supported.

Essentially, they make new/delete easier by replacing delete with a garbage collector, and then force you to use them by making all class instance variables pointers.

[nitro2k01]

Code: [Select]

string string1 = "This is a string";
string string2;
string2 = Convert.ToString(string1);
I could have simply said string2 = string1; and it have been functionally the same.  Is that optimized out during the compile stage?

string1 and string2 are references to objects in memory. If you do string2 = string1;, they both now point to the same object in memory. Normally, this would mean that if you modify the object, say if you add an item to an array list, you will see the newly added object whether accessing the object from one or the other reference. This is not so different from a pointer pointing to a memory location in C.

However, strings are, by design, immutable. There is no way you can modify the memory that the object is located at. string2 = string1; is therefore perfectly safe and sensible. If you later do string2 = "Another string"; a new string object is created, and the string2 reference ("pointer") is now made to point to that object instead, and string1 is left intact.

string2 = Convert.ToString(string1); may or may not be optimized depending on the implementation. Convert.ToString may choose to return the same object if the object is of type string instead of creating a new one. Bottom line is, that that shouldn't matter for strings and other immutable objects, as far as correct execution is concerned.

Should? Should. There is a common pitfall, at least in java, and quite possibly in c#, which is that the == operator compares the references and not the contents of the objects. Something like:

Code: [Select]

string string1 = "a string";
string string2 = "a string";

if (string1 == string2){
  Console.Write("true")
}else{
  Console.Write("false")
}
would then report false, since the strings are stored in separate objects. To confuse things further, the compiler might be smart enough to point string1 and string2 to the same reference, as their contents are identical and they appear in the same scope. The comparison above might then be true, while the same comparison made from user input would be false.

The correct way to compare strings is with Equals: if (string1.Equals(string2))

I also see that I can do a lot of crazy things that I find myself saying "well this seems logical but there's no way it would work" but it does work.

Example:
This is a line from a program I'm working on (no I'm not asking for homework help on this). The line is just there to give me some status as to what my variables are doing as I'm working on part of it.

wordGuess is an array of chars and I'm outputting it is a string.  I had tried to use the ToString method but apparently you can't do that for whatever reason with an array of chars. So I did some research and found out about using "new string" but the example was something like:

Code: [Select]

string s = new string(c);
In my case I didn't need to assign it to anything, I just wanted to monitor its status my program did its thing, so I thought, what if I just omit the assignment?

So here I create a new string out of thin air with no variable for it to go into, and it works. 

Code: [Select]

Console.WriteLine("{0} {1} {2}", wordList[rndNum], index, new string (wordGuess));
Is this some kind of on the fly thing that disappears or does it actually take a small snip of memory that it doesn't give back.  If I ran it through an infinite loop, would the program eventually crash because of eating up too much resources?

Unlike a language like c++, c# has a garbage collector, whose job it is to look for unreferenced objects and recycle their resources. Unless garbage collector leaks resources, that line should not create any problem.

To aid your mental model, new string (wordGuess) is an expression. Expressions can generically be used both in a function call or in an assignment, or even on its own.

Code: [Select]

new string (wordGuess) <- Example of an expression

string s = <some expression>;
Console.WriteLine(<some expression>);
<some expression>;

So:

string s = new string (wordGuess);
Console.WriteLine(new string (wordGuess));
new string (wordGuess);The last line is of course utterly useless for strings. But if you were creating an object from a class you wrote, that does something useful in its constructor, but that you don't need a reference to, then that code is a valid, though quirky way of creating an object of that type.

Going on, the reason that you cannot do a ToString on a char array, is that a char array, much like an int or a float, is not an object. Thus it has no methods you can execute. You should still be abloe to convert it into a string using Convert.ToString(chararray) or new string(chararray).

[tggzzz]

Concerning OO in general (all languages, not just C#). Objects are user defined data types that represent the properties and behavior of the things your program is dealing with. All objects have a type.

Er, not C++. The pointer/reference in the source code contains contains the type information, which may or may not be valid and certainly is not present in the object code. In C++ the bytes in memory can be interpreted in any way you choose, by casting just as in C.

In all sane languages you are, of course, correct. The mechanism, as I'm sure you know, is that in one way or another each object contains a pointer to something representing the class of the object.

[tggzzz]

From a C++ background that seems weird to me. In C++ you can write string1=string2 which puts a copy of string2 into string1 (similar to many high level languages). I can't believe the same operation is so obfustigated in C#.

Er no, not at all in C++. If you want to copy a string you have to invoke a method/function to do so.

Presuming string2/1 are pointers/references to the bytes in memory that you wish to be interpreted as strings, all you've done is get two variables to point to the same set of bytes, i.e. created an alias.

[nctnico]

From a C++ background that seems weird to me. In C++ you can write string1=string2 which puts a copy of string2 into string1 (similar to many high level languages). I can't believe the same operation is so obfustigated in C#.

Er no, not at all in C++. If you want to copy a string you have to invoke a method/function to do so.

Nope. The standard C++ string type has overloaded the = operator to copy the string when you write string1=string2. I looked it up specifically to be sure.

[tggzzz]

From a C++ background that seems weird to me. In C++ you can write string1=string2 which puts a copy of string2 into string1 (similar to many high level languages). I can't believe the same operation is so obfustigated in C#.

Er no, not at all in C++. If you want to copy a string you have to invoke a method/function to do so.

Nope. The standard C++ string type has overloaded the = operator to copy the string when you write string1=string2. I looked it up specifically to be sure.

Oh hell, I'd forgotten the abomination of operator overloading. Why? Because the last time I used C++, and abandoned it as being "Completely The Wrong Thing Done To Perfection", it didn't have operator overloading.

Mind you, presuming certain specific declarations of string1 and string2,  it does look as if the compiler can to choose to move it, and if moved, string2 is left in an unspecified but valid state. Whatever that means. ( Source http://www.cplusplus.com/reference/string/string/operator=/ )

That is yet another simple example of how C++ is great for language lawyers who enjoy wrestling with aligators, but not for people that simply want to get a job done by draining the swamp.

[IanB]

Concerning OO in general (all languages, not just C#). Objects are user defined data types that represent the properties and behavior of the things your program is dealing with. All objects have a type.

Er, not C++. The pointer/reference in the source code contains contains the type information, which may or may not be valid and certainly is not present in the object code. In C++ the bytes in memory can be interpreted in any way you choose, by casting just as in C.

I think this is a slightly unreasonable mixing up of the conceptual abstraction of the language and the precise details of how it is implemented.

Stroustrup himself is very clear that the motivation for classes in C++ is to represent user-defined types. It is true that with an implementation built on top of C, then some low level machinery is more exposed than it might be, but that doesn't undermine the conceptual abstractions that the language is aiming to provide.

The truth is that with C++ I can code in an OO manner more conveniently than I can with C, and from the point of view of C++ that would count as mission accomplished.

[Wilksey]

Different languages, different ways of doing things, it's like VC++ using WinForms, the pointer is now a ^ rather than * apparently, very confusing unless you are used to it.

C# was designed by the same person that designed Delphi I believe, I use it day in day out for windows based stuff, it does the job and I can create something very quickly.

I came from an array of different languages, from BASIC, assembler, C/C++, Java and a few variants of, when Microsoft released .NET my RAD windows stuff was done in VB6, I didn't like the new VB.NET, but I did like C#, I did used to get Java and C# mixed quite a bit back in the early days, but eventually overcame that.

The only issue I have had with C#, and the same can be said for Java is it is extremely easy to reverse engineer, so I downloaded a free obfuscator for C# which works well and I have made my own for Java, not foolproof but nothing is, and keeps the majority of people out.

[Bored@Work]

Initially I had hoped to learn C++ instead of C# since C++ wasn't Microsoft centric. So I figured they're both object oriented and related to C so I should be able to make some sense of C++ after learning some C#, right? Nope, C++ looks even more confusing to me now than it ever did before, but on the plus side (I guess it's a plus...) I can now read Java for the most part.  I can't speak it, but I can look at it and figure out what's going on.

Not surprising. C# was Microsoft's way to kill Java on the desktop, esp. the Windows desktop. They took more from Java than from C / C++ when designing the language. Of course Microsoft denies having copied Java - but when did they ever tell the truth?

The language was designed by the same guy who decades ago did develop Turbo Pascal and Delphi, and later had already done J++ for Microsoft. J++ was Java with Microsoft extensions to lock programmers to Windows. That created some trouble for Microsoft later on. In fact $1.6bn of trouble, the sum Microsoft had to pay to Sun. The guy doing J++ was then moving on to do C#. And he and Microsoft had 1.6 billion good reasons denying any association of C# with Java. Nevertheless, C#'s lineage is roughly Java --> J++ --> C#

Microsoft also had a language called J#. That was derived from the above mentioned Microsoft J++, with .NET features added. J# was also intended to lure Java developers away from (theoretically) cross-platform Java to definitely Windows-only code.

J++ didn't really take off, J# did not really take off, but C# did, and Java on the Windows Desktop was dead and is ever since.

[tggzzz]

Concerning OO in general (all languages, not just C#). Objects are user defined data types that represent the properties and behavior of the things your program is dealing with. All objects have a type.

Er, not C++. The pointer/reference in the source code contains contains the type information, which may or may not be valid and certainly is not present in the object code. In C++ the bytes in memory can be interpreted in any way you choose, by casting just as in C.

I think this is a slightly unreasonable mixing up of the conceptual abstraction of the language and the precise details of how it is implemented.

Unfortunately with C++ (much more than Java/C#) the conceptual abstraction rapidly degenerates due to the horrific interactions with the implementation. I'm reminded of the old joke "If you want to get there, I wouldn't start from here", where "there" is OOP nirvana, and "here" is C.

The truth is that with C++ I can code in an OO manner more conveniently than I can with C, and from the point of view of C++ that would count as mission accomplished.

Personally I find Objective-C is far better starting point for OOP-in-C. But then that's because my trajectory in the '80s was C->Smalltalk->C/C++.

I rapidly dropped the C++ when it became apparent that C++ would always need to be subsetted for a given project, and that each library you might think of purchasing would use a slightly different subset. That judgement was shown to be valid for, say 15 years, but might be slightly less valid in the past 10 years.

But I don't care since for all projects that might use C++ now use either C or Java (or C#, which is essentially Java with a different concept how the runtime should work).

[tggzzz]

Initially I had hoped to learn C++ instead of C# since C++ wasn't Microsoft centric. So I figured they're both object oriented and related to C so I should be able to make some sense of C++ after learning some C#, right? Nope, C++ looks even more confusing to me now than it ever did before, but on the plus side (I guess it's a plus...) I can now read Java for the most part.  I can't speak it, but I can look at it and figure out what's going on.

Not surprising. C# was Microsoft's way to kill Java on the desktop, esp. the Windows desktop.

Not quite, as you acknowledge below. The impetus was to lock application developers into Windows, using the tried and tested "embrace and extend" technique.

They took more from Java than from C / C++ when designing the language. Of course Microsoft denies having copied Java - but when did they ever tell the truth?

When Anders Hejlsberg gave us a talk (in c2000) before C++ was released, it was completely apparent that C# was indeed Java plus a different philosophy about how the runtime should be implemented. When we asked if we were missing something, he didn't answer.

The language was designed by the same guy who decades ago did develop Turbo Pascal and Delphi, and later had already done J++ for Microsoft. J++ was Java with Microsoft extensions to lock programmers to Windows. That created some trouble for Microsoft later on. In fact $1.6bn of trouble, the sum Microsoft had to pay to Sun. The guy doing J++ was then moving on to do C#. And he and Microsoft had 1.6 billion good reasons denying any association of C# with Java. Nevertheless, C#'s lineage is roughly Java --> J++ --> C#

Microsoft also had a language called J#. That was derived from the above mentioned Microsoft J++, with .NET features added. J# was also intended to lure Java developers away from (theoretically) cross-platform Java to definitely Windows-only code.

J++ didn't really take off, J# did not really take off, but C# did, and Java on the Windows Desktop was dead and is ever since.

Oh, (while there's some truth there) thats too strong. There are many Java applications that run under Windows, but typically they don't go out of the way to make that evident.

[nctnico]

Initially I had hoped to learn C++ instead of C# since C++ wasn't Microsoft centric. So I figured they're both object oriented and related to C so I should be able to make some sense of C++ after learning some C#, right? Nope, C++ looks even more confusing to me now than it ever did before, but on the plus side (I guess it's a plus...) I can now read Java for the most part.  I can't speak it, but I can look at it and figure out what's going on.

Not surprising. C# was Microsoft's way to kill Java on the desktop, esp. the Windows desktop. They took more from Java than from C / C++ when designing the language. Of course Microsoft denies having copied Java - but when did they ever tell the truth?

IMHO C# is 'Java which works for Windows'. Given that many Java programs work very crappy I feared the worse when Google announced they wanted to use Java for Android. Fortunately Google decided to create their own Java engine from scratch which more or less acknowledged my fears.

[tggzzz]

... Given that many Java programs work very crappy ...

Which is equally true for all languages, of course. Maybe the key factor isn't the language

[nctnico]

... Given that many Java programs work very crappy ...

Which is equally true for all languages, of course. Maybe the key factor isn't the language

No. Sometimes the problem is in the framework. Lot's of errors I've seen in Java programs originate from parallel threading errors.

[nctnico]

IMHO C# is 'Java which works for Windows'. Given that many Java programs work very crappy I feared the worse when Google announced they wanted to use Java for Android. Fortunately Google decided to create their own Java engine from scratch which more or less acknowledged my fears.

To be fair, C# is way better than Java for the desktop. The tools that the .NET environment provides and the C# language features on offer make it fantastic for desktop app development, light database work and client apps. There are some irritating parts, like how all bitwise operations get converted to int, but that's not really what it is designed for.

That may be true but if you step outside the Windows world then C# suddenly is a poor choice. When I have to create a desktop application I use C++ and Wxwidgets because I know I can get my software to work very easely on every popular platform without having to depend on specific libraries or limited implementations (like Mono). In fact I develop all my 'for Windows' software on Linux because it is easier.

[vvanders]

Having spent a bunch if my career working on tools built in wxWidgets I find that surprising. You're missing out on delegates, properties, a great editor and an even better debugger.

If I'm writing for multiple platforms I could see wxWidgets but if you're writing windows only there's many advantages to C#/winforms/etc.