C BASIC

[kryton9]

Why aren't you guys using the c-basic-project source code site?

I put the code from the posts to here:
Charles's:
https://code.google.com/p/c-basic-project/source/browse/c_basic.h

John's:
https://code.google.com/p/c-basic-project/source/browse/john/Basic.c

I will put all my code later tonight to the site. Please start using it. You can
do it via the google interface for now.

[John]

My folder on Google Code contains what I wish to post at this point. It also contains files you posted I can't delete. I updated my README for the folder with where my head is at the moment with this project.

[kryton9]

John, I see you named it with a c extension. It should be a .h extension. I will delete the one I put up for you and link yours in my previous post.

[John]

I would prefer to maintain my own folder with no site default files.

[AIR]

Pushed a proof-of-concept C++ implementation.  Not ready for posting here, so please don't.

Read my readme text file.

A.

[kryton9]

I would prefer to maintain my own folder with no site default files.

John, don't understand what that means.
Tell me exactly what you want and I will do it for you.
Do it local on your computer take a screenshot with all trees expanded for your folder
and I can then duplicate that on the google code site for you.

[kryton9]

Pushed a proof-of-concept C++ implementation.  Not ready for posting here, so please don't.

Read my readme text file.

A.

Great will check it out! ... it looks like you are using c++ instead of c
underneath just glancing

Pushed a proof-of-concept C++ implementation.

I guess that said that it all. Neat looking for sure!

[John]

I would prefer to maintain my own folder with no site default files.

John, don't understand what that means.
Tell me exactly what you want and I will do it for you.
Do it local on your computer take a screenshot with all trees expanded for your folder
and I can then duplicate that on the google code site for you.

I don't think we need all the structure at this point as we are still getting started. Remember, we are doing this in our spare time and any additional steps or new things to learn is going to take away from the reason we all came to the party in the first place. Just do what you think will help the project. I don't want to scare anyone away making this too complex. The theme of this project is making things simple and adding all these layers are counter productive. IMHO

[kryton9]

Updated my folder here the first version of for_next
Now that I figured out a clear way to handle nested for loops,
I will converge the various FOR, FORS, FORR, FORRS into 1 FOR

I am trying a different route. Trying to make BASIC like syntax, but
even better than basic original if I can. As you see declaring variables
is at a minimum.

https://code.google.com/p/c-basic-project/source/browse/kent/for_next

Which standard of C are we trying to match?
3.2 K&R C
3.3 ANSI C and ISO C
3.4 C99
3.5 C11
3.6 Embedded C

[kryton9]

I have been reading about the different C standards. I guess C11 is not fully supported yet, but C99 has lots of cool things:

http://en.wikipedia.org/wiki/C99

I have had problems and this is why:
http://www.mingw.org/wiki/C99


For windows the only free compliant C99 compiler:
Pelles C   Full   Supports all C99 features.[22]
http://en.wikipedia.org/wiki/C99#Implementations

I was using c++ and mingw32 and codeblocks are outstanding for that, but not C,  I think its kind of funny.
Well a good reason to use Pelle C. http://www.smorgasbordet.com/pellesc/

update: My code gave warnings in mingw32 but compiled and ran fine. In PelleC I am getting many errors with the same code.

[AIR]

You should fix your warnings.

Have you tried defining USE_MINGW_ANSI_STDIO in your code?

BTW, itoa is NOT a part of the C standard.  I think it's mostly Microsoft-specific, but other compilers have it.  Not GCC on non-Windows platforms, though.

You can try your STR() as a function (just waking up, so quickly thrown together):

Code: [Select]

char* STR(int val){
    static char tmpStr[256]={0};
    int ret=0;
   
    ret = snprintf(tmpStr,256,"%d",val);
    if (ret){
        return tmpStr;
    }else{
        return strncpy(tmpStr,"",1);
    }
}
The above compiles with both gcc and g++ on my Mac.  Just a bunch of printf warnings, because of missing format specifiers in your code.

A.

[AIR]

Found a VERY cool utility call ACK.

It's like grep on steroids (grep is a *nix tool to search files for matching strings).

It's written in perl (which is ok on Windows too, because perl is installed with the Git Windows package) which makes it totally cross-platform.

I'm using it to create a Keywords.txt file, without having to manually type in the keywords, or cut and paste.

Here's an example, pulling the keywords out of #define statements:

Code: [Select]

ack '#define (\w+)' cppbas.inc  --output='$1'
And here is the output, ready for piping to a file:

MAIN
ENDMAIN
DECLARE
FUNCTION
ENDFUNCTION
DIM
AS
SUB
ENDSUB
BEGIN
END
AND
OR
CLASS
TYPE
ADDRESS
INCR
DECR
NEXT
PRIOR
BYREF
NOT
IF
THEN
ELSE
ENDIF
FOR
TO
STEP
SELECT
CASE
_TO_
ENDCASE
CASE_ELSE
ENDSELECT
WHILE
CONSTANT
STR
BOOL
integer
INTEGER
VECTOR
MAP
TRUE
FALSE

