The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

defining constants in multi-language projects

How do you avoid hard-coding constants in multiple locations when dealing with projects that use multiple languages?  For instance, my current project has parts written in C++, C#, VB.NET and SQL.  There are various constants that have to be shared between them (names of registry keys, numeric constants, stored procedure names, etc).  For the most part, I can define them once per language (with #define or a public static member or whatever), but is there any way to do it better?
It hasn't actually been a problem yet, but I would never write the same string literal multiple places within a single component, so I'm uncomfortable doing it across components.
bmm6o Send private email
Tuesday, February 07, 2006
 
 
Sounds like a good place for some text (ini, XML,...) config file that can be read by what ever needs to know
Honu Send private email
Tuesday, February 07, 2006
 
 
+1 to Honu.

I'd also take a real close look at each of these constants and decide if they have to be hard coded, shared constants. For example, you mentioned stored procedure names. Why?

So far, its been extremely rare that I'd ever need to call a stored procedure from more than two different places and if I ever needed to change the name, I also probably need to change the code that deals with the returned results.  In that case, I would just bite the bullet and recompile as opposed to dynamically passing it in via a parameter.

So far, the only things I'd make "external constants" are serial numbers (or license keys), machine specific info such as directory paths, performance tuning parameters and user preferences. As Honu said, XML is ideal for this sort of stuff.
TheDavid
Tuesday, February 07, 2006
 
 
What I did when I needed this functionality was to write a simple preprocessor that converted the set of constant definitions from one language into a class for the other language.  However, whether that's a viable solution for you rather depends on whether you can slot such a preprocessor into your build system.
Iago
Tuesday, February 07, 2006
 
 
Between C# and VB.NET a DLL is ok. Regarding SQL... hmm... you don't even have constants there (I miss PL/SQL). You could have a table which holds all the constants, but still they are not shared with C# and VB, unless you read them from the table at startup. Or maybe Yukon's CLR integration helps? About C++... try to consume the managed DLL where you store the constants for use from C# and VB (using C++/CLI or CLR hosting). Or make an unmanaged DLL and use P/Invoke from the other two. :-)
smalltalk Send private email
Wednesday, February 08, 2006
 
 
SWIG will read your C/C++ and generate the relevant Java, C#, Lisp, Python etc. counterparts. You can add another language yourself directly (a major undertaking); or, you can read it's XML dump of all the C/C++ structures, constants, and variables and generate it from there.

Doxygen does the XML generation part more or less the same most of the time.
Ori Berger Send private email
Wednesday, February 08, 2006
 
 
If SQL needs it, it's got to use a table, right?  So, you could start there and write a small - like, single select statement small - code generator that pulls from the table and generates the constants for each of the other languages from that.

If SQL's a small part of it, and if C++ for you means Managed C++, then it's all .NET and I'd just use a shared DLL with public static readonly members.
Chaz Haws Send private email
Wednesday, February 08, 2006
 
 
We had this exact same problem when I worked at Smith Corona. I used to be able to say "Set Left Margin" in 18 languages. We used configuration files to trigger a make process; if you have more than 8 bit microcontroller assembly language, I would recommend storing the "constants" in a metadata repository of some sort.
Steve Hirsch Send private email
Wednesday, February 08, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz