61
General Discussion / Re: "Code of least surprise"
« on: November 09, 2018, 08:35:43 PM »
I'll make this more explicit in the documentation!
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.
62
Ideas / Re: Asm naked functions
« on: November 08, 2018, 12:02:28 PM »
I'm a bit surprised you don't have anything against the word 'naked' in code 
63
Ideas / Re: Dynamic arrays & fixed arrays
« on: November 08, 2018, 12:01:46 PM »
I think the same here goes for 'smart' strings, etc. It's always possible to create something like this as a developer.
That way it's just a library thing and not a language thing. Unless there are some real benefits by putting this in
the language itself.
That way it's just a library thing and not a language thing. Unless there are some real benefits by putting this in
the language itself.
64
Ideas / Re: Relax variable initialization rules
« on: November 08, 2018, 11:59:39 AM »
Here's what Linus Torvalds has to say about VLAs: https://lkml.org/lkml/2018/9/3/1288.
Of course he's not talking about the C2 compiler
I think the designated array initializer syntactic sugar doesn't really bring anything, except
complexity. Is the code it replaced that much worse?
The first example (global array init) is allowed, but only by making foo const.
Of course he's not talking about the C2 compiler
I think the designated array initializer syntactic sugar doesn't really bring anything, except
complexity. Is the code it replaced that much worse?
The first example (global array init) is allowed, but only by making foo const.
65
Ideas / Re: One more big thing: Errors
« on: November 08, 2018, 11:55:40 AM »
I've read the C part of the proposal mentioned above. I think it's an attempt to introduce a universal mechanism,
for something that simply has no universal solution. Also it's a bit nasty with macros/syntax. It has to be because it has
to deal with existing C code. For C2 that restriction is not there and that is exactly why I believe we can do
better.
Although I don't have a single universal solution in my, I do have multiple non-universal ones that can maybe be
improved by some language support:
for something that simply has no universal solution. Also it's a bit nasty with macros/syntax. It has to be because it has
to deal with existing C code. For C2 that restriction is not there and that is exactly why I believe we can do
better.
Although I don't have a single universal solution in my, I do have multiple non-universal ones that can maybe be
improved by some language support:
- It would be nice to rid calling code of error handling by placed that in another 'layer'/place. This can currently be
achieved with longjmp. The programmer must make sure the state remains solid (no mem leakage etc) when jumping. - C has a habit of (ab)using special return values for error values. Like value -1 for file handles. I think this is fine for some things. It does
force a cast sometimes, because the result is signed instead of unsigned to support this - For some errors, a larger performance penalty is fine since it's a non-common situation anyways. But for others where
failure is a common case, the penalty might not be acceptable. - returning a tuple (=overhead) for situations where failure is rare, using the 'other-layer' approach might be better.
66
Ideas / Re: One more big thing: Errors
« on: November 08, 2018, 11:21:25 AM »
Error handling is THE most complex thing for languages I think. The best solution I ever saw was for a (real-time) embededded Operating System.
All 'system' calls didn't return success or not, but on failure, just called a pre-registered on-error function. But that is only usable for a truly embedded
solution where some failure probably means reboot or just do nothing. It did make the code immensely better:
Without:
With:
And that is even a small example.
For C code, I've used a longjmp mechanism. Most people don't like this, but it goes make the code so much easier
to read/write and if used correctly, it just simplifies things. This also creates something like a normal-path and a separate
error path (just like exceptions and the example above). The Erlang language also has some nice mechanisms to
explicitly register error handlers for specific pieces of code. The problem with all these mechanism however, is that
none of them can be used generally for all problems.
All 'system' calls didn't return success or not, but on failure, just called a pre-registered on-error function. But that is only usable for a truly embedded
solution where some failure probably means reboot or just do nothing. It did make the code immensely better:
Without:
Code: [Select]
buffer* b = malloc(10000);
if (!b) { .. } // error handling
socket* s = open(123);
if (!s) { .. } // error handling
With:
Code: [Select]
buffer* b = malloc(10000);
socket* s = open(123);
And that is even a small example.
For C code, I've used a longjmp mechanism. Most people don't like this, but it goes make the code so much easier
to read/write and if used correctly, it just simplifies things. This also creates something like a normal-path and a separate
error path (just like exceptions and the example above). The Erlang language also has some nice mechanisms to
explicitly register error handlers for specific pieces of code. The problem with all these mechanism however, is that
none of them can be used generally for all problems.
67
Ideas / Re: Readability of keywords "uint32", "float64" etc
« on: November 08, 2018, 11:09:19 AM »
It's common to store pointers in numbers. Code like that often keeps track of the meaning of the value. It could be a real number or a pointer.
For code like this, having a usize/isize is a real requirement.
For code like this, having a usize/isize is a real requirement.
68
Ideas / Re: Switch statement
« on: November 08, 2018, 11:07:13 AM »
I think it's good to have a language as simple as possible. Especially to read. Having (the option) to specify whether
a switch statement is auto-break or auto-fallthrough is nasty when you are only seeing the case part on your screen.
You think it's auto-break, but it might be auto-fallthrough. All code/switch statements should just look alike.
Fallthrough (by forgetting a break) in C has been a common cause for bugs, so I think it should be addressed somehow.
My proposal would be to force either a break or fallthrough statement. But mapping this to generated C code might
not be trivial..
a switch statement is auto-break or auto-fallthrough is nasty when you are only seeing the case part on your screen.
You think it's auto-break, but it might be auto-fallthrough. All code/switch statements should just look alike.
Fallthrough (by forgetting a break) in C has been a common cause for bugs, so I think it should be addressed somehow.
My proposal would be to force either a break or fallthrough statement. But mapping this to generated C code might
not be trivial..
69
Ideas / Re: Anonymous structs (actually, tuples)
« on: November 08, 2018, 10:45:50 AM »
This is actually multiple return types right?
70
Ideas / Re: Weird ideas #2: variable sized structures
« on: November 08, 2018, 10:39:46 AM »
Yes those are all more clear then Foobar[0]. So we could disallow the use of zero-size arrays and force usage of [ +].
Originally any array[ +] was always an incremental array, but with this change, it could also be a zero-size array.
Originally any array[ +] was always an incremental array, but with this change, it could also be a zero-size array.
71
Ideas / Re: Enum improvements
« on: November 08, 2018, 10:25:53 AM »- I actually had the same idea, but had an attribute @(to_string) in mind to enable it.
- I like the TheEnum.max_val a lot. It's more elegant than the current global enum_max keyword! And since it starts with a lower case, it cannot clash with constants.
- Associated values with enums are indeed a bigger change. I don't think they fit a C-like language
- Same for the list.
Thinking this through, we could also use the same method for sizeof(). So MyType.sizeof() instead of sizeof(MyType). Although it might be harder to replace sizeof(Type*). Maybe use Type.ptrsize() ?
And replace elemsof(array) with array.elemsof(). This would require changing the analyser to understand that every Type or variable can have some 'members'. The advantage would remove so global
keywords and maybe make the code more readable:
Code: [Select]
for (u32 i = enum_min(State); i <= enum_max(State); i++) {}
// vs
for (u32 i = State.min; i <= State.max; i++) {}
72
Ideas / Re: Allocation strategies
« on: November 07, 2018, 03:38:49 PM »
Usually you want to hide allocator stuff like this completely in a language. Just like Java/Go do. But the strength
of C is that nothing is hidden from developers, so no funky unexpected stuff is happening. Following your example,
in C, if you want to create an uppercase() function, you either:
of C is that nothing is hidden from developers, so no funky unexpected stuff is happening. Following your example,
in C, if you want to create an uppercase() function, you either:
- modify the original input
- return a pointer to a static buffer
- allocate so caller has to free
73
Implementation Details / Re: Code formatting of C2's c++
« on: November 07, 2018, 10:41:48 AM »
I played around with clang-format and that seems to be a good candidate. I'll look at an initial style and propose that..
There is a .clang-format file in the root of the archive. It can be applied by running
Please use that on several files and check whether it does something really nasty or bad style-wise
There is a .clang-format file in the root of the archive. It can be applied by running
Code: [Select]
clang-format-i main.cppPlease use that on several files and check whether it does something really nasty or bad style-wise
74
Implementation Details / Re: ASM validation
« on: November 07, 2018, 10:39:26 AM »
you're correct. I haven't copied all the register checking etc because there is no
target Triple yet. I have done successful cross-compilation to Arm/PowerPc systems of C2
using build files, but the compiler itself doesn't implement this yet.
target Triple yet. I have done successful cross-compilation to Arm/PowerPc systems of C2
using build files, but the compiler itself doesn't implement this yet.
75
Implementation Details / Re: Why do we need Clang and LLVM?
« on: November 07, 2018, 10:37:37 AM »
Yes, lexical macros (like C) allow everything, but cause so much issues in tooling etc. Once C2 has a
replacement macro system, we can simplify the Lexer a lot.
replacement macro system, we can simplify the Lexer a lot.