Jose's Read Only Forum 2023

General Category => General Discussion => Topic started by: Rick McNeely on December 09, 2012, 12:32:59 AM

Title: C#
Post by: Rick McNeely on December 09, 2012, 12:32:59 AM
I don't have the benefit of working with other programmers.  Much less more experienced programmers.  So I have a question for those of you who have been working with object oriented languages.

When I view tutorials for C# and other object oriented languages, I get the impression that developers spend most of their time creating objects as well as utilizing existing objects, avoiding any significant procedural code like the plague.  But when I use C# (or C++) I find that I still write procedurally (perfectly cromulent word), while using existing objects and occasionally creating objects of my own. 

Is this typical?  Or should I be finding ways to further 'objectify' my code.
Title: Re: C#
Post by: Paul Squires on December 09, 2012, 01:25:53 AM
I am certanly no C# expert because I have only been using it for the past two weeks since the PB announcements started. It is my Plan "B". Everything in C# is OOP. Everything. It is easy to create procedural style code (as you know) by just creating a static class.

I am totally impressed with C# so far. I am converting one of my work programs from PB/FireFly over to C# (using SharpDevelop as the IDE) as a means of learning the language. There is an enormous amount of tutorials and examples on the web which is making the process pretty easy.

...it is wierd getting used to the curly braces and semicolons though.  :)

Title: Re: C#
Post by: Tom Cone Jr on December 09, 2012, 03:59:40 AM
Paul,

Why C# instead of VB.NET ?

-- tom
Title: Re: C#
Post by: Paul Squires on December 09, 2012, 04:57:57 AM
Quote from: Tom Cone Jr on December 09, 2012, 03:59:40 AM
Paul,

Why C# instead of VB.NET ?

-- tom

I considered VB.NET. A lot of the syntax is familiar.

I figured that if I was going to learn .NET programming then I may as well learn the most popular .NET language - therefore, I chose C#. The web has an incredible amount of C# support forums, documentation, examples, tutorials, books, add-ons, components, etc.

I had briefly considered Java. I looked at FreePascal.

Actually, learning C# has kind of got my programming juices flowing again. It's nice to be excited about programming again.

This is now my second week with C# and it is not hard to learn at all. Sure, the braces and semicolons take a bit of getting used to but after a short time it becomes second nature. Most the rest of the learning is simply learning the syntax for things you already know about like FOR/NEXT and WHILE LOOPS, etc.

C# is a fully enabled OOP language. The biggest learning for me is not C# but rather learning the .NET framework. There are sooooooooo many built in classes, methods, properties, namespaces... that just about anything you can think of doing has a corresponding .NET class to help - the problem is trying to find it. I'm getting pretty good with Google and MSDN searches.   :)
Title: Re: C#
Post by: Tom Cone Jr on December 09, 2012, 09:11:07 AM
Thanks, Paul.
Title: Re: C#
Post by: Patrice Terrier on December 09, 2012, 09:42:51 AM
My C# corner (http://www.zapsolution.com/DW/US/ccorner.html)

If i could have used the C# syntax without the .Net framework, then i would have switched for long, but you know as i am using mostly "unsafe" code (flat API)  i never used it for production.

...
Title: Re: C#
Post by: Carlo Pagani on December 09, 2012, 09:55:02 AM
I'm with you Patrice so I am looking at http://msdn.microsoft.com/en-us/vstudio/hh386302 because I too am not fanatical about .NET. I think it is a difficult decision to make!
Title: Re: C#
Post by: Patrice Terrier on December 09, 2012, 10:28:47 AM
Carlo

On the long term i think C++ is what make the more sense for a SDK coder, i already started to learn it two years ago, but delayed the big jump in the hope that we were close to a 64-bit version of PB.

I shall wait until the end of this month, but if nothing new, then perhaps we could go on from the VS2010 thread i have already started here:
http://www.jose.it-berater.org/smfforum/index.php?topic=3793.0

...
Title: Re: C#
Post by: Rick McNeely on December 09, 2012, 06:25:30 PM
I do like C++.  I took a course in it at my Community College.  But I REALLY like the platform independence of C#, especially when combined with wxWidgets.  Most of my applications are slowed by networks, database servers, etc..   Being hyper-fast isn't much of a benefit in situations like that.  You just spend more time waiting for some other process.

