Programming thread

[UERISIMILITUDO]

i should man up and start writing everything in C89

Use the right tool for the job, I say.

 

[Rango Dango]

The new if declaration thing is a welcome intrusion of Go into C

to be fair until reading the article i thought this was already in the standard, since i'm pretty sure i have written code that used it

---

C23 added a lot of nice things, like binary literals or that you can make enums not int-wide, some guy even sent a letter thanking for #embed (sorry for using the tranny furfag as the source, its the only one i could find)
also constexpr variables are useful, since theyre typechecked macros
the addition of digit separators also makes reading some values easier

in general C23 added a lot of nice things to C, while still keeping it C, instead of making it C++

 

[DumbDude43]

to be fair until reading the article i thought this was already in the standard, since i'm pretty sure i have written code that used it

---

C23 added a lot of nice things, like binary literals or that you can make enums not int-wide, some guy even sent a letter thanking for #embed (sorry for using the tranny furfag as the source, its the only one i could find)
also constexpr variables are useful, since theyre typechecked macros
the addition of digit separators also makes reading some values easier

in general C23 added a lot of nice things to C, while still keeping it C, instead of making it C++

50 years after the creation of the language, we finally have true and false in C
amazing

 

[Anti Snigger]

Technically, sure, but I know Common Lisp and Ada both provide the option to name certain program units specifically to avoid this problem of leaving nested units. Ada in particular allows the programmer to name just about anything, to an extreme degree, however. I've used goto in Ada once, when writing some Task exiting code that wasn't as pretty as I'd like. The Ada solution to goto is to make the labels ugly; they look like this:

goto Label; -- Damn, no Ada syntax for code blocks here.  No Pascal either.
...
<<Label>>

It's clear, at least. There are also the usual rules about not jumping into the middle of control constructs from outside of them and things like that.

Amusingly, Common Lisp only has goto as its iteration construct, good old TAGBODY and GO, they're just wrapped up in so many macros that the programmer never has to deal with them unless he feels like it.

I like the labeled break personally, I've often used goto in a similar capacity to break out of multiple layers. I think while the new syntax doesn't do anything new, the explicitness of it is really nice.
I'm also a big fan of the if declaration syntax. Again, it's not much different than

int sneed;
if (!(sneed = get_sneed)) {...}

However, the scoping of sneed isn't something you can conveniently replicate without wrapping the entire if-else chain in braces, and so it just makes it easier to write and specify scope.
I'm generally pretty positive toward nu-C, there are a lot of gadgets they added that allow you to more aggressively specify contracts and effects, which is really nice for static analysis.

 

[306h4Ge5eJUJ]

50 years after the creation of the language, we finally have true and false in C
amazing

50 years after the creation of the language, we finally have portable generic ways to check for overflow. Except that MSVC will probably take until 2040 to implement it, lol lmao.

 

[Anti Snigger]

50 years after the creation of the language, we finally have true and false in C

I still don't use bool lol, The ! and !! operators compile into single instructions that use a single bit register in x86 cpus anyhow

 

[analrapist]

we finally have true and false in C

It's hilarious to me how with all the HM type inference being added everywhere, the older and more well-understood restricted boolean inference traditional to C syntax is seen as a "bad thing".

 

[DumbDude43]

It's hilarious to me how with all the HM type inference being added everywhere, the older and more well-understood restricted boolean inference traditional to C syntax is seen as a "bad thing".

t.

//boolean.h
#ifndef BOOLEAN_H
#define BOOLEAN_H
#define FALSE 0
#define TRUE !FALSE
#endif

enjoyer

 

[analrapist]

#define TRUE in C is an antipattern that breaks logic, eg.

int a=2;
if(a==TRUE){printf("never reached\n");}

Doesn't stop people from doing it but neither did Rust.

 

[WielkiWapiesz2137]

#define TRUE in C is an antipattern that breaks logic, eg.

