ITT: Zig Forums extends C with proper extensions(try to describe precisely what you want)...

delete it all and add Haskell

Attached: tad.improving_c_language.webm (316x236, 159.58K)

How about interpretive C?
Have GCC running as a VM, with access to kernel via function calls, and host a userspace for everything else.

I think we already have enough interpretive languages.

I bet you can't write an interrupt routine in Haskell, you little faggot

big brain: ATS
smol brain: Zig
unironically though, I might add Zig as an output target for ATS. Maybe next year.
ATS lets you write everything you can in C, exactly as you can in C, but brings a ton of static checking to the table, so that you can be sure that some code can't run off the end of an array, or dereference a NULL pointer. And that's just the start.
of Zig, my first impressions were poor because it does a bad job selling itself, but it's again a language that can work hip-against-thigh with C while improving on it. Zig for example has compile-time capabilities and guaranteed inlining that let it do stuff with code that you'd need the preprocessor for in C. Zig just goes more in the direction of comfiness than in safety, although for safety it still has integer-overrun checks for example.
You can use both of these languages now, but neither is super mature. In particular, neither document their standard library yet.

Attached: bigbrain.png (1010x72 43.43 KB, 15.12K)

what are you niggerfaggots on?

RAII is still a GC

replace the preprocessor with a module system, templates, and proper compile time introspection

"Someone who is not me will hopefully write a compiler."

Proper arrays, templates and better multibyte encodings support (other than converting to gay wide chars).

Extend preprocessor, maybe make m4 the standard.
Add lambdas from C++.
Add namespacing from C++.
Purge unsafe functions (gets, non-"n" variants for string.h functions).
Add some way of keeping track of array lengths.
???
Profit!
(Not really C related, but I wish Linux gave you the ability to drop to debugger when a program crashes, without necessarily running it from a debugger.)

sudo apt-get install vala
done

autoshitter detected

this

rust is for faggot jews, so it should be perfect for (((you)))

You do that c++ already exists, yes? Go use this instead.

You know, if C++ was only C with classes, it would be used. Too bad a loser that never did program anything of value made it.

Is that a function being called though a function pointer inside a struct called lib or is it that the C hater can't into basic c programming? My money is on the latter.

No, you should see the sick abuses in some of the code. eg. 3-4 layered macros used for function definitions with ##, # and variable lengths of arguments. I could not use any search functionality to find function definitions and had to spend fucking hours deciphering those layers of shit before even having any idea of what the function does.

I think this was in the iw code somewhere.

C is really an extensive language that lets programmers have nearly full reign on the computer. Those who complain don't understand how the compiler or interpreter of their languages work. They complain about memory management mostly, but that is entirely laziness on the programmer. Memory management is not difficult, especially with C. How do they think all those other language compilers/interpreters were made: in assembly?

In c++, mostly

(after RIIR)

When I am programming I would rather focus on how to solve the problem rather than how the computer should solve the problem which is the job of the compiler. Would you rather concatenate to strings by:
1. "Hello " "World"
2. const char *hello = "Hello "; const char *world = "World"; const char *res = malloc(strlen(hello) + strlen(world) + 1); strcpy(res, hello); strcat(res, world); return res;
In the first I simply describe that I want to append one string monoid to another, but in the latter I have to do all this busy work of creating buffers, and copying stuff into them.

see
Yet another situation where gnu has already extended c so we dont have to.

Write your own libraries. Problem solved.

Add common structures like trees, hashmaps, and graphs in the standard library so my shitty fizzbuzz program that relies on 3 different libraries doesn't have 3 versions of these structures with their associated methods thrashing my cache.

Also replace the preprocessor with an actual programming language like js.

I'd love a golang-style single-function built-in server. Something like
err = listen(8080, &responseStruct, &otherShit)

Range based for over arrays.
Why?
Take a look at a common way:
// Crufty, and if you malloc array after compile-time, it gets more crufty. The attack surface widens. Try to count by other than 1's, it's easy to make off by one error.for (int i = 0; i < sizeof(array) / sizeof(typeofArray); i++)
Instead, can do:
for (typeofArray atom, array)

github.com/combinatorylogic/clike

...

your programming problems dont require c if the nuances of const, pointers, and libraries just get in the way

What do you think about some kind of macro system where you can overwrite C syntax?

