Topics

1

Ideas / [Email suggestion No. 4] OS compatibility (layer) / libc2 || libc2core

« on: July 19, 2016, 10:30:06 AM »

   C and C++ are known for requiring a lot of work when one wants their code to be compatible with more OSes, generally to support Linux, Mac OSX and Windows. That usually translates to a lot of macros, especially many #ifdef _WIN32 ones.
   C2 is the evolution of C which aims to evolve all "the" bad or aged aspects of C. My suggestion is to create a library, which I could gladly do, called something in lines of libc2 or libc2core (since libc2 already exists, frankly), which would abstract the portability problems between POSIX-ish systems and systems like Windows, which are only partially POSIX-compliant (and aren't especially at places where it hurts the most) and throw in a few more functions/types/symbols to refresh the old libc, which is also aged.
   A great example is zed_net https://github.com/luciusmagn/zed_net by ZedZull, which handles the great incompatibility problems between using sockets in POSIX and Windows. The link is to my fork of zed_net, since the author frankly deleted the original repo for reasons unknown. In other words, the library itself could be like a libc extension and compatibility layer specifically made for C2. I would like to create it, if you like the idea, since I like making portable software.

2

Ideas / [Email suggestion No. 3] type casts in C2 + bugs

« on: July 19, 2016, 10:26:37 AM »

The current cast<type>(what); does not really fit into C2 syntax wise, since it implies generics and that is not something that fits in C2 as it is now. Bas proposed this syntax in an email a few months ago:

Code: [Select]

(->type)what
This could be much better and due to the arrow, more understandable to those who don't know how casts work beforehand.

casting bug 1: C2C parser completely ignores invalid C-style casts and interprets statements that use it as ones using implicit conversion

example:

Code: [Select]

int32 i = 10;
char c = (char)i;
I think that this syntax should result in an error or at-least warning about C-style casts. Frankly, I know that C-style casts are hard to parse, so I am not sure how easy or hard that is to implement

casting bug 2: C2C does not work properly when I do intentionally a bad thing like this:

Code: [Select]

int32 i = 10;
char d = cast<char>(d); //undeclared identifier error
I think that the proper behavior should be issuing a message/error/warning about using uninitialized variable or casting to itself.

3

Ideas / [Email suggestion No. 2] libraries and build system suggestions

« on: July 19, 2016, 10:23:46 AM »

The introduction of the library system was a great addition which basically turned C2 from an interesting toy that proves some improvement concepts to an interesting usable language. However, there could be some tiny additions make it easier to work with:


2.1 Allow targets to specify additional, perhaps local to the project, C2 libs directory. In C and C++, it is also common to have more include paths, so allowing something like this:

Code: [Select]

target trg
     $generate-c
     $libdir ./myotherinterfacefiles
     file1.c2
     file2.c2
end
could be a great addition to the library system.

2.2 Ability to recognize a prefix in in .c2i files. When there is a header that exposes the following functions:

Code: [Select]

void thislib_function1();
void thislib_function2();
void thislib_function3();
Then typing it as thislib.thislib_function1(); in C2 is not nice on the eyes. My suggestion is to the use of a prefix value in the toml manifest file for the library in the following manner:

Code: [Select]

//manifest file for the thislib
[library]
language = "C"
prefix = "thislib_"

Code: [Select]

[[modules]]
name = "thislib"
header = "thislib.h"

Code: [Select]

//thislib.c2i
func void thislib_function1();
func void thislib_function2();
func void thislib_function3();
In other words, the .c2i files would still contain the prefix, but when used in C2 code, one would use thislib.function1(); which is shorter and more sane.

4

Ideas / [Email suggestion No. 1] macros in C2

« on: July 19, 2016, 10:21:29 AM »

It has been stated in previously that macros need to be changed and not like the ones in C/C++, since those were limited/impacted by the age in which C and C++ were created in. When I was playing with Rust, which is a great programming language with some oddities (like filenames having significance in code, odd build system, variables immutable by default etc.), I stumbled upon Rust's macros, which are a great part of the language I otherwise think is okay, but not overly great. This is how a macro in Rust looks

Code: [Select]

macro_rules! foo {
    (x => $e:expr) => (println!("mode X: {}", $e));
    (y => $e:expr) => (println!("mode Y: {}", $e));
}

The following macro would be then used as:

Code: [Select]

foo!(x => 5); or foo!(y => 10);
because this example uses Rust's pattern matching. I think that a modification of Rust macros, suited for C2's cause, could be a good way how macros could work. Here is a simple suggestion of rules C2 macros could follow:

• Each starts with keyword like macro, followed by name and the content of the macro.
  
• The content may be either single value/statement or a mutiple lines of stuff in {} brackets.
  
• Macros are multi-line by default, no need to use \ to extend number of lines
  
• Macros must contain parse-able C2 code
  
• When used, an exclamation mark ! must be added to the name of the macro and semicolon at the and as if it was a regular statement. example macro:
  

Code: [Select]

macro myassert(desc, test) {
    tests_ran++;
    if (!(test)) {
        char* error;
        asprintf(&error, "[%s:%d]\x1b[31mTEST FAILED\x1b[0m: %s\n",__FILE__, __LINE__, desc);
        asprintf(&finalmessage, "%s%s", finalmessage, error);
    }
    else {
        char* success;
        tests_passed++;
        asprintf(&success, "[%s:%d]\x1b[32mTEST PASSED\x1b[0m: %s\n", __FILE__, __LINE__, desc);
        asprintf(&finalmessage, "%s%s", finalmessage, success);
    }
}
Which could then be used as

Code: [Select]

myassert!("Test if 1 == 1", 1 == 1);
Of course, this is just a simple suggestion, it is just an idea how fitting and readable yet distinguishable macros could work in C2.