Thread 106300522

You don't need more.

>>106300522 (OP)
>in C
more like GCC? That seems like a compiler-dependent hack.

>>106300522 (OP)
>You don't need more.
In your school projects.

>>106300522 (OP)
I can't wait for jai to be released. Hope the compiler isn't a brittle pos

>>106300522 (OP)
>F(3.14, 2);
I'd kill myself if I had this bug.

>>106300522 (OP)
Everyone involved with the creation of the _Generic abomination should be lynched for crimes against C.

>>106300522 (OP)
this is the same retard who complains about c++ syntax

>>106300522 (OP)
You're supposed to do it with function pointers, vtables, self-modifying code, that sort of shit.

just use TinyC as a standard

just use TinyC as a standard
and PHP as preprocessor

>>106300659
Jai Sri ram

>>106300522 (OP)
I thought the point of types was to make programs more readable and less error prone. Why not just use a dynamic language at this point?

>>106300522 (OP)
too complicated

>>106300522 (OP)
This is some cnile shit tsoding would write unironically and then claim it is superior than C++ function overloading.

>>106300659
The only way Jai is getting released is if Jblow dies and then someone who has the source code just puts it out there. He will never finish it.

>>106300522 (OP)
>Function Overloading
use case?

>>106301239
C++ function and operator overloading are worse than this

>2000+25
>still no function underloading
The absolute state of C.

>>106300522 (OP)
You literally never need function overloading.

>>106301298
>>106301353
You need it for duck typing.

>>106301446
>it's necessary for something unnecessary

>>106300917
CNiles don't actually care and are purposefully being stubborn.

>>106301465
Well, in seriousness, function overloading is static dispatch and C can't really do that except with variadic functions. But it can do dynamic dispatch (with function pointers) and there are various use cases for it.

>>106301314
bait used to be funny

>>106300549
I don't see anything compiler specific, _Generic is part of C11.

>>106301509
>there are various use cases for it
such as?

>>106301509
Function pointers have different use cases than function overloading (which has none)

>>106301655
>function overloading has no usecase
lmao kys

>>106301721
what's the problem?

>>106300922 (checked)
sex with essex

>>106301721
Not a single serious language allows overloading on the return type, it's so obviously retarded that even C++ doesn't implement it.

>>106300522 (OP)
Thanks, that's great

literally irrelevant for all use, unless your magical contract is actually trying for this generic optimization.

>>106301892
You can absolutely return auto in c++

goto programming doesn't have this problem.

>>106300522 (OP)
return 0 no need for main(void).

Would make a fun golf, but i be horrified if had read/debug this.

>>106300522 (OP)
Function overloading is bad design, a function should only take in a single input type and should not have multiple implementations.

>>106300747
_Generic is not bad, though it should have been named something else because it otherwise implies being related to generics programming.

>>106300522 (OP)
no, overloading and preprocessor clever tricks should begone

def f(*x):
print(*x)

Simple. Effortless. You know you deserve it.

The preprocessor is cancer and AIDS
constexpr, inline, code gen macros and modules are how sane and modern languages do things. The only thing you should use the preprocessor for is maybe conditional compilation

>>106300522 (OP)
first part

#include
#include
#include

typedef enum { FI, FII, FD, FDD } F_TYPE;

typedef union F_Data F_Data;
typedef struct F_Struct F_Struct;

union F_Data {
struct { int a; } i;
struct { int i; int j; } ii;
struct { double b; } d;
struct { double d; double e; } dd;
};

struct F_Struct {
F_TYPE type;
F_Data data;
};

#define F1_X(f) ((f)->data.i.a)
#define F2_X(f) ((f)->data.ii.i)
#define F2_Y(f) ((f)->data.ii.j)
#define F3_X(f) ((f)->data.d.b)
#define F4_X(f) ((f)->data.dd.d)
#define F4_Y(f) ((f)->data.dd.e)

