/g/ - Technology

install openbsd

[Make a Post]
[X]





Nanonymous No.7784 [D][S][L][A][C] >>7802 >>7803 >>7894 >>7908
>be me
>C programmer
>fucking around with function pointers and functions that take a struct with several addresses of all types (including of other structs)
>finish writing my opus magnum
>gcc has a mental breakdown due to the sheer amount of errors
>I may or may not be putting structs inside other struct that will only be defined later
>cant really change it, both structs have pointers to one another
>replace all pointer types with void*
>can't derreference void*
>fair enough
>create lots of placeholder structs that only have void* fields (and are otherwise identical to the original structs)
>struct foo0, struct foo1, ... you get the idea
>make several casts like:
>struct foo0 temp = {address0, address1, address2};
>ActualStruct actualData = (ActualStruct) (temp);
>should work, since they all are made of pointers
>it doesnt work
>gcc whines "error: conversion to non-scalar type requested" and "error: type of formal parameter 1 is incomplete"
C needs to fucking die already.

Nanonymous No.7785 [D]
Did you try a forward declaration for your structs? This sounds more like you do not understand how to write C.
The alternative to requiring forward declarations for when you want to have declarations ahead of time which I have seen in Idris is the mutual block. The mutual block tells the compiler that it should evaluate the types of the functions first before continuing. Due to complications of having dependent types needs to know the type of the function before it gets used.

Nanonymous No.7802 [D]
>>7784
>I decided to write in a language
>I decided not to conform to the spec
Go fuck yourself, this is entirely user error.

If you cannot be bothered to conform to a spec you shouldn't even bother. Why not just whine about non-existent features instead like some user.

Nanonymous No.7803 [D]
>>7784
The problem here is that you are using GCC. GCC is well known for not supporting Standard C/C++, in favor of using GNU C Standard which is a not standard C specifications.
You should use Clang++ or MSVC++ instead, which should fix the problem easily.

Nanonymous No.7804 [D]
Functional is the future.

Nanonymous No.7829 [D] >>7838
>using C
>using function pointers
you are GNU retard
your thread shows how GNU and C are brain damaged

Nanonymous No.7838 [D]
>>7829
>GNU and C are brain damaged
>OP is perfectly fine
ok

Nanonymous No.7845 [D] >>7868 >>7883
C is botnet.

Nanonymous No.7847 [D]
>be me
>speak english
>I can say very mean things with it
>why haven't the jews already spread newspeak

Nanonymous No.7868 [D]
>>7845
And Lua isn't?

Nanonymous No.7883 [D]
>>7845
C isn't a botnet you fucking kike. It was developed by white men from the USA in the 1980s, not by kike shills like you.

Nanonymous No.7894 [D][U][F] >>7895
File: dbfd50ef76f49e5956a779f1faae7636af133f7dba81a228e2971d9ef4a6bfd6.png (dl) (150.81 KiB)
>>7784
The thing about void pointers is that it's supposed to be a pointer to anything (any datatype), so they don't have the data size information (like what the sizeof() gives).
You use void pointers to pass some of the type formality to somewhere else, or to operate on that data with raw assembly language, but to dereference a void pointer you have to typecast it, either implicitly or explicitly.

Here goes some weird test program that maybe helps you. I tried to do it without the "copy" of a needed type but it treated that pointer like of a second structure, with void pointers (which you could still dereference after typecasting, I bet!).

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

typedef struct stuff {
int *var1;
int *var2;
int *var3;
} typestuff;

typedef struct shit {
void *var1;
void *var2;
void *var3;
} typeshit;

int main(void)
{
typestuff mystuff = {NULL, NULL, NULL};
typeshit myshit = {NULL, NULL, NULL};
typestuff *pmystuff = &mystuff;
typeshit *pmyshit = &myshit;
mystuff.var1 = malloc(sizeof(int));
mystuff.var2 = malloc(sizeof(int));
mystuff.var3 = malloc(sizeof(int));
*(mystuff.var1) = 1;
*(mystuff.var2) = 2;
*(mystuff.var3) = 3;

printf("%d %d %d\n", *(pmystuff->var1), *(pmystuff->var2), *(pmystuff->var3));

pmyshit = (typestuff *) memcpy((void *) pmyshit, (const void *) pmystuff, sizeof(typeshit));
typestuff *pmyshitcopy = pmyshit;

printf("%d %d \n", (u_int64_t) pmystuff, (u_int64_t) pmyshit);
printf("%d %d %d\n", *(pmyshitcopy->var1), *(pmyshitcopy->var2), *(pmyshitcopy->var3));

free(mystuff.var1);
free(mystuff.var2);
free(mystuff.var3);

return 0;
}

Nanonymous No.7895 [D] >>7896 >>7897
>>7894
What the hell? Is everyone a programmer on this board?

2 Questions:
Is C the best language?
Also, I know you're hapa.

Nanonymous No.7896 [D][U][F] >>7899
File: 7da777fd1d56f0a1878e66fe6ff5bd4f38b3257c9a14e7a1531e4b4135051e8b.jpg (dl) (124.29 KiB)
>>7895
1) No, since the best language is yet to be created
2) Not a question, but no. I'm white as snow. xD

Nanonymous No.7897 [D][U][F]
File: 126ef9f042e86cf745e59c9980ca153daa338ea4d316134772d8e1c8b5531857.jpg (dl) (196.36 KiB)
>>7895
I'm not because I have 30iq and everyone around me spends their days screaming which makes focus or attention impossible.

