-=> On 28 May 96  16:23:02 Tom Brown said to Andrew Grillet <=-

Hi Tom,


 TB> My problem with point 2 is that the code I wrote to handle this (3 C++
 TB> classes: Profile, ProfileSection, and ProfileEntry) really bloat out
 TB> my code.  The first 2 classes inherit from ISequence, which makes them
 TB> fairly expensive in terms of code size.  The OS/2 API adds roughly
 TB> nothing to my executible size and probably executes faster.  BTW, I
 TB> would be happy to share this code with anyone who is interested.
 
 AG> Perhaps you could offer it to the DevCon program.

 TB> I would, but I'm not sure that it would be appropriate for widespread
 TB> use.  The source is quite small (it creates about 23K of object code),
 TB> but a simple test application that does nothing more than instantiate
 TB> this object ends up being 120K (this is with /EXEPACK:2).  For my
 TB> part, all I care about is programming productivity.  The code is fast
 TB> and easy to use.  Frankly, though, if IBM sent me this code, I would
 TB> think that it was pretty bloated.

Well, submitted with appropriate docs, someone might be tempted to improve on
it and re-submit. 
 
 TB> I have C code to do most of this, as well.  The problem with C is that
 TB> it is not as nice to work with.  

That depends on the circs. I feel a need for both C and C++ versions myself. 
Some things have to be in C for contractual reasons (cleints don't wish to
retrain) or to minimise changes to existing projects. Others are best in C++. 

Personally, I will be likely to continue using C for ever, even if I use
C++ 90% of the time (at present I doubt its 10%).

 TB> I wanted something that was object oriented.  
 TB> A profile is a container of sections and a section is a
 TB> container of entries.  

 TB> My thinking is that C++ makes this sort of thing very easy to work
 TB> with (for me), because it makes it easier to think about (for me).  As
 TB> best I can tell, my biggest problem is that TProfile and
 TB> TProfileSection inherit from ISequence.  This makes them _BIG_.  

Not necessarily a disadvantage though. The code will only be loaded when in
use, otherwise swapped out. Large code may be bettert han no code.

 TB> They are suprisingly fast.  In fact, they execute much faster than my C
 TB> code which stores nothing in memory, it reads the file every time it
 TB> looks up an entry.  Of course, I think that the C code adds less than
 TB> 10K to my application and speed has never been a problem.  Its just
 TB> that the C stuff seems more complicated.  For me the whole value behind
 TB> C++ is being able to hide complexity.
 
 
 AG> Submitting to DevCon would make your stuff the 'Dev Facto'
 AG> standard, since few programmers would not have access to it. 

 TB> I'm flattered, but I'm not sure that my code is up to DevCon speed. 
 TB> Its quite complete, but if I got some code which added this little
 TB> functionality and made the .EXE this much larger, I would think that
 TB> the guy had written a bloated piece of crap.  This is why I'm not sure
 TB> that its up to DevCon speed.

As I said previously, submit the source, and wait for others to improve on it. 
Sooner or later, they will, and you benefit from the improvements, both in
performance, and in learning the solution to the problem.

 TB> Now, I want to add the ability to find out where the .EXE was executed
 TB> from and default to this path.  This is Mike Bilow's idea and it seems
 TB> to be a good one.  I'm still struggling with figuring out how to
 TB> implement it, though.  

I have done this in DOS by using the program name as passed as argument[0].
AFAICR, this is the full name with path and extension, and not the form
physically used to start the prog, but I might be wrong.

There is also an OS/2 API DosGetCWD(). 

 TB> On the bright side, I would imagine that 20 or
 TB> so lines of C code to add this function will not make any noticeable
 TB> difference on the size of my executable.  :)

My client is in MM, so we use the MMOS2 environment variable, and the .INI file
is always in the MMOS2 base directory it points to. 

There is an issue where you have more than one OS/2 on your machine, eg English and
German OS/2. Here you want to use the relevant .INI file, which means that
you want it relative to where you booted, and NOT relative to where you start the
prog from. There is also the possibility of a shared network installation
for which users will want their own .INI files.

I consider an override by command line option or something is essential if
you use the execution path.  One practial solution is to look in the CWD, and if
not found, look in the program's startup directory.

Andrew 
... Ooops!...Got my floppy caught in my PKZipper...
--- Blue Wave/Max v2.12 OS/2 [NR]