[IGSTK-Developers] Borland compiler and StateMachine macro; tcon on Thursday

[Kevin Cleary]

Hi all:

I would agree with Luis in this case (well I guess I tend to agree with Luis
in general)

I don't think it is critical that we support all compilers

As for the tcon tomorrow, I am in Barcelona and do not have an access to a
touch-tone phone to call in on - at my hotel they just have analog lines -
so I may not be able to participate - I will ask Kevin Gary to run the tcon
- note that we plan to do it at 2 pm tomorrow instead of the usual 1 pm time


I would like to be sure that at least Luis, Julien, David, and Sohan and
Hee-su can participate - please let us know if you can't

Thanks

Kevin
  
------------------------------------------------------------------
Kevin Cleary, Ph.D.                        Work phone: 202-687-8253
Associate Professor                        Work fax: 202-784-3479
Deputy Director  
                            
Imaging Science and Information Systems (ISIS) Center
Department of Radiology                    Pager: 202-901-2033
Georgetown University Medical Center       Cell phone: 202-294-3409
2115 Wisconsin Avenue, Suite 603           Home phone: 301-299-0788
Washington, DC, 20007                      Home fax: 301-299-0789
 
ISIS center: www.isis.georgetown.edu
Research group: www.caimr.georgetown.edu
WashCAS: www.washcas.org
Email: cleary at georgetown.edu
-------------------------------------------------------------------

-----Original Message-----
From: igstk-developers-bounces at public.kitware.com
[mailto:igstk-developers-bounces at public.kitware.com] On Behalf Of Luis
Ibanez
Sent: Tuesday, April 19, 2005 12:33 PM
To: Julien Jomier
Cc: igstk-developers at public.kitware.com
Subject: Re: [IGSTK-Developers] Borland compiler and StateMachine macro



Hi Julien,


Given the central role of the State Machine on the toolkit
I rather not put a dummy variable on it just to cover for
the poor implementation of the Borland compiler.


I would rather drop support for Borland altogether...


Maybe a less invasive option is to put a "typedef"
(instead of having an extra byte)... something like


#ifdef __BORLAND__
   // This variable is added to support broken bcc compiler
   typedef char BorlandIsABadCompilerType;;;
#endif


Again, given the critical nature of IGSTK we should
continuously evaluate how much are we willing to convolute
the code just for supporting an extra compiler...



Put in perspective:  We are facilitating the use of broken
compiler for developers to write Image Guided Surgery
applications...    there is something wrong about that.

Is like helping patients to reuse defective syringes...



    Luis



--------------------
Julien Jomier wrote:

> Hi Luis,
> 
> bcc doesn't like the extra line either...
> 
> I propose to add the following lines at the end of the macro:
> 
> #ifdef __BORLAND__
>   // This variable is added to support broken bcc compiler
>   char mydummychartypeforbcc
> #endif
> 
> What do you think?
> 
> Julien
> 
> Luis Ibanez wrote:
> 
>>
>> Hi Julien,
>>
>> Thanks for looking into the Borland errors.
>>
>> This is interesting, specially since an empty
>> statement (e.g. an isolated ";" is supposed to
>> be acceptable anywhere...
>>
>> I wonder if Borland will be happier with:
>>
>>   private:
>>      ;
>>
>>
>> meaning that we add a couple of empty lines
>> to the declaration of the Macro.
>>
>> or... another option if to put an #ifdef BORLAND
>> in the macro...
>>
>> If you have a chance, could you please give it
>> a try to the extra blank line and let us know
>> what you find ?
>>
>>
>>    Thanks
>>
>>
>>      Luis
>>
>>
>> --------------------
>> Julien Jomier wrote:
>>
>>> Hi all,
>>>
>>> I was looking at the compiling error on bcc32 and found out that 
>>> Borland compiler doesn't like:
>>>
>>>   private: ;
>>>
>>> The problem comes from the macro
>>>
>>> igstkStateMachineMacro();
>>>
>>> This macro ends by: 'private:' so the semicolon at the end causes bcc 
>>> to report an error.
>>>
>>> We have two options (AFAIK):
>>>
>>> 1) write:
>>>   igstkStateMachineMacro()
>>>
>>> instead of
>>>
>>>   igstkStateMachineMacro();
>>>
>>> 2) Add something like: 'char dummy' at the end of the macro...
>>>
>>> I prefer the second option and maybe there is another alternative,
>>> let me know what you think,
>>>
>>> thanks,
>>>
>>> Julien
>>>
>>> _______________________________________________
>>> IGSTK-Developers mailing list
>>> IGSTK-Developers at public.kitware.com
>>> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
>>>
>>>
>>
>>
>>
>>
>>
>>
> 
> 
> 



_______________________________________________
IGSTK-Developers mailing list
IGSTK-Developers at public.kitware.com
http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers