31
General Discussion / Re: Are modules always single level or is there any (future) concept of nesting
« on: November 29, 2018, 08:19:14 AM »
will do..
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
32
Implementation Details / Re: LLVM/C gen
« on: November 29, 2018, 08:18:50 AM »
What do you mean exactly? do you have a code reference for that?
33
Implementation Details / Re: Code formatting of C2's c++
« on: November 29, 2018, 08:17:55 AM »
We could have the analyser check that if either the if or else body has braces, that they both have. If not, just give an error.
I wouldn't really want to prevent developers from writing a short if/else and always require braces. It's a matter of style at
some point. On the todo-list is a clang-format like style program that styles C2 code. That tool could be used to check/fix
this as well. That removes it from the language and puts it in the style part...
I wouldn't really want to prevent developers from writing a short if/else and always require braces. It's a matter of style at
some point. On the todo-list is a clang-format like style program that styles C2 code. That tool could be used to check/fix
this as well. That removes it from the language and puts it in the style part...
34
Implementation Details / Re: Suppress warnings
« on: November 29, 2018, 08:13:29 AM »
The only warnings in C2 so far are unused decls/imports/etc, all other issues are just errors.
I don't like pragma's either, very ugly. But I also don't like abusing comments. I think all stuff related
to meta issues (like packed, etc) could just be attributes. So @(..). That way the language syntax
is still the same, but we just have to add some possible attribute points..
I don't like pragma's either, very ugly. But I also don't like abusing comments. I think all stuff related
to meta issues (like packed, etc) could just be attributes. So @(..). That way the language syntax
is still the same, but we just have to add some possible attribute points..
35
Ideas / Re: Switch proposal
« on: November 29, 2018, 08:08:56 AM »
Wow, that's a lot of posts in one day..
The case of
I want to simplify the language as much as possible, so I don't really want to change the current behavior too much. If you think
about the possible bugs that often occur is only that a develop forgets to add the break keyword. So the only needed option I
think is to add the fallthrough keyword and require that for all fallthroughs. So for example:
or maybe even allow empty cases to fallthrough without keyword to make code with lots of fallthrough's better readable
The case of
Code: [Select]
case 3| looks quite nice, but it differs from the case where you have some code, but also a fall-through.I want to simplify the language as much as possible, so I don't really want to change the current behavior too much. If you think
about the possible bugs that often occur is only that a develop forgets to add the break keyword. So the only needed option I
think is to add the fallthrough keyword and require that for all fallthroughs. So for example:
Code: [Select]
case 1:
break;
case 2:
fallthrough;
case 3:
fallthrough:
default:
// ...
or maybe even allow empty cases to fallthrough without keyword to make code with lots of fallthrough's better readable
Code: [Select]
case 1:
break;
case 2: // allowed because empty case
case 3:
fallthrough;
default:
// ..
36
General Discussion / Re: Discussions where?
« on: November 27, 2018, 10:01:59 AM »
I prefer the forum, although it doesn't look very nice. GitHub posts are closed after a while, and the forum stays..
37
General Discussion / Re: Are modules always single level or is there any (future) concept of nesting
« on: November 27, 2018, 10:00:55 AM »
I have played around with this, but wanted to avoid the hassle in Java where everything is nested 6 deep.
Since C did exist 40 yeas with a single level (ie the global namespace), having 2 namespaces already
seems like a big improvement. When programming in C2, there is never any hassle with clashing
module names, but I do use the convention of naming files somewhat after the module name. If a module
consists of multiple files if use: foo_utils, foo_api, etc
Since C did exist 40 yeas with a single level (ie the global namespace), having 2 namespaces already
seems like a big improvement. When programming in C2, there is never any hassle with clashing
module names, but I do use the convention of naming files somewhat after the module name. If a module
consists of multiple files if use: foo_utils, foo_api, etc
38
General Discussion / Re: Overwriting fields in init struct.
« on: November 27, 2018, 09:58:32 AM »
This depends completely on the situation. For some file_operations in linux, this might be a good option, but for generic
code, there are no good 'defaults' imho. What C2 did change already is to guarantee that every global is always initialized
by default. This avoids some silly mistakes.
code, there are no good 'defaults' imho. What C2 did change already is to guarantee that every global is always initialized
by default. This avoids some silly mistakes.
40
Implementation Details / Re: I found this about implementing C very interesting
« on: November 27, 2018, 09:53:43 AM »
Ha, yes so complex to parse correctly. Hence there are almost no great tools everyone uses
41
Implementation Details / Re: Code formatting of C2's c++
« on: November 27, 2018, 09:47:13 AM »
For if() statements I always follow the Linux kernel syntax:
- allow simple if statement
- allow single if() statement followed by simple else
- if either the if or the else part needs brackets, both should have them.
so this is NOT allowed:
Otherwise it depends on the code whether you want to use brackets or not for simple if's
- allow simple if statement
Code: [Select]
if (x) func();- allow single if() statement followed by simple else
Code: [Select]
if (x) func1();
else func2();
- if either the if or the else part needs brackets, both should have them.
so this is NOT allowed:
Code: [Select]
if (x) func1();
else {
//...
}
Otherwise it depends on the code whether you want to use brackets or not for simple if's
42
Implementation Details / Re: LLVM/C gen
« on: November 27, 2018, 09:37:23 AM »
Yes, I concur, I ran into the same issue. Since C2 and C are close relatives (and the Clang code served as an example in many
occasions), look at the Clang source code. Usually that's more complex than C2 needs, but it should contain the basics.
occasions), look at the Clang source code. Usually that's more complex than C2 needs, but it should contain the basics.
43
Implementation Details / Re: LLVM/C gen
« on: November 15, 2018, 09:24:21 AM »
The 2 back-ends are indeed worlds apart.
When starting with the back-ends, I needed one that was easy to write/debug to test with. That is the C back-end.
The generated C code is readable and can be easily checked.
The LLVM/Ir back-end is only in the initial phase. Generating code for this is more complex than C and also the result
is harder to check. When C2 started, LLVM was at 3.2 (I think). Since then, the API has changed a lot, so the 2nd
goal was to keep the contact layer between C2 and LLVM/Clang to a minimum, to be able to rebase easily. That has
proven to be very nice: most rebases take one-two hours.
In the end, the IR back-end will be the main one and we might even drop the C back-end if it becomes very hard to
map C2 functions to that one. It might be good fun to start integrating the IR back-end more and to really generate
an executable with that (for a small subset of the language at start). C2C currently just generated IR. What is missing
is calling LLVM for optimization passes and then generate binary code and link etc.
Language wise, the back-end is not important. So fleshing out the language itself is the highest priority. But it might be
fun to start doing something (like generating an executable)..
When starting with the back-ends, I needed one that was easy to write/debug to test with. That is the C back-end.
The generated C code is readable and can be easily checked.
The LLVM/Ir back-end is only in the initial phase. Generating code for this is more complex than C and also the result
is harder to check. When C2 started, LLVM was at 3.2 (I think). Since then, the API has changed a lot, so the 2nd
goal was to keep the contact layer between C2 and LLVM/Clang to a minimum, to be able to rebase easily. That has
proven to be very nice: most rebases take one-two hours.
In the end, the IR back-end will be the main one and we might even drop the C back-end if it becomes very hard to
map C2 functions to that one. It might be good fun to start integrating the IR back-end more and to really generate
an executable with that (for a small subset of the language at start). C2C currently just generated IR. What is missing
is calling LLVM for optimization passes and then generate binary code and link etc.
Language wise, the back-end is not important. So fleshing out the language itself is the highest priority. But it might be
fun to start doing something (like generating an executable)..
44
Ideas / Re: Switch statement
« on: November 13, 2018, 09:00:47 AM »
If you put a switch inside a while/for loop, continue currently means: jump to the next loop
45
Ideas / Re: Dynamic arrays & fixed arrays
« on: November 13, 2018, 09:00:02 AM »
When we put a feature like this in the language, there should be syntactic sugar that is the reward. Otherwise
it doesn't make sense. For example, we could do '+=' on the array to add items, etc. That way the calling code
is easy to read.
it doesn't make sense. For example, we could do '+=' on the array to add items, etc. That way the calling code
is easy to read.