separate class files for namespaces

separate class files for namespaces

• Richard Tkachuk

  Thank you for the advice. I must confess that my first reaction is "aaaaggghhhhhh - another language!!!"
  I wrote numerical processing routines years ago in Fortran on a Dec mainframe as a graduate student - later Commodore Basic and a little 6502 assembly (wedges into Basic). For the last 10 years, most of my crunching work has been done in Mathcad. I can whip up a program pretty quick but it is painfully slow for large data volumes and a drag to deploy since you must have it installed on any computer that will use your application - expensive.
  Right now I have only VB.net 2003 & c++.net 2003 on my machine - no C#. I purchased the NR in C++  code just so I wouldn't have to re-code the same routines from C that I already had when I purchased the book & code about 20 yrs ago!!. I am not a C programmer either.
  Maybe I'll reconsider C# after trying a little harder with the VB.NET - C++.NET combo.
  Thank you for the leads to the blogs - I will check them out.
  Frankly, my progress is inhibited mostly in finding my way around the development environment in terms of code organization rather than code development. So many options...

  
  

• Carlos Tortajada

  Thank you for responding. Your reply is very helpful.
  
  By "Single translation unit" I mean simply a file of code. Or maybe the MyClass.h/MyClass.cpp file pair. At least this is the way I've seen it referred to in much of the literature & help files I've been perusing. Examples I see in the texts show a single file with a namespace keyword and several classes enclosed within the namespace brackets. For organizational purposes, I like to keep the individual classes coded in separate files.
  
  I am still very much a novice at this and the volume of options is a bit daunting.
  
  My intention is to develop (for myself and for limited deployment in the laboratory in which I work) utility applications in Windows that process measurements or models physical processes, data fitting and interpolation, etc. Mostly I will be writing user interfaces in Visual Basic using the Forms and controls classes backed up by number crunching done in the background in VC++. I've selected this approach for two reasons: the first is that I've already gained some experience in VB having written VBA macros in Excel & Autoccad and a suspicion (perhaps unfounded ) that the number crunching in VC++ will be faster than in VB; and secondly because I can obtain much C++ code commercially (e.g. Numerical Recipies) than in VB.
  
  So should I be using MFC or  .NET
  

• waltc

  Could you clarify your question What do you mean by "single translation unit"
  
  Namespaces are a logical organization of code and are unrelated to physical deployment. i.e. One DLL or assembly can contain one or more namespaces and a namespace can be spread across multiple DLLs or assemblies. By convention, it's a good idea to name DLL after the root namespace. e.g. System.Data.dll contains types in the System.Data (and child) namespaces.
  
  The decision to use a MFC library versus .NET assemblies is highly dependent on your application. If you're writing a MFC application, you could go either way. If you have no need for .NET, I would write it in MFC. If you are going to be using .NET, I would create a .NET assembly. Alternatively you can always write a standard C-style DLL with EXPORTS too. It all depends on what types of applications you plan to incorporate your code into. Given that I spend most of my time in .NET, I would write it using .NET since you can expose your functionality to a wide variety of languages that target the .NET Framework. You also get a rich base class library to implement functionality on top of.

  
  
  

• Owen T. Soroke

  Many years ago during my graduate work in Chemistry, I wrote similar types of applications. I wrote the applications in C/C++. Given this is the C++ Forum, I'll probably get myself flamed for saying this, but consider using C# rather than VB/C++. (I've done more than my fair share of VB/C++ COM professionally and it can be a very non-fun world to live in. Writing your C++ COM objects so that they can be utilized by VB6 is an art.) If you're going to be using VB.NET, I would just write everything in C#.
  
  What about numerical processing performance I can't afford to crunch large volumes data using a slow managed runtime. Think again. Managed doesn't necessarily mean slow. Check out http://blogs.msdn.com/ricom/archive/2005/02/22/378335.aspx, which gives you lots of great information about the performance characteristics of managed. (If you're intersted in .NET performance, read everything by Rico Mariani (http://blogs.msdn.com/ricom). For basic number crunching, managed can be as fast as unmanaged. I wouldn't use .NET for large quantum chemical calculations, but for your average data analysis tasks in a typical lab, it should work just fine.
  
  As for what to do with all your C++ numerical recipes You should be able to do a fairly sensible translation from the C++ version to the C# version after learning a bit more about C#. C# is very easy to pick up (in my opinion) if you already know another C-style language.
  
  
• separate class files for namespaces