Vulcan CVS Tree - Jan 2004

From Jim Starkey on the Firebird Development List 30th January 2004

The code is very much a work in progress, and is released primarily for discussion. It is known not to build on any platform, and runs only in my imagination, and then only on good days.

If you would like to roll your makefiles, in the component directories there are files "modules.mak" and "dependencies.mak" with the important stuff. These are mechanically generated from the MSVC 7 project files *.vcproj by a master configuration file vulcan.conf. Vulcan.conf is obscure but available for your amusement.

There are two major new pieces, components "why" and "config". Why is the new Y-valve. Config is the object based configuration scheme and associated friends and relations. Unlike the old config file manager, this one is context (i.e. database) dependent, with the appropriate ConfObject handing off the database block (formerly dbb, now Database). Most, not all, configuration file references now have a trail back to the database block.

I'm generally happy with the implementation of the new configuration manager but have not reached any firm decisions re. the fine structure of objects and associated attributes. I have tried to maintain fairly strict backwards compatibility, even when I think the old scheme was particularly unwise. We should be able to include existing configuration files and have the right things happen. Attributes declared within an object will always take precedence over attributes declared globally.

Please note that no files include anything that is not required, but do contain everything that is required, save firebird.h. This policy covers both header and code files. All new header files declare referenced classes, but contain only the specific class being defined. There are no new proto.h files, and there will not be.

The configuration files are example of how I write C++. Simple code, no templates, no artificial datatypes. Then mean number of lines per method is probably under ten and the median about four (plus or minus blanks). I use blank lines to set apart branching code, and indentation that reflects the language structure of C++. I don't object to inlining, and there are methods that eventually will be declared inline, but for rapid development I like declarations in declaration files and code in code files. Silly, silly me.

New classes do not use pools, and are responsible for their own cleanup with destructors and/or addRef/release.

I am using JString where appropriate. I'm willing to substitute an equivalent string class if a better one becomes available. Do note that the current JString uses a 32 bit use count and has a less brain dead concatenate operator.

I am in the process of phasing out all code that uses the std library.

I haven't consistently added modules header boilerplate. All code is copyright Netfrastructure, Inc. and James A. Starkey. All virgin modules with be adorned with the IDPL. Modules contaminated with stuff cobbled from Interbase code with be Interbase Public License.