Hi,

I am learning C#, having a good C background as a programmer.

I need to port a C application to C#, but there is a very basic problems that stalls me.

My C program has many subroutines, each of them in its own file. They share a common .h include file, that holds various definitions and global variables.

Since C# does not use include files, my first idea is to define a specific namespace for all the routines and global variables that will mimic the C ones.

I would imagine something like in a "aProgram.cs" file:

#define aDefinition 3

namespace C
{
	int aGlobalVariable;
	double *aNotherGlobal;

	void SubRoutine1()
	{
		SubRoutine2();
	}
}

My problem is that I don't want to have all the C subroutines to be included is the same .cs file. There are to many of them for that to be practical.

But if I create a second "aProgram_2.cs" file like:

namespace C
{
	Void SubRoutine2()
 	{
		aGlobalVariable = 2;
	}
}

SubRoutine1() is not able to access SubRoutine2(), and SubRoutine2() cannot access aGlobalVariable, nor aDefinition;


How can I create a pool of routines and variables (and #define items) that will be accessible from different "cs" files?

Hi BobFX! Welcome at DaniWEB!
C certainly still has it's merits. But C evolved to C++ and C# for a reason. You should try to make a mindshift here. C# has no variables, it has "fields". C# has no subroutines it has "methods". Everything in C# is a class. If you needed the string of the integer 42 you could even write 42.ToString(), because the literal number 42 is an integer class and you can invoke the method ToString() of that class.
Now I don't know the exact design of your C code, but if at all possible you should try to make some classes out of it. This is not easy, but if you think some routine looks more like an "apple", put it in an apple class, if it looks more like an "orange" put it in an orange class.
Hope I'm a bit clear, if not, just ask.:)

Given the code sample and question, you only need to declare the methods static within a class and you can reference/call them anywhere as long as you establish a reference within your project and call the method by it's fully qualified name. For example:

namespace MyNameSpace
{
    public class MyMathMethods
    {
        public static void MyMethod1()
        {
            Console.WriteLine("doing something in MyMathMethods.MyMethod1()...");
        }
        public static void MyMethod2()
        {
            Console.WriteLine("doing something in MyMathMethods.MyMethod2()...");
            string s = MyStringMethods.MyMethod1();
            Console.WriteLine("call to MyStringMethods.MyMethod1() returned: " + s);
        }
    }
    public class MyStringMethods
    {
        public static string MyMethod1()
        {
            return "MyStringMethods.MyMethod1() called...";
        }
        public static string MyMethod2()
        {
            return "MyStringMethods.MyMethod2() called...";
        }
    }
}

You could define these in different namepace's within the same file too (this is NOT typical way to organize namespaces, but perfectly legal):

namespace MyMathNamespace
{
    public class MyMathMethods
    {
        public static void MyMethod1()
        {
            Console.WriteLine("doing something in MyMathMethods.MyMethod1()...");
        }
        public static void MyMethod2()
        {
            Console.WriteLine("doing something in MyMathMethods.MyMethod2()...");
            string s = MyStringNamespace.MyStringMethods.MyMethod1();
            Console.WriteLine("call to MyStringNamespace.MyStringMethods.MyMethod1() returned: " + s);
        }
    }
}
namespace MyStringNamespace
{
    public class MyStringMethods
    {
        public static string MyMethod1()
        {
            return "MyStringMethods.MyMethod1() called...";
        }
        public static string MyMethod2()
        {
            return "MyStringMethods.MyMethod2() called...";
        }
    }
}

And, if you wanted to separate them (namespaces) into separate files (this IS typical way to organize namespaces):

// in MyMathNamespace.cs file
namespace MyMathNamespace
{
    public class MyMathMethods
    {
        public static void MyMethod1()
        {
            Console.WriteLine("doing something in MyMathMethods.MyMethod1()...");
        }
        public static void MyMethod2()
        {
            Console.WriteLine("doing something in MyMathMethods.MyMethod2()...");
            string s = MyStringNamespace.MyStringMethods.MyMethod1();
            Console.WriteLine("call to MyStringNamespace.MyStringMethods.MyMethod1() returned: " + s);
        }
    }
}
// in MyStringNamespace.cs
namespace MyStringNamespace
{
    public class MyStringMethods
    {
        public static string MyMethod1()
        {
            return "MyStringMethods.MyMethod1() called...";
        }
        public static string MyMethod2()
        {
            return "MyStringMethods.MyMethod2() called...";
        }
    }
}

It's really easy in C# to reference libraries using namespaces as you would using '#include "header.h";' in c, but in C# you can separate the classes into various files and just use the same namespace without having to include a header file for each class as is typical to do in c/cpp. This flexibility allows you to focus on the objects within the library without the need to worry about what header files you need to include and, obviously, the need to setup any path information for each header file.

I did not include any class variable declarations above, but the accessibility and principles are the same, except that it is standard practice to use properties to get/set variables (and necessary practice where multi-threading is a concern).

Edited 6 Years Ago by DdoubleD: n/a

Hi BobFX! Welcome at DaniWEB! This is not easy, but if you think some routine looks more like an "apple", put it in an apple class, if it looks more like an "orange" put it in an orange class.
Hope I'm a bit clear, if not, just ask.:)

Thanks for the welcome, and for the guideline about C# programming.

Given the code sample and question, you only need to declare the methods static within a class and you can reference/call them anywhere as long as you establish a reference within your project and call the method by it's fully qualified name. For example:

And, if you wanted to separate them (namespaces) into separate files (this IS typical way to organize namespaces):


It's really easy in C# to reference libraries using namespaces as you would using '#include "header.h";' in c, but in C# you can separate the classes into various files and just use the same namespace without having to include a header file for each class as is typical to do in c/cpp. This flexibility allows you to focus on the objects within the library without the need to worry about what header files you need to include and, obviously, the need to setup any path information for each header file.

I did not include any class variable declarations above, but the accessibility and principles are the same, except that it is standard practice to use properties to get/set variables (and necessary practice where multi-threading is a concern).

I understand, thanks for the examples.

But what I'm looking for is a way to split the methods of a given unique class into different .cs files, and avoid to have to fully qualify each method and class variable.

If I take your MyMathNamespace example, I would like to have a first .cs file with:

// in MyMathNamespace.cs file
namespace MyMathNamespace
{
    public class MyMathMethods
    {
        public static void MyMethod1()
        {
            	Console.WriteLine("calling MyMethod2 from MyMathMethods.MyMethod1()...");
		MyMethod2();
        }
        
    }
}

and a second .cs file with:

// in MyMathNamespace.cs file
namespace MyMathNamespace
{
    public class MyMathMethods
    {
       
        public static void MyMethod2()
        {
            Console.WriteLine("doing something in MyMathMethods.MyMethod2()...");
            
        }
    }
}

but that does not work. I get an "The namespace 'MyMathNamespace' already contains a definition for 'MyMathMethods'" error message.

I need that because my C core has scores of subroutines, and I don't want to rewrite each of them with fully qualified calls.

The C core application needs to continue to live and evolve, and I would like to be able to just drop new versions of it into the new C# one, the C# part being used exclusively for the GUI, and for accessing an API that only exists in C# (or C++).

I'm actually on the fence about using C++ or C#. C# will be much easier for the GUI and the new API, but if I can't solve the problem above, I will need to use C++ instead.

Edited 6 Years Ago by BobFX: n/a

This question has already been answered. Start a new discussion instead.