case sensitive compiler
case sensitive compiler
Hi,
to make the C users feel more comfortable when using FBC, the compiler should have an option to make it work case-sensitive.
This is what I've done. The patch is on the SF page as a RFE entry ( https://sourceforge.net/tracker/index.php?func=detail&aid=1222310&group_id=122342&atid=693199 ).
Have fun with it ...
Regards,
Mark
PS: Where's the "Patches" page of this project?
EDIT: Just want to mention it: This patch also allows the compiler to compile itself in case-sensitive mode.
to make the C users feel more comfortable when using FBC, the compiler should have an option to make it work case-sensitive.
This is what I've done. The patch is on the SF page as a RFE entry ( https://sourceforge.net/tracker/index.php?func=detail&aid=1222310&group_id=122342&atid=693199 ).
Have fun with it ...
Regards,
Mark
PS: Where's the "Patches" page of this project?
EDIT: Just want to mention it: This patch also allows the compiler to compile itself in case-sensitive mode.
-
- Posts: 341
- Joined: May 27, 2005 7:01
- Location: Canada
- Contact:
you know doing that goes agaist basic Standers. incredibly there is such a thing. anyways one of basic defining charaterists has been that it case insenitive.
also case senitivity would really throw fb over the edge and truely make hulium statement that FB is C in a clown suit true. and that statement was made becasue pointer existed in FB.
so i think case senitivity would be just to much for us moderits to tollerated and the hardliners who already think fb blaspmis to basic would freak even more. so i can't really see this patch making it into the main stream distro.
also there is some legitiment resons not to have case senitivity. for one idotic programmer get it into there head it a good idea to name mutiple varible by the same name but with different case's making code a near nightmare to fallow.
also case senitivity would really throw fb over the edge and truely make hulium statement that FB is C in a clown suit true. and that statement was made becasue pointer existed in FB.
so i think case senitivity would be just to much for us moderits to tollerated and the hardliners who already think fb blaspmis to basic would freak even more. so i can't really see this patch making it into the main stream distro.
also there is some legitiment resons not to have case senitivity. for one idotic programmer get it into there head it a good idea to name mutiple varible by the same name but with different case's making code a near nightmare to fallow.
That's the reason why I did it. However, the case-sensitivity must be switched on explicitly. Therefore: no change for all users that don't want this feature.Shadowwolf wrote:also there is some legitiment resons not to have case senitivity. for one idotic programmer get it into there head it a good idea to name mutiple varible by the same name but with different case's making code a near nightmare to fallow.
Sorry, I'm not Mark Sibly.relsoft wrote:mjs = Mark Sibly ?
Regards,
Mark
-
- Posts: 341
- Joined: May 27, 2005 7:01
- Location: Canada
- Contact:
Perhaps the contributor comes from the Unix world, where everything is case-sensitive?
In any case, I would not recommend following this suggestion. I like to have FB as compatible as possible with QB.
BTW, in the QB editor, when the user changes the capitalization of a variable, all occurrences of the same variable are changed. It would be nice to have this feature in the IDE (if it is not too much complicated to program...)
In any case, I would not recommend following this suggestion. I like to have FB as compatible as possible with QB.
BTW, in the QB editor, when the user changes the capitalization of a variable, all occurrences of the same variable are changed. It would be nice to have this feature in the IDE (if it is not too much complicated to program...)
I would love case sensitivity (as an option, of course... to appease all these delerious BASIC addicts :). Does the patch include changes to make the preprocessor case sensitive? I'll try the patch once I get back to my dev computer. If v1ctor doesn't like the patch, I'll volunteer to maintain a separate branch that allows case sensitivity... (that's a hint to accept it, please... :)
Re: case sensitive compiler
COOL !mjs wrote:Hi,
to make the C users feel more comfortable when using FBC, the compiler should have an option to make it work case-sensitive.
This is what I've done. The patch is on the SF page as a RFE entry ( https://sourceforge.net/tracker/index.php?func=detail&aid=1222310&group_id=122342&atid=693199 ).
Have fun with it ...
Regards,
Mark
PS: Where's the "Patches" page of this project?
EDIT: Just want to mention it: This patch also allows the compiler to compile itself in case-sensitive mode.
Have to test it out.
IMHO It should be added to the compiler code (if it works fine...).
I know, I know it's not the BASIC way, but hey, this only expands the possibility of fb. It's an option, you don't have to switch it on if you don't like it.
BTW suppose that from now on Vic anyway adds a lot of things to fb that are not BASIC - just to add certain functionality to fb that he wants to use in the future ;)
Thanks Mark, I like it.
One thing though:
how to use your patch file, and which fb file version is needed?
The patch is an input file to use with the GNU 'patch' program ( http://www.gnu.org/software/patch/patch.html ) - just do 'patch <patch_file_name.patch' in the proper directory. patch is part of the GNU diffutils, a win32 port of which is available from the mingw project.
BTW, it seems the tracker for patches is no longer visible; I guess v1ctor disabled it?
BTW, it seems the tracker for patches is no longer visible; I guess v1ctor disabled it?
I don't think it's a good idea, sorry..
Say you have a case-sensitive header, used with your case-sensitive library, would you impose case-sensitiveness to all your users? While you can add alias to function prototypes, that can't be done with global vars. If you declare constants and other symbols taking the sensitiveness into account, they won't work either if the user forget a command-line option (too easy to forget) or an OPTION.
Case sensitiveness + implicit variables allocation = mess. foo Foo FOO FOo will be all different automagically-allocated variables.
The context-sensitiveness is the worst part of QB, IMO, and yet i had to add more to support escape-sequences and to remove keywords that clash with bad-designed libraries.
Hand-translated headers could stop working too, the Win API ones, SDL etc.. i'm not going to mess with that..
Without an IDE with auto-completion that supports include files, and without a "strict" name convention like in say Java, case-sensitive functions, types and (later) classes will become a nightmare if you have to look up the headers all the time when something stops compiling 'cause the function starts with say a capital letter, because the author followed his own convention.
Say you have a case-sensitive header, used with your case-sensitive library, would you impose case-sensitiveness to all your users? While you can add alias to function prototypes, that can't be done with global vars. If you declare constants and other symbols taking the sensitiveness into account, they won't work either if the user forget a command-line option (too easy to forget) or an OPTION.
Case sensitiveness + implicit variables allocation = mess. foo Foo FOO FOo will be all different automagically-allocated variables.
The context-sensitiveness is the worst part of QB, IMO, and yet i had to add more to support escape-sequences and to remove keywords that clash with bad-designed libraries.
Hand-translated headers could stop working too, the Win API ones, SDL etc.. i'm not going to mess with that..
Without an IDE with auto-completion that supports include files, and without a "strict" name convention like in say Java, case-sensitive functions, types and (later) classes will become a nightmare if you have to look up the headers all the time when something stops compiling 'cause the function starts with say a capital letter, because the author followed his own convention.
Yes, this patch also affects the preprocessor. However, the normal BASIC keywords aren't affected.DrV wrote:I would love case sensitivity (as an option, of course... to appease all these delerious BASIC addicts :). Does the patch include changes to make the preprocessor case sensitive? I'll try the patch once I get back to my dev computer. If v1ctor doesn't like the patch, I'll volunteer to maintain a separate branch that allows case sensitivity... (that's a hint to accept it, please... :)
And yes, it's optional and turned off by default.
Too bad.v1ctor wrote:I don't think it's a good idea, sorry..
EDIT2: I don't think that's a problem. Users that use case-sensitive modules must use case-sensitivity too. After some time a good (?) naming style will be forced *g*.
EDIT: I'll create a final patch of all my changes and instead focus on a PB -> FB translator.
EDIT2: It doesn't make sense to fight against the world because the world will always win ... :-(
Regards,
Mark
You must ask yourself one question: what in God's name is the benefit of case-sensitivity? In my opinion, it only adds room for human error and doesn't speed up anything, by any means. Name one situation where you'd need two variables with the same human-readable name, but separated only by capitalization.
Also, I don't want to start anything with anyone. I'm in agreement with v1c: he brings up perfectly valid points. I also agree that the BASIC languages are not meant to be case-sensitive, or we wouldn't have all the different capitalizations for FreeBASIC ;-) (Or might it be freeBASIC, or FreeBasic? Anyone?)
Also, I don't want to start anything with anyone. I'm in agreement with v1c: he brings up perfectly valid points. I also agree that the BASIC languages are not meant to be case-sensitive, or we wouldn't have all the different capitalizations for FreeBASIC ;-) (Or might it be freeBASIC, or FreeBasic? Anyone?)
-
- Posts: 680
- Joined: May 28, 2005 1:11
- Contact: