C#

[Paul Squires]

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.

[James C. Fuller]

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

[Rick McNeely]

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.

[John Strasser]

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

[Rick McNeely]

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.

[Fredrick Ughimi]

Paul,

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.

[Steve Rossell]

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

[Patrice Terrier]

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.

...

[Theo Gottwald]

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?

[Edwin Knoppert]

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

[Steve Rossell]

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.

[Theo Gottwald]

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.

[Stan Duraham]

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/

[Steve Rossell]

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.

[Theo Gottwald]

There 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.