Now that only shows you your #defines.  What if you also created functions for this project, and wanted to output those including those with a return type identifier like "$" for strings?

Code: [Select]

ack '^FUNCTION \w+ (\w+.|\w+)' cppbasrt.inc  --output='$1''

REVERSE$
LTRIM$
RTRIM$
TRIM$
LEFT$
MID$
RIGHT$
INSTR
LCASE$
UCASE$
MCASE$
LOADFILE$
SPLITPATH$
ENC$
REPLACE$

And how about outputting the actual function prototypes?

Code: [Select]

ack '^FUNCTION (.+\))' cppbasrt.inc  --output='$1'

CSTRING REVERSE$(CSTRING src)
CSTRING LTRIM$ (CSTRING s)
CSTRING RTRIM$ (CSTRING s)
CSTRING TRIM$ (CSTRING s)
CSTRING LEFT$ (CSTRING s, INTEGER length)
CSTRING MID$ (CSTRING s, INTEGER start, INTEGER length)
CSTRING RIGHT$ (CSTRING s, INTEGER length)
INTEGER INSTR (CSTRING  s,CSTRING  match,INTEGER offset)
CSTRING LCASE$ (CSTRING str)
CSTRING UCASE$ (CSTRING str)
CSTRING MCASE$ (CSTRING S)
CSTRING LOADFILE$ (CSTRING N)
CSTRING SPLITPATH$ (CSTRING FPATH, INTEGER mask)
CSTRING ENC$ (CSTRING  A, INTEGER L, INTEGER R)
CSTRING REPLACE$(CSTRING subject, CONSTANT CSTRING& search, CONSTANT CSTRING& replace)

Having the ability to do this so easily will make it easier to document your keywords.

A.

[kryton9]

You should fix your warnings.

Have you tried defining USE_MINGW_ANSI_STDIO in your code?

BTW, itoa is NOT a part of the C standard.  I think it's mostly Microsoft-specific, but other compilers have it.  Not GCC on non-Windows platforms, though.

You can try your STR() as a function (just waking up, so quickly thrown together):

Code: [Select]

char* STR(int val){
    static char tmpStr[256]={0};
    int ret=0;
   
    ret = snprintf(tmpStr,256,"%d",val);
    if (ret){
        return tmpStr;
    }else{
        return strncpy(tmpStr,"",1);
    }
}
The above compiles with both gcc and g++ on my Mac.  Just a bunch of printf warnings, because of missing format specifiers in your code.

A.[/size]

Thanks AIR, but I am trying to go as far as I can with macros and defines. And the warnings I had were similar nothing to worry about warnings.
I got the errors not with gcc(not compliant with all standards), but with PelleC which is compliant with all C standards.

No one has responded to the standard we are all targeting. The standard will have a dramatic effect on what can be done.
For example read this, this morning from Herbert Schildt's "The Complete C Reference 4th Edition":

Perhaps the most important features added by C99 are the new keywords:
inline
restrict
_Bool
_Complex
_Imaginary
Other major additions include
• Variable-length arrays
• Support for complex arithmetic
• The long long int data type
• The //comment
• The ability to intersperse code and data
• Additions to the preprocessor
• Variable declarations inside the for statement
• Compound literals
• Flexible array structure members
• Designated initializers
• Changes to the printf( ) and scanf( ) family of functions
• The _ _func_ _ predefined identifier
• New libraries and headers
Most of the features added by C99 are innovations created by the standardization committee, of
which many were based on language extensions offered by a variety of C implementations. In a few
cases, however, features were borrowed from C++. The inline keyword and // style comments are
examples. It is important to understand that C99 does not add C++-style classes, inheritance, or
member functions. The consensus of the committee was to keep C as C.
Features Removed
The single most important feature removed by C99 is the ''implicit int" rule. In C89, in many cases
when no explicit type specifier is present, the type int is assumed. This is not allowed by C99. Also
removed is implicit function declaration. In C89, if a function was not declared before it is used, an
implicit declaration is assumed. This is not supported by C99. Both of these changes may require
existing code to be rewritten if compatibility with C99 is desired.
Features Changed
C99 incorporates several changes to existing features. For the most part, these changes expand
features or clarify their meaning. In a few cases, the changes restrict or narrow the applicability of a
feature. Many such changes are small, but a few are quite important, including:
• Increased translation limits
• Extended integer types
• Expanded integer type promotion rules
• Tightening of the return statement
As it affects existing programs, the change to return has the most significant effect because it might
require that code be rewritten slightly.

Thanks for the exporting routines in Perl!!

[John]

No one has responded to the standard we are all targeting.

Not true. It was stated early on that C BASIC core will be developed on all platforms using gcc/g++. Variations can do what they wish.

[kryton9]

But that doesn't specify the standard John, gcc is different levels of compliance on windows vs linux. I provided the links earlier.

Should we all develop in Linux via Virtual Machines or Direct if installed as such?