RE: New version of The Electric VLSI Design System

[Hans-Jochen Trost]

Steven,

I've come farther late yesterday, and am where I was before with
version 6.06.  The answer to your question is: __BORLANDC__ (double
underscores front and back), and I agree, that is the cleanest way of
doing things.

In graphpccode.cpp, I'll use this:

     #ifdef __BORLANDC__
     #include <utime.h>
     #else
     #include <sys/utime.h>
     #endif

In network.h, I'll add this:

     /* HJT 030709 - Put two-argument operator delete functions
        under different flag.  Original use is "#ifndef MACOS". */
     #if defined(MACOS) || defined(__BORLANDC__)
     #define NO_PLACEMENT_DELETE
     #endif

and in network.h and network.cpp, I'll replace

     #ifndef MACOS

with

     #ifndef NO_PLACEMENT_DELETE


The two-argument operator new is indeed used as a placement new (in
network.cpp; see, e.g., Scott Meyers "More Effective C++", items 4 and
8).  I have not seen a two-argument operator delete USED anywhere
which makes me suspect that some compilers may just ask for its
presence because of the two-argument operator new.

I have made the two-argument operator delete disappear as I suggested.
Some minor gymnastics are needed with the electric.rc file also, the
line

     FONT 8, "MS Sans Serif", 0, 0, 0x0

for the "About Electric" dialog needs to have (some or all of) the
arguments following the font name removed.  This makes the compilation
succeed at that point, i.e., it does not show any ERRORS.

However, when I then try to start the program, I get the following
errors right away:

   The instruction at "0x00535ddc" referenced memory at "0x00000014".
The memory could not be "written".    (I click on OK to terminate the
program.)
   The instruction at "0x00535ddc" referenced memory at "0x00000014".
The memory could not be "written".    (I click on OK to terminate the
program.)
   The exception unknown software exception (0xc0000027) occurred in
the application at location 0x7c4ff0ac.   (I click OK to terminate the
program.)

Then the program finally terminates.  I am reporting this for the
Borland users more than strictly for you - there are some who have
asked me in response to my post of yesterday.

Where do we go from here?  I have tried to compile the release
version, remembering that trying the debug version with 6.06 lead to
"missing" source code, i.e., I couldn't find some stuff.  I've told
the compiler anyway to not optimize and to include debug information.
The memory location 0x14 in the error message is very strange, way too
close to 0x0 to be likely correct/intended.  There is still a
trainload of warnings from the compiler which I will go through and
see if there are serious ones among them.  Badly or undefined macro
names may be among them, and such could explain the suspicious address
0x14.  So I'd say, you just sit back to wait and see if I manage to
get further than this.  If I do, I'll post it here.  Maybe another
endeavoring Borland user can pick up the ball and help, in particular
someone who is more versed with modern debuggers than I am - my habits
reflect accumulated practices of the past 31 years and thus will look
old-fashioned to many.

Cheers,            Jochen

> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden
> Behalf Of Steven Rubin
> Sent: Wednesday, July 09, 2003 8:01 PM
> To: address@hidden
> Cc: address@hidden
> Subject: RE: New version of The Electric VLSI Design System
>
>
>
> >I am going at it again, trying to compile electric with Borland
> >Builder 5.  I found two small things in graphpccode.cpp, and
> got stuck
> >in logeffort.cpp.
> >
> >graphpccode.cpp:
> >
> >1.  I have <utime.h> but not <sys/utime.h> and simply assume
> that this
> >substitution will work.  The compiler is happy with it.
> >
> >2.  There is (again or still) an odd-spelled sizeof call in
> >gra_initdialog:
> >
> >         for(i=0; i<dialog->items; i++)
> >         {
> >                 itemlengths[i] = (sizeof DLGITEMTEMPLATE) +
> 3 * (sizeof
> > (WORD));
> >                 itemtype = dialog->list[i].type;
> >
> >i.e., the DLGTEMPLATE needs to be in parentheses just as WORD is in
> >the same line.
> >
> >                 itemlengths[i] = (sizeof (DLGITEMTEMPLATE))
> + 3 * (sizeof
> > (WORD));
>
> These two fixes are certainly the right thing to do.  Is
> there a "BORLAND"
> #ifdef that can be used in the first case?
>
> >The compiler is unhappy with network.h as used here.  It complains
> >about the various overloaded "operator delete" declarations in the
> >NetXXXX classes, i.e., it cannot distinguish the two versions:
> >
> >         void* operator new( size_t size );
> >         void* operator new( size_t size, CLUSTER *cluster );
> >         void operator delete( void* obj );
> >#ifndef MACOS
> >         void operator delete( void *obj, CLUSTER *cluster );
> >#endif
> >
> >This looks very much like a non-standard operator delete to me.
The
> >two-argument operator new (a "placement new") does not have a
> >"symmetric" two-argument delete, and defining one this way creates
an
> >operator delete that would behave differently from the one defined
in
> >the standard.  (Borland does know an OPTIONAL second argument for
> >operator delete, of type size_t.)  The proper way to do a delete on
a
> >placement new allocation is to do an explicit destructor
> call followed
> >by an "operator delete[]" call for the raw memory.  It looks to me
> >like trying to extend the MACOS solution in this regard to all
> >supported platforms would alleviate the situation.
>
> Once again, the existence of a BORLAND #ifdef can make the
> code work right
> in all cases.  Let me know how it turns out.
>
>     -Steven Rubin
>
>
>
> _______________________________________________
> Discuss-gnu-electric mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/discuss-gnu-electric