Albrecht Schlosser wrote:
>>      2) Convert the few C++ style comments to C style.
>>         This won't be hard, as there aren't too many.
>>         I've already done this, and can check it in if need be.
>>
> +1 for #2: If there is one compiler that doesn't like this, there may be
> more. Fixing this in an general way for all compilers is better than
> adding special options for one compiler.

        Agreed -- will check that in later today.

>> Also: some of the files that probably should be .h files are named .H
>> eg. FL/filename.H is #included by numericsort.c
>>
>> So strictly speaking, anyone working on filename.H won't really have a clue
>> (by the filename extension) that this file needs to be C format compliant.
>>
>> Should filename.H be changed to filename.h?

        BTW -- just noticed filename.H #includes Fl_Export.H,
        so Fl_Export.H is in this category as well.

> If it's wrong, then it should be fixed. IMHO that's all to it.
>
> And if we don't decide to change all header files to .h (lower case 'h'),
> then we should be consistent and have all c header files with ".h".

        Agreed, though I'll bet this impacts other stuff as well..
        configure, Makefiles..

        I think I'll leave the case/name changing up to folks wiser than I.
        I'll just handle the comment tweaks, so that SGI will build.

        The filename extension problem has maybe been in there long enough
        to qualify as a "charming wart"..? ;)

        I'm trying to remember why we use the C compiler at all.
        I'm naively thinking it should /all/ compile with C++,
        I must be forgetting something. We don't care about xforms anymore..
_______________________________________________
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev

Reply via email to