Nanonymous No.7899 [D] >>7900
>>7896
best language so far, then?

Nanonymous No.7900 [D][U][F] >>7902 >>7906
File: 591ef070305373a9b073367fdd3631a7e403cda070395bc312e186383451cc68.jpg (dl) (131.10 KiB)
>>7899
What do I look like, a CS professor? xD

Languages I know somewhat, in no particular order:
a) BASIC
b) Pascal
c) C
d) Shell (xD)
e) x86 assembly

I kinda have prejudice against dynamically typed, interpreted, object-oriented and functional languages, as far as being "perfect" goes, and I believe for good enough reasons. All those approaches do not address the "high-level" programming the way I would like them to, so yea, I like C very much. I would try Ada, but apparently there is no free/open source Ada implementation written completely in Ada, so I fail to see the point to use it for some heavy stuff, at least not yet.
But again, I don't KNOW what makes a language good. For me, it's easy and straightforward low-level stuff, i.e allowing "unsafe" things, having lean implementation/runtime and generating fast code. Though recently I've considered a point of language having a well-defined structure and therefore being easy for compiler to optimize. In other words, it would be nice to have a powerful, readable language with a compiler that is relatively easy to implement. Here comes Ada, some subset of which might be just perfect. Might be. I've been under a lot of distractions lately, so I didn't really learn it. xD
Other than that, I dunno. I don't wanna touch languages created by corporations and products maintained by them mostly because they were not made for ME, and it shows, and I am not a professional programmer. Though at the same time, I kinda have to touch it. I'll see if I can change it, but it's a ton of work anyway.

Nanonymous No.7902 [D] >>7904
>>7900
I love how every language on your list is at least 40 years old. 50 if we scratch x86 assembly. Bourne shell is also relatively recent, but we can suppose you were thinking of thompson shell or something older. If I were you, I wouldn't be very hopeful that something is going to come along that's even better, if it hasn't so far, but I guess the thing is to keep waiting.

Nanonymous No.7904 [D]
>>7902
RISC-V assembly?

Nanonymous No.7906 [D] >>7916
>>7900
>some subset of which might be just perfect.
SPARK:
https://en.wikipedia.org/wiki/SPARK_(programming_language)

What are your arguments against functional languages? It is, by far, the most neat thing in PL these last 20 years and open the possibility for dependent types.

Nanonymous No.7908 [D]
>>7784
underage b&
or babbies first year of college in which case still b&

Nanonymous No.7916 [D][U][F] >>7918
File: bda8b55c17a6e8dd470d2647dc09993e958eb683652488c897eb296f5c9f2936.jpg (dl) (152.12 KiB)
>>7906
>What are your arguments against functional languages?
Essentially, they do not improve situation well enough so I (or anybody) would just jump on them ASAP.
Also the implementation for them becomes way too tricky, mostly in the purely functional parts. Immutable data is heavy on memory usage regardless of the implementation, meaning a lot of useful stuff cannot be done that way. Monads are fine, but there are imperative languages way more mature than any of functional languages.
>dependent types
I really didn't understand what they are about, but they look bloat anyway. Like, if I have a possibility of a compilation of my program to actually hang for bullshit reasons, then I'd rather not.
Honestly, I just lean towards UNTYPED languages, but since machines have some specific operations on some specific data well supported, we could use real and integer. You could see structures in C as some types, but the typing there is incredibly weak in the first place and basically structures in C are just some data blocks packed together with some alignment rules, and that's it.
Maybe I'm full of delusions but I grew to hate C++ because of those class definitions for no good reason, which are basically like datatypes. I could construct some object (not in a strict programming sense) without those, thanks. And if we have some crazy complicated type and we get a type error, we might just blow our brains out anyway.

Nanonymous No.7918 [D] >>7922
>>7916
>there are imperative languages way more mature than any of functional languages.
What do you mean by "mature"? Declarative languages are arguably much more "mature" than imperatives, in the mathematical sense. Just look at CakeML.
>but they look bloat anyway
So that's the argument for everything now? Dependent-types is the best solution we have (together with SMT) to solve 60 years of buggy code.

Nanonymous No.7922 [D][U][F]
File: 18a143ccaa165d9342b56e185e2fa01a79056f1d8d1130c2d56fdecb973bac35.png (dl) (141.21 KiB)
>>7918
>What do you mean by "mature"?
Industry use. Performance. Somewhat real-field tested flexibility. I dunno.
I would love to see declarative languages as some DSLs where they work best (and written in other languages), but some imperative general-purpose language to do the work.
>So that's the argument for everything now?
As I said earlier, this is the argument for me. Well, unless people stop being stupid niggers and write better code in "proposed" new languages than it's being written in old languages, which I doubt, unless these new toys become virtually perfect.
>Dependent-types is the best solution we have (together with SMT) to solve 60 years of buggy code.
What's the problem? Legacy code really SHOULD be thrown away or rewritten, preferrably in some GOOD languages, like, maybe even functional, I don't care. Fun fact though - you still CAN write like a nigger in functional languages, and that shit WOULD have some abysmal performance and possibly semantic errors (meaning the code would be correct, but do something not "intended"). Also I find that functional languages are more difficult to learn. Maybe I have an imperative brain at this point though, I don't care. I just want to manage the state.