Products > Programming

Oh, C3!

(1/13) > >>



--- Quote ---Member access using . even for pointers
--- End quote ---


--- Quote ---Removal of multiple declaration syntax

Only a single declaration is allowed per statement in C3:

int i, j; // ERROR
int a;    // Fine

In conditionals, a special form of multiple declarations are allowed but each must then provide its type:

for (int i = 0, int j = 1; i < 10; i++, j++) { ... }

--- End quote ---


--- Quote ---Goto removed

goto is removed and replaced with labelled break and continue together with the nextcase statement that allows you to jump between cases in a switch statement.

Rationale: It is very difficult to make goto work well with defer and implicit unwrapping of optional results. It is not just making the compiler harder to write, but the code is harder to understand as well. The replacements together with defer cover many if not all usages of goto in regular code.
--- End quote ---

Thankyou to the authors for providing the rationale.  I'm not involved in your group or the languages you are probably using as context, without this I'm clueless as to why you are doing many of your things.

I like C as a low-level language, ie closer to assembly.  Goto is natural for that.  I'm worried that it sounds like you are placing compiler author desires ahead of users; what are these desires?  Higher optimisation levels?  That's a difficult sell to many C users, it's not an absolute problem, there are lots of shades of grey.

I want to look more at this 'defer' feature, but I can't find much docs about it.  Best I can do is this example but it doesn't explain things like order of defer executions (stack or queue?), what happens to variable scope, whether I can defer an entire block of code (instead of just one line), etc.

EDIT: removed my extra ideas, split into another post below.

 ::)   :-\

Always the same. Based on C.

--- Quote ---Stay close to C - only change where there is a significant need.
--- End quote ---

Or when you're too lazy to write code that cleans up after itself.


I disagree with both you Kloonk AND the statements of the C3 authors :P  I hope that doesn't count as a double negative.

There is lots to C I like.  Definitely lots I don't like either.  I'm not sure if C3 really floats my boat. 

I wonder what C3's use case and mindshare is?  Narrowly in-operating-system programming mainly?  Or broad inc micros?  I can't find anything about that on the site.

The C2 site mentions kernels & bootloaders.

Split from my earlier post, these are not comments about C3 but just interesting to compare with the lang changes they have made.

Some things I've imagined up over the years whilst using C that I wish I had:

(Whales1) Make the struct keyword unnecessary when using structs. 

Both options are annoying: having to write "struct" before every defintion (inc in function args) OR having to typedef every struct.

This change would be backwards compatible with 99% of code (only breaking those that use struct names as names for something else too).  If you want to keep using "struct" keyword everywhere you still could, no wakkas.

(Whales2) Clamp down on a lot of the silliness you read being discussed about undefined behaviour. 

Do what the programmer would expect to happen on a standard 2's complement machine with type sizes a multiple of 8 bits.  Use the rule of "least astonishment".  C is supposed to be easier than assembly, don't make it harder.

(Whales3) Require that ALL new arches/platforms adopt the same fixed definitions for the sizes of int, char, long, etc. 

I already use uint32_t and co from <stdint.h> but standard funcs like printf("%d") then require much uglier writing to be platform portable. 

eg printf("I have %"PRIu32" doges with %"PRIs64" coolness factor\n", dogcount, coolsum) is just a pain, even worse when you have many consecutive fields and less string inbetween.

(Whales4) Syntactic sugar: namespaces.

Implement just as an auto-prepending of function (and var?) names with the characters "namespacename::" and do nothing more.  Also allow someone to strip these characters off again (ie skip the namespacename:: prefix when using the funcs) if they so desire.

Completely optional, breaks nothing.  Worth trying just to see if it makes things easier or harder to deal with.  Many people already prefix their lib's function names with "LibName_" anyway, it might be better or worse to make an option of a standard method, not sure.

(Whales5) Syntactic sugar: allow defining functions in a class-like syntax.

ALL it does is automatically modify them to add a "self" argument to their arg list.  No new/delete/constructor/deconstructor/public-private-protecgted stuff, leave that to Cpp, just a bit of sugar to make things a little neater and happier.

--- Code: ---struct something
  f32 posx, posy;
  char *name;
  void *aux;

something::new(u32 id);
something::recolour(u8 r, u8 g, u8 b);
--- End code ---

Unlike C++ you wouldn't even need to expose all of the struct internals inside the header files, so editing the struct contents won't cause header files to change (which then won't trigger a recompile of absolutely everything).  Eg this would be OK too:

--- Code: ---struct something;
something::new(u32 id);
something::recolour(u8 r, u8 g, u8 b);
--- End code ---

(On the technical side: this is doable because then things don't need to know sizeof(struct) any more)


[0] Message Index

[#] Next page

There was an error while thanking
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod