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));
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.