121
Ideas / Re: Function inside function
« on: September 24, 2018, 12:20:16 PM »
Features like this are not used very often in C and do make a language more complex than needed. So it was removed.
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.
122
Ideas / Re: Keyword "func" - redundancy?
« on: September 24, 2018, 12:19:34 PM »
If the func keyword was completely redundant it would have been removed indeed. The keyword does make it a lot
easier on the parser. For a human it probably looks redundant. I was initially thinking about 3 keywords for globals:
type, func and (var?). That way it's completely obvious. Many new languages use something like this because making
stuff utterly obvious is usually a good thing. I did not add the (var?) keyword, because I felt that all variables should then
use it; so also local variables. This make the function bodies less easy to read, so now types and functions have a
keyword and variables don't.
easier on the parser. For a human it probably looks redundant. I was initially thinking about 3 keywords for globals:
type, func and (var?). That way it's completely obvious. Many new languages use something like this because making
stuff utterly obvious is usually a good thing. I did not add the (var?) keyword, because I felt that all variables should then
use it; so also local variables. This make the function bodies less easy to read, so now types and functions have a
keyword and variables don't.
123
Ideas / Re: Readability of keywords "uint32", "float64" etc
« on: September 24, 2018, 12:15:51 PM »
C2 started out with the short versions (u8, etc), then returned to versions. After a while, this didn't feel right, so it was changed back to the short
versions. In the end, it takes a bit of getting used to, but it is easier on the eyes. This is the same as Rust btw.
Encapsulation at compile time level does not exist anymore at all, since the C2 compiler has a different unit of compilation. Having no
headers avoids a lot of issues and increasing the unit of compilation also allows some pretty nice features.
versions. In the end, it takes a bit of getting used to, but it is easier on the eyes. This is the same as Rust btw.
Encapsulation at compile time level does not exist anymore at all, since the C2 compiler has a different unit of compilation. Having no
headers avoids a lot of issues and increasing the unit of compilation also allows some pretty nice features.
124
General Discussion / Re: State of progress?
« on: July 15, 2018, 09:24:39 PM »
C2 is definitely not going as fast as I would like, but it's definitely not dead either. Work and family life does
take a big toll on available time. Luckily it's already quite usable, so people (me included) can play around
with it to get a feel and evaluate it for parts that could be improved.
Parts where C2 still needs developers:
- LLVM IR generation
- inline assembly support
- some tooling (syntax highlighting, style formatting)
take a big toll on available time. Luckily it's already quite usable, so people (me included) can play around
with it to get a feel and evaluate it for parts that could be improved.
Parts where C2 still needs developers:
- LLVM IR generation
- inline assembly support
- some tooling (syntax highlighting, style formatting)
125
Ideas / Re: What about initialization in conditions?
« on: June 27, 2018, 09:01:32 AM »
Currently in C++ it's possible to do (using pointer now)
This compiles to the exact same thing. So each iteration, p is assigned a value from a call to getPointer().
So this call could have an internal iterator state and return NULL once it's done. These type of constructions
are also used in clang itself because they lower the scope of p.
Code: [Select]
while (Ptr* p = getPointer()) {
..
}
This compiles to the exact same thing. So each iteration, p is assigned a value from a call to getPointer().
So this call could have an internal iterator state and return NULL once it's done. These type of constructions
are also used in clang itself because they lower the scope of p.
126
General Discussion / Re: Struct "inheritance"
« on: June 27, 2018, 08:57:23 AM »
struct 'inheritance' in already possible in C by just having the other struct as (first) member.
Also, you can already have object-oriented like features by adding function pointers in a
struct (also in C). Those two cover you example already..
Also, you can already have object-oriented like features by adding function pointers in a
struct (also in C). Those two cover you example already..
127
General Discussion / Re: Complex numbers
« on: June 25, 2018, 09:00:29 AM »
Since C2 is a descendant of C and has no symbol-mangling, function overloading (multiple functions with same name bit with different arguments)
is not supported. I recently looked at Zig (ziglang.org) a bit and they allow putting functions on many constructs, like types, enums etc. This could
also be implemented in C2..
is not supported. I recently looked at Zig (ziglang.org) a bit and they allow putting functions on many constructs, like types, enums etc. This could
also be implemented in C2..
Code: [Select]
type Color enum u8 { Red, Green, Blue }
func bool Color.isRed(const Color* color) {
return *color == Red
}
128
General Discussion / Re: Struct "inheritance"
« on: June 25, 2018, 07:53:02 AM »
I think your proposal would complicate the language and create more corner cases. The only thing gained would be
that instead of a.data.name a developer could use a.name. Right?
that instead of a.data.name a developer could use a.name. Right?
129
General Discussion / Re: Why the module restriction on struct functions?
« on: June 25, 2018, 07:46:55 AM »
I agree with your extension idea. When compiling C2 code, the compiler has a global view
of the code (ie not per-file, but the whole lib/binary). Thus there can never be multiple functions
with the same name. This also goes for struct functions. While it would be possible to let other
modules add functions to a struct; these functions would have to be globally unique.
This does not have to be a problem, but the error message might be an indication for the developer
to refactor some code..
of the code (ie not per-file, but the whole lib/binary). Thus there can never be multiple functions
with the same name. This also goes for struct functions. While it would be possible to let other
modules add functions to a struct; these functions would have to be globally unique.
This does not have to be a problem, but the error message might be an indication for the developer
to refactor some code..
130
Ideas / Re: What about initialization in conditions?
« on: June 23, 2018, 07:29:29 AM »
Making the scope of variables smaller is always a good thing.
C2 currently already supports the (C++) syntax of
So in terms of formal syntax, this means
instead of
While making the scope smaller is nice, we also should try toallow avoid complex constructions like
because this makes the code unreadable. Maybe a single decl would be a middle way that
covers most situations and avoids excess complexity..
C2 currently already supports the (C++) syntax of
Code: [Select]
while (Height h = getHeight()) {
..
}
So in terms of formal syntax, this means
Code: [Select]
while ( decl/expr ) {
instead of
Code: [Select]
while ( expr ) {
While making the scope smaller is nice, we also should try to
Code: [Select]
while ( u32 x = get(), u32 y = getY(); x < y && x > 0) {
because this makes the code unreadable. Maybe a single decl would be a middle way that
covers most situations and avoids excess complexity..
131
General Discussion / Re: Why the module restriction on struct functions?
« on: June 23, 2018, 07:14:40 AM »
When a struct (Type) is defined in some module, it makes sense to also place the operations on
that type in the same module. This way, they are automatically shared between all users of that module.
Also it prevents ambiguity, that there can only be one function named x for that type. So there can
never be a A.x() in one module and B.x() in another.
that type in the same module. This way, they are automatically shared between all users of that module.
Also it prevents ambiguity, that there can only be one function named x for that type. So there can
never be a A.x() in one module and B.x() in another.
132
Implementation Details / Rebased on clang-60
« on: March 28, 2018, 08:43:13 PM »
C2C is now based on LLVM/Clang 6.0. The port was rather easy and took 20 minutes (excluding time to build LLVM/Clang).
The only nasty thing was a shift in arguments in include/clang/Basic/DiagnosticSemaKinds.def. This gives runtime asserts,
but luckily one of the unit tests broke, so it was very easy to detect and locate.
The performance seems to be the same and I've noticed no other differences. The clang binary does seem to have grown
another 5MB (87 -> 92 MB), all nice features I'm sure
The only nasty thing was a shift in arguments in include/clang/Basic/DiagnosticSemaKinds.def. This gives runtime asserts,
but luckily one of the unit tests broke, so it was very easy to detect and locate.
The performance seems to be the same and I've noticed no other differences. The clang binary does seem to have grown
another 5MB (87 -> 92 MB), all nice features I'm sure
133
Implementation Details / cross-compilation using build file
« on: March 22, 2018, 10:27:54 PM »
I've recently added the concept of a build file to C2. I would like to explain some design choices here.
The C2 compiler used to use a single configuration file called the recipe. The recipe describes:
for embedded systems where cross-compilation is a basic need, it should be easy to do. To handle
this, there now is a build file that specifies:
to isolate cross-builds between different targets. No need for sysroot like constructs.
The general idea is that the recipe file is written by the develops of the project. If the project has a lot
of configuration options (which could change the files that need to be compiled), a 'make menuconfig'
like tool could generate this.
The build file is either written by users or generated by a 3rd party build system like yocto/buildroot etc
The same recipe could be used to build for different targets by using a different build file for each.
To demonstrate this, the C2-examples archive has a working example for Ubuntu 17.04. See the README.md
for instructions.
Future work
Currently C2 uses a <triple> subdirectory in each library directory, so it can hold libraries for multiple targets.
This is handy for now, but in a real system, an (external) build system will already have populated a sysroot-like
directory with all required libs. So this directory will be removed in the future.
Another step will be to add a Cargo-like (from Rust) tool that reads the recipe, downloads all required libraries and
generates the build file.
Cross-compilation for ansi-C is quire a hassle. Hopefully C2 can make this a lot easier.
For more documentation see http://c2lang.org/site/build_system/intro/
As always, other ideas/feedback is welcome.
The C2 compiler used to use a single configuration file called the recipe. The recipe describes:
- which targets and type (executable or library
- which source files for each target
- the configuration options
- some output options (whether to generate-c, deps, refs, etc)
- which libraries the targets depend on
for embedded systems where cross-compilation is a basic need, it should be easy to do. To handle
this, there now is a build file that specifies:
- The target triple (eg arm-unknown-linux-gnueabi or x86_64-unknown-linux-gnu)
- A list of library search directories
- toolchain settings for the C-backend
to isolate cross-builds between different targets. No need for sysroot like constructs.
The general idea is that the recipe file is written by the develops of the project. If the project has a lot
of configuration options (which could change the files that need to be compiled), a 'make menuconfig'
like tool could generate this.
The build file is either written by users or generated by a 3rd party build system like yocto/buildroot etc
The same recipe could be used to build for different targets by using a different build file for each.
To demonstrate this, the C2-examples archive has a working example for Ubuntu 17.04. See the README.md
for instructions.
Future work
Currently C2 uses a <triple> subdirectory in each library directory, so it can hold libraries for multiple targets.
This is handy for now, but in a real system, an (external) build system will already have populated a sysroot-like
directory with all required libs. So this directory will be removed in the future.
Another step will be to add a Cargo-like (from Rust) tool that reads the recipe, downloads all required libraries and
generates the build file.
Cross-compilation for ansi-C is quire a hassle. Hopefully C2 can make this a lot easier.
For more documentation see http://c2lang.org/site/build_system/intro/
As always, other ideas/feedback is welcome.
134
Ideas / Struct Function declaration
« on: April 15, 2017, 09:22:04 PM »
With the current syntax, I think it's quite unclear when a function is a struct function. I would
like to try to make this more explicit. So hereby some ideas.
I like the last option best. The two arguments against it are:
What do you think?
like to try to make this more explicit. So hereby some ideas.
Code: [Select]
func void point_add(Point* p, int32 x) { .. } // current syntax
func void Point_add(Point* p, int32 x) { .. } // allow Upper-case as first char, so looks more like type Point
func void point_add[Point](Point* p, int32 x) { ..} /// hmm, 3 points in a row..no
func void point_add(Point* p, int32 x) @{structfunc} { ..} // via attribute
func void point_add(Point* p, int32 x) @{struct='Point'} { ..} // via attribute, nr 2
func void Point.add(Point* p, int32 x) { .. } // most explicit, via member operator
..
I like the last option best. The two arguments against it are:
- it's harder to see what the c- function name is (point_add in all cases). The is actually currently
the same for module attributes as well (Foo.bar() -> foo_bar) - The syntax breaks more with the ansiC style
What do you think?
135
General Discussion / Re: VLA crash
« on: March 15, 2017, 08:37:44 AM »
The issue reproduces nicely indeed. There seem to be several issues here. The first one
is that array subscript expressions were not marked at compile-time-constant (if they were).
That is fixed on a branch now. Since C2 allows more then C sometimes, I'll look carefully
at the order of evaluation, since it's otherwise easy to get loops in constant declarations
that we have to detect/avoid..
is that array subscript expressions were not marked at compile-time-constant (if they were).
That is fixed on a branch now. Since C2 allows more then C sometimes, I'll look carefully
at the order of evaluation, since it's otherwise easy to get loops in constant declarations
that we have to detect/avoid..