F_Struct* make_F_Struct(F_TYPE type, ...) {
F_Struct* f = (F_Struct*)malloc(sizeof(F_Struct));
if (f == NULL) {
return NULL;
}

f->type = type;
va_list args;
va_start(args, type);

switch (f->type) {
case FI:
F1_X(f) = va_arg(args, int);
break;
case FII:
F2_X(f) = va_arg(args, int);
F2_Y(f) = va_arg(args, int);
break;
case FD:
F3_X(f) = va_arg(args, double);
break;
case FDD:
F4_X(f) = va_arg(args, double);
F4_Y(f) = va_arg(args, double);
break;
}

va_end(args);
return f;
}

void print_F_Struct(F_Struct* f) {
switch (f->type) {
case FI:
printf("F %d\n", F1_X(f));
break;
case FII:
printf("F %d, %d\n", F2_X(f), F2_Y(f));
break;
case FD:
printf("F %f\n", F3_X(f));
break;
case FDD:
printf("F %f, %f\n", F4_X(f), F4_Y(f));
break;
}
}

>>106305287
second part

void F(F_TYPE type, ...) {
F_Struct* f = make_F_Struct(type);
va_list args;
va_start(args, type);

switch (type) {
case FI:
F1_X(f) = va_arg(args, int);
break;
case FII:
F2_X(f) = va_arg(args, int);
F2_Y(f) = va_arg(args, int);
break;
case FD:
F3_X(f) = va_arg(args, double);
break;
case FDD:
F4_X(f) = va_arg(args, double);
F4_Y(f) = va_arg(args, double);
break;
}

va_end(args);
print_F_Struct(f);
free(f);
}

int main() {
F(FI, 4);
F(FII, 4, 5);
F(FD, 4.0);
F(FDD, 4.0, 5.0);

return 0;
}


I've tried to implement the version without passing type, but it was so cancerous that I gave up. Type inference with va_list is cancerous combination. Wasted few hours. Never again. Maybe If I was actual C dev I would know how to do this, but I'm not.

>_Generic
why this name? How is it generic?

so just more verbose and uglier pattern matching?

>>106305316
void F(F_TYPE type, ...) {
F_Struct* f = make_F_Struct(type);
print_F_Struct(f);
free(f);
}


somehow the wrong code came there

>>106305060
>>106305175
>>106305214

Why couldn't they make it proper operator. In it's current state _Generic is shit.

>>106305060
>>106305175
>>106305214

For me it's gcc statement expression and __auto_type

>>106305079
It was named after from C99 (type generic math).

>>106300853
>>106300853
>>106300853
>>106300853
>>106300853

>>106305316
Cancer is trying to use complexities such as struct, since you are trying to unite everything into one function..

I.e tunnel vision
keep having fun

>>106300522 (OP)
>function overloading
LMAO, that macro hack should be removed from C, it's a fucking aberration. Pls stop using it, it can only be used for basic types and it's no really "generic" as the name implies. If you really loves C you should not rely on those kind of hacks, fuck the committee.

>>106305573
at least it's normal code
not a macro soup you can't even read

>10X's the compile time
good job retard...

>>106305320
It can select an expression based on the type of another expression. That turns out to be useful for making something that looks like a generic function that takes a range of different argument types.
If you find that hard to understand, maybe C isn't for you, you retard. Or maybe you work at Microsoft on MSVC. Hard to tell which.

>>106304581
Yes, but you can't use the type of the receiving variable to determine which function implementation to call. Too much ambiguity.

>>106300522 (OP)
I wish we had a "bind" operator or something like that to bind types to functions:
int add(int a, int b)
{
return a + b;
}

bind int add;


Then we can use it as if it's a member of the type:
int a;
int b;
a.add(b);

Of course the type can be any type including structs or onions.

>>106305689
You kind of become desensitized to macros after you write a bit, like making one that shits out all the code for a dynamic array for a given type. The macro readability can vary depending on who writes it though and whether it's meant to be header only or not.
What really fucking sucks is debugging them.

