[IGSTK-Developers] Borland compiler and StateMachine macro

[Julien Jomier]

Hi Luis,

I think this is the correct solution to the problem.
There are so many things that the developers should do right anyways. We 
are talking about the developers and not the users of the toolkit, so to 
me it is ok.

Let me know if I should check in the modifications,

Julien

Luis Ibanez wrote:
> 
> Julien,
> 
> Another option is to drop the
> 
>            "private: "
> 
> Keyword inside the Macro, and stablish the
> rules that:
> 
> 
> 
> A) the state machine macro must be the first
>    on the class declarations
> 
> 
> B) a "public, protected, private" must be
>    placed just after the macro.
> 
> 
> 
> My only concern with this solution is that
> we rely on developers to remember to do the
> right thing...     but.. maybe that's good
> enough given that we have the code reviews.
> 
> 
> 
>    Luis
> 
> 
> ----------------------
> Julien Jomier wrote:
> 
>> Hi Luis,
>>
>> I completely agree with you! :)
>>
>> So here are some issues:
>>
>> 1) We cannot put the #ifdef __BORLAND__ #endif inside the macro 
>> beacuse the compiler doesn't like it.
>>
>> 2) Definitively, bcc doesn't like multiple semicolons...
>>
>> Should we skip the #ifdef/#endif statement? or do you have other ideas?
>>
>> I think it's still ok to support bcc32 since the compiler can find 
>> strange errors in the code. However it shouldn't be used in the OR :)
>>
>> Julien
>>
>> Luis Ibanez wrote:
>>
>>>
>>>
>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
> 
> 
> 
> 
> 
>