Recent Posts

Pages: [1] 2 3 ... 10
1
Ideas / Re: Readability of keywords "uint32", "float64" etc
« Last post by acbaile on Today at 05:38:34 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.

Maybe, types with names "uint" and "int" ? With clear rules for defining their sizes. For example: these types always have size of common/address registers for target platform.

So, it will be set of types: int8, uint8, int16, uint16, int32, uint32, int64, uint64, int, uint.

int, uint are last in set with recommendation to use it only when necessary (of course, because of uncertain size) - pointers, sizes of buffers etc.
2
Ideas / Re: Overloading of functions
« Last post by lerno on Today at 03:30:23 AM »
Overloading functions requires some sort of name-mangling scheme. – Unless you do it using something like C's __Generic, and that's more of an alias.
3
Implementation Details / LLVM/C gen
« Last post by lerno on Today at 03:27:49 AM »
The two backends makes it a bit hard to keep feature parity of both. LLVM is far behind, but what is the strategy?

Using C, a nice thing is that we can start bootstrapping early if we'd like to(!) We can build parts of the server in C2, then compile to C and then automatically copy that code into the main source!

On the other hand, keeping the same behaviour between LLVM and C isn't easy. I've looked at Clang's LLVM gen, and it produces a lot of optimized code by leveraging intrinsics for certain "known" functions. So for example, if Clang sees sqrt, it can swap the normal library version for a LLVM intrinsic. To complicate things further, those are target dependent :( So there are *massive* amounts of work to do – on the LLVM gen.

Obviously if we get more people behind the project then that might be an easier thing to do. Without a lot of people spending time on C2 it will have a hard time being anywhere near optimized.

So what would the plan be?
4
Ideas / Re: Overloading of functions
« Last post by acbaile on November 14, 2018, 10:56:32 PM »
It looks like acceptable possibility - with term that C2 recommends using of overloading only for functions that do the same action.
5
Ideas / Overloading of functions
« Last post by acbaile on November 14, 2018, 10:37:41 PM »
Bas, it seems, i saw here in forum (i can not find it with search now, maybe in main documentation) some words about overloading of functions. Like you don't plan to include it in C2. If it is true, my question is: "What are reasons?"

I use it all time, and i don't feel any discomfort of it. I never had errors or bugs with overloaded functions. It's convinient: when action is the same, you group functions by one name, and you can not make big mistake by calling another function instead of one - because action is very close. Really, i had no problems with it. And it gives possibility to use one, short, beautiful, laconic name for this action.

Word "overload" has negative meaning. Like too much weight for one name. Like it can be problems with calling right function. You want to call one function, but call another. But in my practice i never give the same name for functions that do different work. Every module has it's own prefix for functions.

Who did have problems with overloaded functions?
6
Ideas / Re: Function inside function
« Last post by lerno on November 14, 2018, 06:30:42 PM »
This C feature is only in GCC/Clang or?
7
Ideas / Re: Syntax of const pointers
« Last post by acbaile on November 14, 2018, 10:02:11 AM »
3. <Your idea here>

Why you don't like this syntax? I see only one unclear moment. This one:

Code: [Select]
int const * a;

Who is const here... Asterisk? Asterisk means pointer. Constant pointer? No, constant value, in fact. It confuses. It's better to remove.

Other three forms are clear:

Code: [Select]
const int * a;
int * const a;
const int * const a;

I don't see reasons to change it.

Parentheses is not good, make worth.

Preciding of const qualifier is better. In this form you always know: this is "const int", this is "const var". Form "const *" confuses programmer. Proposal 4 is not good.

Maybe, it's native language dependent. In my native language we usually say first adjective, and follow it by substantive. So, form "const int" is much more clear for me than "int const". But, i think it's universal. At least, english is similar in this moment.
8
Ideas / Re: Function inside function
« Last post by acbaile on November 14, 2018, 09:00:51 AM »
  • Do you clone the values of the local vars as they were when the closure was created?
  • Do you keep a reference or move them into the closure?
  • Can the closure be freed? If so, how? You probably wouldn't want a memory leak

The idea was to have a part of code inside function with possibility to call it many times. Like call by local label in assembler - without usual rules of saving registers and passing parameters. Operating with variables is like this is high-function's code. I did not think about passing arguments inside even, it seems you simply don't need it in this idea - you can access them directly.

But, i agree: this feature is not used often, and it can be difficult to realize it. It's too expensive.
9
General Discussion / C2x
« Last post by lerno on November 14, 2018, 01:49:03 AM »
Very important to look at and incorporate: https://gustedt.wordpress.com/2018/11/12/c2x/
10
Ideas / Re: One more big thing: Errors
« Last post by lerno on November 13, 2018, 08:47:33 PM »
My guess was that it wouldn't need to add much complexity. But the idea has to be completely fleshed out before knowing for sure. A comfortable and practical syntax is also necessary.
Pages: [1] 2 3 ... 10