>>106300522 (OP)
I just glanced at this and I assumed it was proper overloading. But it's fucking now, it's just a C preprocessor macro.
For what fucking purpose?

>still no real generics
is C the biggest KWAB language of all time? Who uses this shit for real?

>>106300522 (OP)
In JS this is just
function F(){ console.log([...arguments].map(a => a.toString()).join(', ')) }

>>106300522 (OP)
I don't get why people need so many features like C++ being filled with slop every year
Almost no serious project need more than the basics, like every library that does something like loading image files or videos, every program like a video player that is just calling function after function, even a kernel is fine with the normal stuff
But no, academics keep pushing things nobody uses as if it's gonna revolutionize the world

>>106301593
aka not part of C

>>106301892
that's a whole new level of tarded.

>>106307409
C is the quintessential jeetlang.

>>106300522 (OP)
>Function overloading
>pre-compiler gymnastics

At this point it isn't even C anymore.
That's even worse than people trying to emulate classes using structs and function pointers.

There're thousands of programming languages. Just choose the right one for your use case.

>>106306687
Absolutely disgusting. You deserve C# and it deserves you.

>>106307409
You don't need generics.

>>106308713
Yeah, it may not be perfect but it's better than _Generic macro. How would you do it?

>>106308796
>How would you do it?
a += b

print("numbers: ", 10, 20)

>>106301633
>such as?
Imagine you have a computer game and you have monsters and when the monsters attacks they call an attack() function. You could make them call a pointer to an attack function and you could swap the attack function for different monsters so that different monsters have different attack behaviours.

>>106308833
or you can call attack() with the type of monster as an argument and keep your dick intact
git gud

>>106300522 (OP)
Okay, okay, but hear me out. The programmer knows what arguments he is passing so why not call F1_i, F2_id or whatever correctly? Hungarian notation was based.

>>106308872
Imagine there is a state machine for which next() is called. next could be a pointer to a function that could be swapped depending on the state of the state machine.

kneel before me
#include

#define MACRO_ARG_6(_1, _2, _3, _4, _5, _6, ...) _6
#define MACRO_OVERLOAD_4(_0, _1, _2, _3, _4, ...) MACRO_ARG_6(_, ##__VA_ARGS__, _4, _3, _2, _1, _0)

static void print_int(int x)
{
printf("%d", x);
}

static void print_str(const char* x)
{
printf("%s", x);
}

static void print_float(float x)
{
printf("%f", x);
}

#define PRINT_(_x) _Generic((_x), int: print_int, char*: print_str, float: print_float)((_x))

#define PRINT_1(_1) do { PRINT_((_1)); } while (0)
#define PRINT_2(_1, _2) do { PRINT_1((_1)); PRINT_1((_2)); } while (0)
#define PRINT_3(_1, _2, _3) do { PRINT_2((_1), (_2)); PRINT_1((_3)); } while (0)
#define PRINT_4(_1, _2, _3, _4) do { PRINT_3((_1), (_2), (_3)); PRINT_1((_4)); } while (0)

#define PRINT(_1, ...) MACRO_OVERLOAD_4(_, PRINT_1, PRINT_2, PRINT_3, PRINT_4, (_1), __VA_ARGS__)((_1), __VA_ARGS__)

int main(int argc, char** argv)
{
int x = 1;
float y = 3.14;

PRINT("x=", x, ", y=", y);

return 0;
}

https://godbolt.org/z/1nfWTvsqo

>>106308827
you end up hitting the type inference limit
people need to actually study for math to advance language development and research

>>106309313
you already swap and match the state, why bother swapping a function pointer too?
unless you're generating machine code on the fly, I don't see any reason to use function pointers

>>106301239
It kind of is though

>>106309469
Very practical.

>>106307589
no one asked

>>106309537
>I don't see any reason to use function pointers
if conditions cost cycles.