I've also been doing some Python work.  If better debugging were available, that could be an awesome language.  I wrote a Python application on my Windows 7 machine, copied it over to my CentOS box and it ran with zero modification.  The application uses sockets and an SQLite database.  That is pretty awesome.
Title: Re: C#
Post by: James C. Fuller on December 09, 2012, 09:34:29 PM
Paul,
  What C# compiler are you using?

James
Title: Re: C#
Post by: Juergen Pfisterhammer on December 09, 2012, 09:54:10 PM
Hello,

I use C# and Java within my daily work. They are ok. But the greatest features from PowerBasic such a low level programming and the speed are missing in my opinion. They both use an interpreter.

One alternative to PowerBasic is PureBasic. It has a 32 and 64 bit compiler for Windows / Linux and MacOSX. The compiler can compile Executables and Libraries.

But only a suggestion because I hope that PowerBasic goes on.
Title: Re: C#
Post by: James Klutho on December 10, 2012, 01:07:15 AM
My attraction to Powerbasic has been string handling, the forum for code help, and knowing for sure that any problem with my project was my fault and not the compiler's fault.  I bought a Purebasic license eons ago but never really used it.  The bug list on the forum would make my head swim, the forum was basically hobbyists, and the non standard basic syntax (like blitzbasic) was a big turnoff.  I guess if you needed a 64 bit dll it could be an option, but if my memory serves me, the dll handling was also screwy. Jim
Title: Re: C#
Post by: Paul Squires on December 10, 2012, 01:15:57 AM
Quote from: James C. Fuller on December 09, 2012, 09:34:29 PM
Paul,
  What C# compiler are you using?

James

I didn't realize that there were C# compilers other than Microsoft's. I am using SharpDevelop for the IDE.
Title: Re: C#
Post by: James C. Fuller on December 10, 2012, 10:35:33 AM
Paul,
  Maybe I should rephrase that. How did you acquire the C# compiler?
I assume because you do professional coding you have purchased one of the retail versions of Visual Studio?
For those with more modest means it seems the Express suite would be a possibility; but ( I assume again :)) you would then  have the same restrictions you have with the Express C++: No 64bit??

I found there is a free one:

http://www.mono-project.com/CSharp_Compiler

I think Patrice is on the correct path with C++.

I just uninstalled VS Express and installed Win7.1 SDK which includes the C++ compiler. I now can compile both 32 and 64 bit apps and dll's.


James
Title: Re: C#
Post by: Patrice Terrier on December 10, 2012, 11:41:19 AM
Patrice is currently trying to learn how to create a plain (flat API) Win32 DLL without MFC using VS2010.
Any tutorial welcome  :)

...
Title: Re: C#
Post by: Paul Squires on December 10, 2012, 12:48:27 PM
Hi James,

This is what I am using:

http://www.icsharpcode.net/opensource/sd/

I also have VS Express 2012 (free) installed on my main computer at home, however SharpDevelop allows me to install onto a USB or portable hard drive which is more convenient for me because I use my development tools on multiple computers.
Title: Re: C#
Post by: James C. Fuller on December 10, 2012, 01:10:59 PM
Quote from: Patrice Terrier on December 10, 2012, 11:41:19 AM
Patrice is currently trying to learn how to create a plain (flat API) Win32 DLL without MFC using VS2010.
Any tutorial welcome  :)

...

Patrice,
  See your c++ thread:
http://www.jose.it-berater.org/smfforum/index.php?topic=3793.0

James
Title: Re: C#
Post by: Rick McNeely on December 10, 2012, 05:20:26 PM
There ARE C# compilers besides the MS compiler.  See go-mono.net.  Linux, OSx, iOS and Android all have C# support now.  Gtk and wxWidgets are both supported for cross-platform GUI applications.
Title: Re: C#
Post by: John Strasser on December 12, 2012, 02:07:05 AM
Quote from: Rick McNeely on December 09, 2012, 12:32:59 AM
I don't have the benefit of working with other programmers.  Much less more experienced programmers.  So I have a question for those of you who have been working with object oriented languages.

When I view tutorials for C# and other object oriented languages, I get the impression that developers spend most of their time creating objects as well as utilizing existing objects, avoiding any significant procedural code like the plague.  But when I use C# (or C++) I find that I still write procedurally (perfectly cromulent word), while using existing objects and occasionally creating objects of my own. 

Is this typical?  Or should I be finding ways to further 'objectify' my code.


Rick,

Turning EVERYTHING into objects creates just as many problems as not having objects.  In short, being able to mix OOP and procedural code gives you the flexibility to have the program you're working on actually fit the task at hand.  Just as you can design data structures to fit your data, having  functions internal to the objects or (in C's case) polymorphism and inheritance and operator overrides, etc all are there to make your life easier.

Contorting yourself into knots to make the program fit the programming paradigm tells me you're using either the wrong language or using the right language wrong.

As for those creating everything into objects, what languages are they using and how are they using them?  If you're using a library like .NET that requires objects to be passed to various routines, then you need to create more objects.  If you're building tools, then objects let build conceptual frameworks around specific tasks and data that you can provide to others.

If you're developing end user software that is not designed to have other applications plug into it then any use of classes & oop (or any other programming paradigm) is purely for your own convenience.

Example:

Right now most of my programming is purely for my own internal use.  Which means that most of the "objects" I create are really just jazzed up data structures (structures & unions in C++ or User Defined Types in PowerBASIC) with constructors and destructors and very little else.

In the past when I was designing engineering systems I would often develop class libraries so that I could have (for instance) a unified set of tools for handling *whatever* (say pumps).  Then my software (which controlled say...I don't know...pumps?) could handle any pump I threw at it without having to re-write tons of code.  Because the screen display didn't care what type of pump I was working with, it just knew that it was looking for a pointer to an object of "type pump" and the object would then take over and display the proper information and controls.

Did I answer your original question in my long-winded way?  Or did you just pass out with boredom :D
Title: Re: C#
Post by: Rick McNeely on December 12, 2012, 04:06:05 AM
John,

You answered it!  And I kinda felt like i was going in a direction that made sense.  I do create objects for my own use.  Usually, as you said, they are just jazzed up data structures.  But sometimes they're full fledged objects.  But only when it makes sense.  Most of my efforts have been tying a bunch of  useful pre-existing objects together with procedural code.
Title: Re: C#
Post by: Fredrick Ughimi on December 15, 2012, 11:54:35 PM
Paul,

Quote
I am totally impressed with C# so far. I am converting one of my work programs from PB/FireFly over to C# (using SharpDevelop as the IDE) as a means of learning the language. There is an enormous amount of tutorials and examples on the web which is making the process pretty easy.

I have always been interested in learning C#. But I never had the time. I have also downloaded SharpDevelop (much smaller in size than VS.Net). Nice IDE. Thanks to the information you posted here. Here is the link for learning how to use the IDE.

http://community.sharpdevelop.net/blogs/mattward/pages/FeatureTour.aspx

Nice documentation.

Title: Re: C#
Post by: Steve Rossell on December 17, 2012, 10:10:07 PM
Since (semi)retiring from PowerBASIC last year I started doing some work in C# and WPF. I still write a mix of procedural and OOP code. I do try to avoid static classes as creating an instance of a class is very fast in C#. It does create more problems as John pointed out, such as removing all references to a class so the Garbage Collector can clean it up. I always thought that managed code would mean less work for the programmer, but it is just the opposite. The API and COM made it much easier to manage memory and object references. You just knew what needed to be cleaned up. Maybe I just have not been using it long enough to be comfortable with it yet.

Steve Rossell
Title: Re: C#
Post by: Patrice Terrier on December 17, 2012, 11:05:15 PM
Steve--

I have always been upset by the C# garbage collector, especially because even in managed mode i keep writing/using "unsafe" code, for the ease of portability.

...
Title: Re: C#
Post by: Theo Gottwald on December 17, 2012, 11:06:31 PM
Whatever tool you use long enough, you will use it with ease Steve.
Do you have any actual insight on the bussiness situation of our favourite compilers?
Or any personal opinion about it you want to share?
Title: Re: C#
Post by: Edwin Knoppert on December 18, 2012, 12:10:52 AM
There is a major difference between releasing objects and releasing resources.
Releasing objects is 'perfectly' done in .NET but releasing resources is something new to many people.
When an object gets out of scope or is set to null the memory for that object is released whenever .NET sees fit.
This is usually during the next instance of that object but minimally later than we 'return from the stack' as in other languages.
Just think of when the computer is idle, it doesn't matter...
The memory footprint is not an issue to all of us, it will be dealt with properly.

Unf. the destructor of an object is also called at that 'idle' moment and this way to late for sequential programming as we know it.
For example when you need to release a connection or datareader.
All such objects require the implementation of the IDisposable interface.
That is some annoying given but it is the way .net works.
What does that mean?
You'll need a real implementation like found here and not the silly single member VS inserts.

(the first example is ok)
http://stackoverflow.com/questions/6967108/is-idisposable-dispose-called-automatically

The impact on your programming will be to call the Dispose() member for such an object.
This whole part is barely discussed and is a trap for many starters imo.
.NET is all 'If you know how it is not a big deal'.

The need for calling dispose() can be a problem like when a call creates an exception for example.
Therefore always try to use the using() statement like:
using(class1 c = new class1())
{
    c.callme();
}

You'll have to verify every object you use from now on but in fact it has a benefit, all your code gets properly nested this way.
Imagine a database connection and commands and such.
They all have a dispose() and are closing themselves properly.
By using using() you'll have less code, no .close() and no .Dispose()

Much more on this:
http://www.codeproject.com/Articles/15360/Implementing-IDisposable-and-the-Dispose-Pattern-P
Title: Re: C#
Post by: Steve Rossell on December 18, 2012, 12:28:36 AM
I am sure I will become more comfortable as I go along. Not every object inherits from IDisposable. For example, I am working on an app that adds ands removes tabitems in code. I have to remove all the references to each control, unhook any event handlers, set Items to null (DataGrid with ObservableCollection), clear out the observablecollection and it's references. If this was not done the tabitem would be removed but the datagrid and other controls that still had references would not be Garbage Collected. I always using USING{} on disposable objects. It just seems like a lot more work and a lot of planning on what it will take to get an object 

Do not get me wrong. I enjoy it. C#, WPF, and XAML are very different then what I am used too. But, I am having a lot of learning something new.

I still do contract work for PowerBASIC, so I am not at liberty to give my personal opinion or any other company information. Sorry.

PowerBASIC is still my favorite language and I am positive the company will be around for a long time.
Title: Re: C#
Post by: Theo Gottwald on December 18, 2012, 07:56:33 AM
Thanks, Steve. Hope you are right.
About your view on that manged stuff ... i completely agree.
But we both know that there are people out there which are perfectly comfortable with that stuff.
I prefer PB where the compiler does all this automatically.
Title: Re: C#
Post by: Stan Duraham on December 21, 2012, 02:36:42 PM
Microsoft killing off Expression suite of Web and design tools
http://arstechnica.com/information-technology/2012/12/microsoft-killing-off-expression-suite-of-web-and-design-tools/

Title: Re: C#
Post by: Steve Rossell on December 21, 2012, 05:26:42 PM
Quote from: Stan Duraham on December 21, 2012, 02:36:42 PM
Microsoft killing off Expression suite of Web and design tools
http://arstechnica.com/information-technology/2012/12/microsoft-killing-off-expression-suite-of-web-and-design-tools/

I use Blend and VS 2012 Ultimate, so I guess this is saying that Blend will be part of the IDE after the next update?
I prefer to hand code the XAML, but sometimes use Blend when I do not know how to do it by hand.
Title: Re: C#
Post by: Theo Gottwald on December 23, 2012, 10:57:08 AM
QuoteThere is a major difference between releasing objects and releasing resources.

The point is that you may need to release stuff again.
Thats why is suggested something i have seen with other modenr languages.
That you can make a "Destructor" for a SUB or Function.
One that is always called no matter where or how you end the function/Sub.

But these are detail-topics. I remember that i have suggested things like that for future PB Versions.
Title: Re: C#
Post by: John Strasser on December 30, 2012, 04:28:51 AM
Quote from: Steve Rossell on December 18, 2012, 12:28:36 AM
I am sure I will become more comfortable as I go along. Not every object inherits from IDisposable. For example, I am working on an app that adds ands removes tabitems in code. I have to remove all the references to each control, unhook any event handlers, set Items to null (DataGrid with ObservableCollection), clear out the observablecollection and it's references. If this was not done the tabitem would be removed but the datagrid and other controls that still had references would not be Garbage Collected. I always using USING{} on disposable objects. It just seems like a lot more work and a lot of planning on what it will take to get an object 

Do not get me wrong. I enjoy it. C#, WPF, and XAML are very different then what I am used too. But, I am having a lot of learning something new.

And there you have the PITA aspect of OOP.  I've always found (when it comes to C++/C# at least) whenever you put anything into a class you then immediately put it in the constructor and destructor.  Even if it's just a code stub that will flag an error at compile time (so that you're forced to flesh it out).  This has often kept me out of (some) trouble.

But as for planning Steve, you're right.  If you get that right though, whoosh - you've got yourself a cool set of class libraries you can drop in almost anywhere.

PS - thanks for the links Edwin.