C# Moving up from C and Tcl/Tk to Visual C#

[berkeman]

Is there a good way to think about the namespace/object/class/method paradigm when transitionig from non OOP C programming to Visual C# programmig? I've written Tcl/Tk GUI apps for manufacturing test fixtures in the past, but now I need to interface with multiple VISA instruments with National Instruments Measurement Studio and Visual C#.

I'd just like to get a better overall intuition for how C# program structure works, and when I would think about classes, methods and so on.

Thanks for helping out with some intuitive keys...

 

[rbelli1]

Namespaces are very important to .NET. Pretty much everything is in its own namespace. This take a bit to get used to when transitioning from C. Once you get used to it it makes finding the thing you want much easier especialy with autocomplete.

Everything is an object. Well except for the integral types but there are objects for those too. You have to be careful when passing integral types where objects are expected. The compiler will transparently box those into objects and eat up your cycles. The everything is an object rule makes shooting yourself in the foot a lot harder.

Return references passed as parameters need to be explicitly made as such even when called (see out parameter modifier).

The good news is you no longer need header files. That cruft is done automatically.

There is enough syntactic sugar available to give an elephant diabetes. See using, yeild, foreach, async, var, properties. And those are only the ones I've stumbled upon in the minimal amount of programming I have done in C#.

One major gotcha I have found is that timers are completely asynchronous. If you have a timer that fires one a second and your handler takes more than a second you will have multiple threads in that timer function. You get called once a second whether you like it or not. Another is that the asynchronous functions such as the Begin... stuff for networking will complete synchronously if the condition is already satisfied on calling. Don't rely on the return value in the asynchronous handler. The documentation sort of alludes to that but there is no warning about it.

Mashing about on bytes is frowned upon in all non byte oriented data. This is more foot protection but can be a pain when moving from C where your access to data is basically god mode.

Basically you need to go full OOP with C#. Lasing off into procedural mode will make your life difficult.

BoB

 

[jedishrfu]

Here's some references that may help:

http://www.oracle.com/technetwork/java/codeconventions-135099.html

and

http://stackoverflow.com/questions/...e-for-package-naming-in-java-projects-and-why

At work we do something like this:

edu/com/org . company_name . your_division . app . client/server . name_of_app . whatever_organization_that_makes_sense_for_your_project

As an example, a computer aided instruction project might be organized as follows:

edu.txuni.mathed.app.tutor.client.display   // contains all display related classes
edu.txuni.mathed.app.tutor.messages         // contains classes related to messages passed between
edu.txuni.mathed.app.tutor.server.parser    // contains math equation parsing
edu.txuni.mathed.lib.calculus.parser        // contains classes related to parsing calculus expressions

The package naming comes into play during runtime when the JVM / ?VM is looking for a particular class to load so you want the package name to be unique to avoid collisions of simiarly named classes.

An example in Java, is the Logger class Oracle has one and Log4J has one and only the package naming keeps them apart.

 

[Mark44]

With regard to namespaces, C# is very similar to Java. In both languages you have a huge API set, several orders of magnitude larger than the C standard library or even the Standard Template Library (STL) in C++. Without knowing more details about what you need to do, it's difficult to point you in an appropriate direction. One of the features that @rbelli mentioned was asynchronous calls, which I think is tricky for newcomers to understand. Many classes have both synchronous and asynchronous versions of methods. When you use an asynchronous method, you provide a callback that gets fired when the asynchonous task is finished, but until that happens, other operations can be performed. With a synchronous method, your code is stalled until that method returns.

Mashing about on bytes is frowned upon in all non byte oriented data.

So is accessing data using pointers, but you can do it if you mark the section as "unsafe." Just for my own amusement I write some C# code that executes intermediate language (IL) bytecodes (essentially machine code for the virtual machine that is used in all of the .NET languages). One chunk of code, 12 bytes, calculated the larger of two numbers passed to the code. Another chunk, about 30 bytes, converted Fahr. temps to Celsius or vice versa, depending on the value of a boolean parameter.

Anyway, it's a big jump from C to C#. The main source of information about C# is MSDN (Microsoft Developer Network), the company that developed .NET and C#. If you have some specific questions, fire away. I am reasonably familiar with C#, having written code in it for about 10 years while working as MSFT.

 

[rbelli1]

mark the section as "unsafe."

There is a clue in the name of the keyword that may indicate why using it is best minimized.

BoB

 

[Mark44]

mark the section as "unsafe."

There is a clue in the name of the keyword that may indicate why using it is best minimized.

As mentioned, the code was for my own amusement.