I've also updated the Makefile to support MinGW.
in the example demo.cc, INSTR(mystring,"is") gives 2 as the answer, where mystring = "This is a string."
FreeBasic and QB64 give 3 as the answer.
Hi Johann,
We eventually build a MacOS binary using GTK. But the experience is bellow normal. GTK works best on Linux, other platforms, including Windows, are not comparable with native applications.
I'm having some issues with our Mac used to build it, but I hope to have some binaries soon.
For the future we expect to have a native MacOS driver functional. It is a contribution from Eric Wing, but there is no time frame for a stable release. He needs help by the way.
Best,
Scuri
FYIQuoteHi Johann,
We eventually build a MacOS binary using GTK. But the experience is bellow normal. GTK works best on Linux, other platforms, including Windows, are not comparable with native applications.
I'm having some issues with our Mac used to build it, but I hope to have some binaries soon.
For the future we expect to have a native MacOS driver functional. It is a contribution from Eric Wing, but there is no time frame for a stable release. He needs help by the way.
Best,
Scuri
The reference to needing help must have eluded you.
It appears that FreeBasic and QB64 are using an index that starts at "1" for their instr command (and other string commands), where as Jade is using a "0" based index.
It appears that FreeBasic and QB64 are using an index that starts at "1" for their instr command (and other string commands), where as Jade is using a "0" based index.
Actually, it appears that every BASIC I am aware of uses 1 as a starting index in its string evaluation functions like Left, Right, Mid, Instr, InstrRev, Tally, etc. with 0 being reserved to indicate the absence of target value in the string being evaluated. Sorry but I would regard a zero based target position in a string a weird abnormality and an unjustifiable deviation from the traditional BASIC syntax in a particular dialect.
This is a proof of concept using a BASIC-like syntax to program C++.
Jade isn't BASIC. ;D
undef?
AIR, often one needs to know if there is no occurrence of the substring, how does your instr function handle that?
If you try this, you will see that it returns a '-1'.
Jade isn't BASIC. ;D
Probably not but your casual and definitive "Jade is using a "0" based index" raised questions immediately from at least three BASIC-ers. Doesn't that ring the bell? ;D
But not for people using other languages.
A$ = ""
IF MID(A$,69,3) = "AIR" THEN
Code: [Select]A$ = ""
IF MID(A$,69,3) = "AIR" THEN
TRUE in JADE returning -1.
But not for people using other languages.
Armando, you telling this to me?! There's been nothing else but C/C++ for me to code in for decades! ;D
Code: [Select]A$ = ""
IF MID(A$,69,3) = "AIR" THEN
TRUE in JADE returning -1.
#include "../include/jade.hpp"
MAIN
STRING mystring = "This is a string.";
if ( INSTR(mystring,"not")) THEN
PRINT ("yes, substring found");
PRINT (STR$(INSTR(mystring,"not")));
END
if ( INSTR(mystring,"is")) THEN
PRINT ("yes, substring found");
PRINT (STR$(INSTR(mystring,"is")));
END
if ( 0 ) THEN
PRINT ("no substring found");
PRINT (STR$(INSTR(mystring,"no")));
END
PRINT ();
ENDMAIN
obviously the last IF clause is not going to be executed, it's just for illustration of what the first clause should be
AIR, I must disagree with your designCode: [Select]#
STRING mystring = "This is a string.";
if ( INSTR(mystring,"not")) THEN
PRINT ("yes, substring found");
PRINT (STR$(INSTR(mystring,"not")));
END
Note to all: There is no BASIC parser with Jade. It's more of a "snake-oil salesman" approach, in that it's a thin veneer of sorts over CPP. So, some things may not work as you may be accustomed to with a "proper" BASIC.
... you need to think more along the lines of how CPP would do something vs BASIC.
Quote... you need to think more along the lines of how CPP would do something vs BASIC.
If one new exactly how CPP would work under particular circumstances, why would one ever need a translator from a non-compliant (i.e. heavily RTFM'ed) and relatively shallow BASIC-like syntax to the incongruously richer C/CPP paradigm in the first place?
However what I'm saying is in no way meant as mockery at your pet project. Have fun! FWIW it may be just a first step to yet another full-fledged BASIC-to-CPP translator on the market. :)
What would make the most sense for someone coming from a BASIC background?Code: C++
"BASIC-like" does NOT suggest compliance. Since there is no "official standard", "compliance" is ultimately a subjective thing. And that's not my goal, anyway.
In the end, what matters is if a given implementation allows you to produce the desired result with the least friction.
Jade actually started as a re-write of MBC, I just thought I'd share what I've come up with towards that end.