[futurebasic] Re: [FB] FBtoC feature request

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : July 2011 : Group Archive : Group : All Groups

From: Robert Purves <listrp@...>
Date: Sat, 23 Jul 2011 17:02:30 +1200
Waverly wrote:

> 	• A request for enumeration/constants to retain their names upon translation
> Code is easier to debug and translation task are easier when the original constant names are present.
> If the constant identifiers have to mangled or modified slightly to avoid namespace clashes, it is still clearer than having a number.
>  
> select thisValue
>   case _someMeaningfulName : fn doSomething1…
>   case _aGoodSoundingName   : fn  doSomething2…
>   case _aStupendousName         : fn doSomethin3g…
> end select
>  
> // synthesized FB output
> If ( gSelectLongExpr[1] = 26 )
> {
> doSomething1;

> // desired FBtoC output
> If ( gSelectLongExpr[1] = someMeaningfulName )
> {
> doSomething1;
> }

Yes, those magic numbers in the translated C code are most undesirable. 

Technically it would be easy to translate
    _foo = 42
as
    enum { foo = 42 };
and then emit 'foo' instead of 42 in the translation.
But constants like this
    _kCFNetDiagnosticConnectionUp = -66559
must not be emitted as an enum, because kCFNetDiagnosticConnectionUp is already known to the compiler. Marking all such constants as 'no-enum' would possibly be a impracticable task, and certainly a huge one.


There is a little-known option that, among other things, shows the values of constants as comments near the place of definition. Build this, and examine the .c file:

'--------------------
override _kFBTranslateComments = _true 

_foobar = 42

begin enum
_foo
_bar
end enum
'--------------------

We don't go out of our way to advertise the _kFBTranslateComments option. It works, sort of...
// A comment
/* another comment */
' yet again

Such comments are indeed passed through to the translation, but their placement can be amusingly wrong. No bug reports are sought on this matter.

Robert P.