>>106301633
Function pointers have a ton of use cases.
- Dynamically loading plugins, where the main program calls a predetermined init function to receive pointers to functions that it does has no knowledge of in advance
- Passing callback functions to external libraries
- Object orientated implementations
etc

Function overloading has no use case

>>106311172
most of the time they're optimized away

>>106311172
Indirect function calls cost more cycles

>>106300522 (OP)
please don't use generic macros
https://lore.kernel.org/lkml/CAHk-=wjLCqUUWd8DzG+xsOn-yVL0Q=O35U9D6j6=2DUWX52ghQ@mail.gmail.com/

Mental disease

>>106306687
>>106308713
Nta, but I would really love to be able to overload + - * etc. For custom types.
It would be way cleaner.
But, yeah, that's basically the first step to C++...

>>106308174
Autist.

>>106314552
Ruby supports this. I have plans for C since it is how the interpreter was developed, we can get in contact should you wish

>>106300522 (OP)
Just use this https://clang.llvm.org/docs/AttributeReference.html#id608

>>106301465
That is called "a solution in search of a problem".

>>106312438
Only if your CPU is pozzed with branch prediction and pipelining.

>>106311358
A comparison between runtime inputs can't be optimised away (not by the compiler, anyway).

>>106308796
>>106308811
I wouldn't. Overloading is a sin. Just call a function. It's REALLY not hard.

>>106319006
function bodies can be inlined in place of branches though

>>106319285
Fucking nigger, overloading is the bare bone of generic programming, deduplicating code can potentially reduce code complexity
>inb4 macros are better
Kys.

>>106319285
Just "calling a function" requieres some kind of runtime overhead that can be avoided by using an overloaded function, fucking moron.

>>106300522 (OP)
C89 + C++98 without STDLib

>>106300747
And you should for being a pedophile

>>106319437
Generic programming is a sin.
>deduplicating code
At the cost of creating bugs because the function you had in mind works differently for each data type whether you like it or not.
>>106319446
If you are working with ints, do mydumbfunction_int(a, b)
etc
generics were a mistake
I've used them a lot in C++ and it always comes back to bite me either with unexpected behavior or bad performance, and C++ is the best performing language for generics.

>>106319446
just use TinyC as a standard
and PHP as preprocessor

>>106311172
If conditions have a cost only because of branch misprediction and potential pipeline flushes, right?
But isn't the same true with dynamic dispatch? The processor doesn't know where the fuck you are going to be jumping until you do, right?

>>106320628
>branch misprediction
That's only an issue if you are developing for a processor produced in the last 25 years or so.

>>106308174
you're beyond retarded

>>106319483
I will cut your penis and nail it to your skull, so you can transition into a teletubbie.

>>106300522 (OP)
not rejecting what you've done but,
why do you need function overloading in the first place?

why is it not enough to have
fInt(x) and fIntFloat(x,y)?

>>106305316
If you were an actual C dev you wouldn't even have tried.

>>106301892
While is not really overload on return type it looks like that:
#include
class Caster {
const char* str;
public:
Caster(const char* str) : str{str} {}
template
operator T() const {
std::cout << "Not implemented: ";
return {};
}
operator int() const {
std::cout << "int: ";
return std::stoi(str);
}
operator double() const {
std::cout << "double: ";
return std::stod(str);
}
operator std::string() const {
std::cout << "std::string: ";
return str;
}
};

auto f(const char* str) {
return Caster{str};
}

#include
int main() {
int i = f("34");
std::cout << i << '\n';
double d = f("2.3");
std::cout << d << '\n';
std::string s = f("text");
std::cout << s << '\n';
bool b = f("true");
std::cout << b << '\n';
}

https://godbolt.org/z/d9G5qb5en

>>106308827
I'm actually fine with certain functions being essentially "magic" and unimplementable without weird compiler nonsense.

Just like I can't implement a "do-while" loop in go... it's essentially magic.