For example
typedef struct Something { int x; char* name; float foo;}Something niggerFunction(Something me, int number) { me.x += number; return me;}#syntax (Something, '+', value) \ niggerFunction(Something, value)Something faggot;faggot = faggot + 500;// the above turns into following:// faggot = niggerFunction(faggot, 500);

So almost no software then.

what are you trying to say? you want to be able to extend the syntax like suggests? because, if you are talking about enhancing the macro system, we are now talking money

There's only 2 things I want. Default values for structs, and syntactic sugar "methods".
typedef struct gaystruct { int health = 100;}void gaystruct.lynch (gaystruct* this, int strength) { this->health -= strength;}gaystruct op;gaystruct op = {.health = 100}; // identical to above due to default valueop.lynch(10);gaystruct.lynch(&op, 10); // identical to above

nim-lang.org

Any big and radical features are definitely out of questions, there's a good reason why all C extensions were relatively small.
As convenient as it may be, new string type would probably result in a complete mess unless it was compatible with the current ones. Something that's easily and concisely converted both ways might be acceptable.
would be worth it, but maybe make it optional, so that there's a standard way to check whether it exists, because small/minimal platforms and implementations probably would not implement it either way.
isn't terribly invasive and does make stuff more readable
RAII could be worth it in some form, but that might be pushing it.
Namespaces.
No overloading.
Templates are nice, but seeing what templates did to C++, there would have to be something preventing template spam. Maybe have the whole special templated header and force people to define the types during inclusion like this/* footemplate.hh */#template A Bstruct foo { A a; int i;.../* main.c */#include "footemplate.hh" {int, double} "_intdouble... struct foo_intdouble x;Could be polished, but you get the idea.

Ups, meant no operator overloading.

...

kys

fuck_off_larper(YOU);

NoYou(faggot)

non-programmer detected

This syntax deserves all the hates that it gets, it's the ugliest shit ever and every time I have to use SFML, Irrlicht, Bullet Physics and many other libraries, I have to stare at this shit. Either do_this() OrThis() but not that halfAssedSyntax().

that explains it. fuck off to /v/

Fuck off to india if you want to code like a pajeet.

Look kid finish up school, fail to get a game dev job, put 10 years in the real industry, then come back.

Nobody needs 10 years in "the real industry" to know that you code like shit.

OK bud. Sure thing.

Attached: DV5KJz6U0AAHgRh.jpg (599x823, 47.96K)

okBudSureThing()

Attached: you.jpg (400x400, 18.81K)

OkBudSure_Thing()

Attached: DeP1W9lXUAIear2.jpg (769x560, 34.63K)

This is worse than /g/, they would at least make a logo.

It's mode specifically a monoid as you have mempty = "".

You can't fix it.
Get rid of postfix operators.
Change (function) pointer declaration syntax.
Change assignment from = to :=.
Better variadic functions or none at all.
Forgot the standard library ever existed.
Incorporate a better means of cooperative tasks (plan9 libthread).
Have the stack programmable for user supplied garbage collection (precise), and exceptions libraries.
No shitty preprocessor, use real module declarations with explicit import and export.
Standard library should have hash tables, lists, vectors, but no trees or graphs.
Meta programming is a maybe.

Also, standardise computed GOTO.
Allow functions to be referenced before declaration.
Nested procedures are another maybe.
Get rid of union and enum, substitute with proper tagged union.
Structures should be abstract, no need to worry about packing. (Abi concerns arise however).
No bit fields.
Top level expressions should be permitted and be implicitly invoked at program entry, no need to manually initialise libraries, just import them.
Parameters/special variables from common lisp/scheme preferred to raw global variables.

Multiple return values would help reduce the need for pointer arguments.

Return a struct with a variable stating the type and a union holding the value you want returned. Not difficult.

So are stack frames

Compare qsort's performance to that of a templated sort and stop being retarded.

So I don't have to give you another (You) try implementing a context switch or checking flags in C. The only thing C gives full access to is the C abstract model of a computer.

Attached: 1421945295834.jpg (312x312, 75.05K)

Use the asm keyword if you have the absolute need to check flags. As for a context switch, why would a struct not work here to preserve state?

Technically in the standard as an extension, but implementation defined.
You need asm to access the registers.

Just tested it, macros and templates lead to equally quick qsort functions (at any optimization level). But the C version compiles twice as fast. C++ BTFO

>>ITT: Zig Forums extends C
moron

Attached: 1430694813664.png (1024x768, 251.06K)

Arguments against function templates:

Sometimes, you want to avoid passing pointers and passing by copy is more desirable, not least because it simplifies memory allocation.
That's a fair point, though it doesn't invalidate the other use. Moreover, the templating system could allows for automatic inference of method names for the type (and fail compilation if it doesn't exist), kinda like TYPE##_to_string in cpp. This isn't the most important use tho.

Most of my recommendations are existing extensions provided by gnu.
They wouldn't require significant restructuring of an existing c compiler, it's not like I'm suggesting closures, templates or object systems.
The feature is want most is modules/namespaces, I would redact top level statements/expressions and special variables however.
Improving a language requires breaking compatibility while maintaining the "spirit of the language", extending it results in people using the old crusty methods and bloated specs like c++.

kys

kys even more

Macros should die in a fire first and foremost.

Compile time CAPTCHAs?

DELET THIS

As a huge fan of macros I agree that they don't really belong in c.
But the temptation still exists to use them.
My best use of macros in C was for a 6502 emulator, all Opcode's were defined in a header file that was shared by the CPU core and debugger, this technique is called "x macros".
It let me change the interpreter from direct threaded, indirect threaded, switch dispatch, etc. with minimal changes to code.
The only other good use i know is to have coroutine's / state machines using a macro YIELD defined like
#define yield{ _label_ cont; state = &&cont; return;cont: 0;}
A coroutine would define static void *state and jump to it right away.
Although it worked, it would cause problems with the optimiser and obviously doesn't preserve local state, but is much better than makecontext/setcontext.
I originally seen a variant of this in "game programming gems" that made a DSL for state machines in c that did message passing.
The only reason I mention this is because I personally can't think of a better way to do these tasks (in c) without loads of boilerplate.
Perhaps the ideal way is to generate programmes in whatever language you prefer in the style of yacc/bison?

I had a fun time writing this last night. Hellish abuse of macros, ugly as all hell, shouldn't be used in serious programs, but fun to code. I only wish a macro call could itself define macros, would make certain things much prettier.
pastebin.com/krUV32vY
Obviously I need to add a way to pass data to the coroutine.

In their most basic usage, macros work. Using them to define simple functions that operate irrespective of types (eg #define ABS(c) ((c)>0?(c):-(c))) is fine. They are way to fragile to use for more complicated things, which is generally when you should start thinking about other languages. I like the idea of doing a simple coroutine thing, but I can't think of a way of keeping it simple enough to still be c, while complete enough to be useful.

why haven't you learned Zig yet? If I were either of you, instead of me (into ATS), I would be crying with joy over Zig. Manual memory management, doesn't have macros because it doesn't need them with its comptime capabilities (that extend to implementing printf, parsing its format string, and considering what to do with the types of arguments to it--all at compiletime, in normal Zig code), can write type-generic code without going full templates, etc.
The author says shit like "I'm not smart enough to be productive in Rust" without shame. Zig is literally your language if C is 90% acceptable to you.

...

I'll work on the logo.

++go[fuck++]--, yourself

I may have given you benefit of doubt, if it stopped at post increment. But when you suggested replacing = with := purely for looks, as a language extension, I knew you're an idiot.

C is a perfect language. In 1000 years we will all use c. No improvements to C or Unix can be made.

Be honest, you've accidentally used assignment in place of equality more than once.

And the compiler issued a warning. Yes, if I was writing a new language, I might consider it, but only a complete and utter moron would think that turning use of the single most frequently used operator into a syntax error is a good language extension.

so don't make it a syntax error in old code. make it a syntax error after an #include

That's stupid and introduces completely unnecessary complexity.

You're hurting my feelings ;_; which violates my proposed CoC for nuC.
Seriously though I'm not going to debate banal lexical conventions.
It's not like anyone here is gonna read this thread then go hacking tcc.

And before I start shitposting again I might as well leave this here
doc.cat-v.org/plan_9/programming/c_programming_in_plan_9

What is wrong with bit fields?

Those plan9 fuckers really thought things through. Too bad most of this stuff is OS level not language level. Basically impossible to take advantage of it without installing 9front. The few language level changes have filtered down into modern c. Utf-8 in particular is the standard for unicode handling (when c programmers bother to support unicode).

since processors work with bytes that should be the atomic unit. let me tell you about lisp machines...

...