int a=1;
if(a==TRUE){printf("never reached\n");}

Doesn't stop people from doing it but neither did Rust.

? It executes the print

 

[analrapist]

? It executes the print

a=2 then, ought to be "true" but not TRUE.

 

[UERISIMILITUDO]

? It executes the print

He's pointing out that, while falsehood has a canonical value, truth doesn't.

 

[Anti Snigger]

He's pointing out that, while falsehood has a canonical value, truth doesn't.

Yes it does, it's not 0

 

[WielkiWapiesz2137]

a=2 then, ought to be "true" but not TRUE.

He's pointing out that, while falsehood has a canonical value, truth doesn't.

Both true from bool.h or later C standards and #define behave the same way (in a = 1 and in a = 2 cases) therefore #define TRUE cannot be considered anti pattern.

 

[analrapist]

therefore #define TRUE cannot be considered anti pattern.

The antipattern is that two variables that are functionally equivalent in value are not recognized as such by the syntax. It has nothing to do with whether an approach is canonical or not.

 

[WielkiWapiesz2137]

The antipattern is that two variables that are functionally equivalent in value are not recognized as such by the syntax. It has nothing to do with whether an approach is canonical or not.

If you were to have the way that you want it you would end up with JavaScript.
There are 3 main ways of doing comparation between types
1: Bitwise
2: By conversion
3: Always return false
Conversion is pure niggery as evident by horrors of JavaScript. Thankfully the C gods decided to be sane and thus limit it to numerical types only and went with bitwise for anything else which is sane for low-levelish languages.
The only way of assigning truth value to 2 == TRUE that isn't pure design niggery(ie treating it in special manner) would be to always do type conversion yet that way you will end up with niggery anyways therefore C behaviour here is sane.
The best solution to that is to do what LISP does that is have multiple comparation operators

 

[UERISIMILITUDO]

Both true from bool.h or later C standards and #define behave the same way (in a = 1 and in a = 2 cases) therefore #define TRUE cannot be considered anti pattern.

Yeah, it's not as if the C language is filled with shit that's got big glaring Do Not Touch warnings all over it.

I like how APL does it. Zero is false and one is true. Two isn't true. Only those two numbers work for this. However, several concepts have been extended past boolean values regardless:

 ⍳4         ⍝ Iota generates an array of numbers starting from zero or one to the provided value.
1 2 3 4
 0 1 0 1/⍳4 ⍝ A forward slash acts as a filter, where true keeps the element and false discards it.
2 4
 (⍳4)/⍳4    ⍝ However, we're not limited to true and false.
1 2 2 3 3 3 4 4 4 4

 

[analrapist]

If you were to have the way that you want it you would end up with JavaScript.

Absolutely not. What I am proposing here is nothing more or less than asserting that defining TRUE on a C platform is semantically-inaccurate and obfuscating. Acceptable values of TRUE involve anything that is not zero. What I'm saying is that using defines and constants for this purpose is niggerlicious, not divine intellect.

Practically, the usual shell semantic is the inverse of C: non-zero return values are "errors", functionally akin to "false" in eg. if statements. I think this is my ideal: exactly one truth, many falsehoods. There's a fun hack here for exception handling because your "error return" can just be a pointer to exception information, NULL if error-free.

In LISPs, if there's a chance you're getting a type you don't expect, you check it. It's miles away from C's strange int-boolean semantic.

 

[WielkiWapiesz2137]

Yeah, it's not as if the C language is filled with shit that's got big glaring Do Not Touch warnings all over it.

Such as? C design is perfectly sensible for single-pass compiled procedural language - most of the cases that i have seen people complaining about it is because either they haven't thought about what the alternatives are or because they do not understand with being single-pass entails.

 

[UERISIMILITUDO]

Such as?

One word: gets. The interface is desirable, but not easy to provide as in other languages, although I'm aware GNU provides both getline and the more general getdelim, which are neat.