[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vm / vmg / vr / vrpg / vst / w / wg] [i / ic] [r9k / s4s / vip / qa] [cm / hm / lgbt / y] [3 / aco / adv / an / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / pw / qst / sci / soc / sp / tg / toy / trv / tv / vp / vt / wsg / wsr / x / xs] [Settings] [Search] [Mobile] [Home]
Board
Settings Mobile Home
/g/ - Technology

[Advertise on 4chan]


Thread archived.
You cannot reply anymore.


[Advertise on 4chan]


File: hmc.png (96 KB, 489x858)
96 KB
96 KB PNG
Hello fa/g/gs, I'm kinda new to this whole programming thing, started learning C recently and I was wondering if any experienced cfaggs could give me some pointers (get it? >.< )

Pic related is part of my implementation of a hashmap in C. I'll spare you the details, you can read through the code yourself, it basically has a singly linked list at each slot of the the table so I can resolve collisions by just appending them to the linked list. If the key already exits it just updates the date field. The table doubles in size each time a certain threshold is exceeded although my memory management skills are very primitive, I don't even know how to properly free the old table after creating the bigger one and copying the elements.

Please look at the code and tell me what you think, what should I be doing better.
All of my friends are brainlets and I basically have no one to talk to about this stuff.
You can look at the code here:
https://codesandbox.io/s/affectionate-pine-nonti?file=/main.c
Or you can download it
wget https://files.catbox.moe/kbkiiq.zip
>>
>>83801246
forgot to mention if you want a bigger map at compile time you can do something like
 gcc -DMAP_SIZE=100[/code[
>>
>>83801246
>>
File: 1597088466603.png (1.03 MB, 1210x1958)
1.03 MB
1.03 MB PNG
>>83801297
it can't be that bad, r-right?
>>
>>83801337
just kidding, i dont know how to program
>>
>>83801246
Either gr8 b8 or you're an actual fucking moron.
>>
>>83801432
elaborate
>>
>>83801246
>new to programming
>learning C
that’s like learning to drive with a car from the 1900s. You’re going to spend more time learning to work around C outdated design than learning to program. Do yourself a favour and use Rust, C++, or any language with at least generics.

About your code : at a glance you call malloc but never free() so you are leaking memory. You are allocating your “map” object on the heap unnecessarily. There’s probably more things that are wrong (for example you’re not handling memory alignement). I would advise familiarising yourself with the basics of memory handling and then using a better language.
>>
>>83801549
>recommending rust as a beginner language
No matter how great you think rust is, please don't do that. The borrow checker, for example, shares absolutely no similarities with most other languages, it will be much harder if he wants to go to another language afterwards.
>>
>>83801549
>not calling free()
you're right, I need some sort of deleteMap function
also about the heap allocations, why is that wrong, what if you want to create more than one table that grows and shrinks over time
>memory alignment
i don't even know what that is
>>
>>83801246
>void resize(map_t **entry)
I think you should make the `createMap` function return a struct instead of a pointer to it, that way you could avoid the pointer-to-pointer here. You also don't do any cleanup / memory deallocation anywhere so I don't see the point in setting all those pointers to NULL.
Other than that, you don't really need the `hashmap` variable as it's basically an alias to `entry` parameter.

>void insert(map_t **entry, char *key, char *data)
This for loop really should be a while loop, for the purpose of readability. For the same reason adding `!= NULL` here and there could

>map_t *createMap(size_t mapSize)
>list_t *createNode(char *key, char *data)
Just return the thing by value. There's no need for those functions to return pointers as all dynamic allocations can be handled on the level of map_t's and list_t's member variables

>>83801714
>i don't even know what that is
Don't worry about it, the retard doesn't know either
>>
is this the new rust thread
>>
>>83801246
>>83801246
Terminology:
use capacity instead of size.
use size instead of taken

Avoid using *_t names, if you don't know why, google it.
Remove load member from map_t.
You don't need to cast mallocs in C.
Just realloc() slots in resize. No need to malloc whole hashmap.
>>
>>83801246
What about this?
typedef struct map_t {
typedef struct list_t {
char *key;
char *data;
struct list_t *next;
} *slots;
size_t size;
size_t taken;
float load;
struct list_t *freelist;
} map_t;


You will need to keep a free list of nodes.
>>
>>83801246
>I don't even know how to properly free the old table after creating the bigger one
Use a multistack for memory, debug it find out what the memory requirements are for it, add a little bit to that before shipping.
Don't how you're allocating nodes for list elements, but look into memory pools too.
>>
>>83801750
>Just return the thing by value. There's no need for those functions to return pointers
i don't quite understand what you're implying with this, does that mean that instead those functions would instead take the address of the struct?
Something like
 createMap(&map, size);

please elaborate
>>83801783
>realloc
thanks for this
>>83801823
why would I need to keep a list of free nodes
>>
>>83801714
>you're right, I need some sort of deleteMap function
you need to free the nodes as well

>also about the heap allocations, why is that wrong,
heap allocations aren’t wrong but you don’t need to heap allocate your map_t when it’s just a wrapper for an array of pointers to heap allocated objects

> i don't even know what that is
never mind, malloc is fine unless you use a custom alignment which is what I’ve been doing recently, but you don’t care about that
>>
>>83801962
>does that mean that instead those functions would instead take the address of the struct?
No, they would just return the struct. You can return a struct by value
>>
>>83801962
>i don't quite understand what you're implying with this
Just return map_t itself, as in
map_t createMap(size_t mapSize)
>>
>>83801750
>adding `!= NULL` here and there could
don't do this, "if" already does the cmp and jz and everyone that might read you code already knows it.
everything else is correct

>>83801783
>realloc() slots in resize
wrong. you have to rehash all the elements if you resize the hashmap, otherwise most of the data will become inaccessible

>>83801246
hashmap.c:20 is not doing what you think it's doing. you should traverse the old map, free'ing the slots, which will kill your code's performance even for a small number of entries. I would suggest you to not use linked lists, or, if you want to use linked lists for the slots, at least implement a page allocator or memory pool so you don't have to make 2*N syscalls every time you resize the map
>>
>>83801246
I like both. I just hate C++. I find the lack of consistent style and what has become the Google style standard if "cloudscape" C++ to be hideous and needlessly unreadable. Compare it to STL code and you'll see the difference. C++ (for me) is a victim of its own community. I really like C because of its fine-grain control and Rust because of its power and guarantees. I really like hacking on the Zephyr RTOS (written in C). It is closing in on getting certified for functional safety, so it is gonna (one day) end up in mission critical applications.
>>
>>83801962
>why would I need to keep a list of free nodes
He suggests an optimization where instead of deallocating your nodes you keep them in a separate list and instead of always malloc'ing new nodes (which might be slow for some uses) you could first check if you've got some stashed in the free list. It's a frequent optimization for things dealing with linked lists (though not without its pitfalls), but I wouldn't sweat over it while you're just learning.
>>
also i didn't think of this until now but how will be able to access keys that hash to a different index then their original index after I resize the table, since now the table size is different and the range of indexes I will get is bigger
should I keep track of the somewhere
>>
>>83802197
>>83802066
>>
>>83802197
That's what rehashing is for. You need to reposition all the elements after growing the table.

>>83802066
Anon is clearly just learning C and algorithms, performance concerns should come later. Don't pile up too many things at once.
>>
>>83802066
>everyone that might read you code already knows it
that's the type of retarded assumption everyone makes and then wonders why C code is so error-prone
>>
>>83801246
Don't have the time to take a closer look and it's most certainly full of bugs. Just wanted to say that for a newbie this is totally fine.
I remember a little section about implementing a hash map in the K&R book. Don't recall whether resizing was part of it but reading that might help you anyway.
Best of luck.
>>
hey look at this c i wrote, do you like it?

#include <stdio.h>

int main() {
printf("Hello, world! \n");
return 3;
}
>>
>>83802414
>printf
use puts
>>
File: EL-0VH5X0AYVfje.jpg (258 KB, 2047x1556)
258 KB
258 KB JPG
>>83802414
>space before newline
>>
>>83801246
i don't know what you're shilling, but you reek of it. go the fuck away
>>
>>83802470
what is the difference? or rather why is puts better than printf?
>>83802482
i have removed the extraneous space
>>
>>83802414
Based
>>
File: 1617909751527.png (294 KB, 396x476)
294 KB
294 KB PNG
>>83801549
You mean spending more time learning to program than learning modern monkey standards. It's like learning to drive a car from the 1960s instead of learning to drive a "car" that keeps getting upgraded from car to bike to bike with training wheels to tricycle to tricycle with training wheels.
>>
>>83802514
Also the parts are getting updated with modern equipment, so it runs much better even with the same instructions.
>>
Can an array be a dynamic size or is that illegal? What's the best way to make an array that is big enough but not to big?
>>
>>83801549
Fuck off back to Python

>why learn to drive a car when you can just Uber?
>why learn math when you can use a calculator?

Learning the fundamentals of what programming languages do under the hood is 10x as important as learning basic programming.
>>
>>83802708
where can a find a c mentor?
>>
>>83802514
>You mean spending more time learning to program
No. Any language without generics is a waste of time. You can’t even write basic generic data structure in C. It’s utterly pointless and unrewarding as a first language. Understanding generic programming and advanced uses of type systems is an enormous part of understanding programming, and you’re not going to learn any of this with C.
>>
>>83802708
learn to read, retard.
>>
File: 1604518977191.jpg (582 KB, 1242x909)
582 KB
582 KB JPG
>>83802323
>rehash
thanks for that, this looks fucking slow as fuck but it seems to work
    for(size_t i = 0; i < oldMap->size; i++) {
list_t *current = oldMap->slots[i];
while(current) {
size_t idx = map(current->key, strlen(current->key), newMap->size);
list_t *next = current->next;
current->next = newMap->slots[idx];
newMap->slots[idx] = current;
current = next;
}
}
>>
File: real taxi.png (1.67 MB, 1085x1280)
1.67 MB
1.67 MB PNG
>>83801246
>rustoids NOT welcomed
>I'm kinda new
lmao ngmi
>>
Am both a Rust user and an experienced C programmer. I'll help you with this despite you saying I am "not allowed", because I do not respect your opinions and I do whatever the fuck I want.

>Please look at the code and tell me what you think, what should I be doing better.
Let's start with your design choices. You want to implement a hash table... there are several ways to do this, but you're going with an inefficient strategy, even if it's maybe easy to implement. If you're going to use chaining instead of probing (which would have you using a flat array for a hash table, rather than an array of lists), why use a linked list? You could instead make a vector, which would be more cache efficient.

Beyond this, I have noticed that your codebase has no functions for freeing anything. Also, createMap returns a map_t* rather than taking a map_t* as input and initializing it in place. What if I wanted to create a map_t data structure on the stack? This API might make sense if you were using PIMPL, but you have exposed the implementation of your data structures in your header file, effectively locking you into that implementation for forwards compatibility.

>I don't even know how to properly free the old table after creating the bigger one and copying the elements
To be fair, your resize() method doesn't even handle the copying right either. You perform a shallow copy of the lists, rather than rehashing everything to take advantage of the new number of slots. You want to instead rehash the entire table, creating new linked lists from scratch if there are collisions. Then you want to free the old linked lists (note: free the deepest nodes first and work backwards recursively), and finally free the old table.
>>
>>83801962
>why would I need to keep a list of free nodes
To easily find which is unused to then allocate value to it. Free list are cool because you can interweave them through used memory without using more memory.
>>
>>83802911
I'll look into that, sounds interesting
>>83802908
>PIMPL
kek
also it's fixed now, i don't want to free the nodes, I just want change the pointers and free only the heads and the old table
>>
>>83802729
Go to school or learn it yourself

>>83802754
The concept of generic data structures means absolutely nothing to a beginner programmer.

C is a fundamental language for understanding what good programmers do. It's dope that you can import whatever you want with newer languages but looking up API calls in OpenCV is a useless skill.

Getting good at C literally makes you a better programmer. Getting good at high level language makes you good at that language.
>>
>>83803098

>i don't want to free the nodes, I just want change the pointers and free only the heads and the old table
Anon, if you're going to increase the number of buckets in your hash table, your hashing mechanism necessarily needs to be changed to accommodate this. Once you have done this, it may not necessarily be correct that the elements in your list belong in the same bucket. As such, you need to rehash EVERYTHING or your linked list is now incorrect. Once you have performed the rehashing, you should free those old lists because they are now functionally useless. And if you free only the heads rather than freeing the deepest nodes first, you will necessarily have a memory leak.
>>
>>83803184

>Getting good at C literally makes you a better programmer. Getting good at high level language makes you good at that language.
Can confirm this. Knowing C (and C++) has made me a better Rust programmer.
>>
>>83801246
>reddit style spacing
>insufferable font that makes eyes bleed
>(>.<)
you have to go back
>>
>>83803306
here's a quick shell script to test to generate some some code and random data to populate the tables and test things out, benchmark it etc
grep -m 400 -Ewoi '[a-z]{12}' /usr/share/dict/words | shuf | 
nl -n'rz' -w 3 -s' ' | sed -E 's/([[:digit:]]+)\ ([[:alpha:]]*)/insert\(\&hashtable, "KEY\1", "\2"\);/g'
>>
>>83801246
Post tits, or if you have a cock, post it in panties
>>
>>83803184
>C is a fundamental language for understanding what good programmers do.
>Getting good at C literally makes you a better programmer. Getting good at high level language makes you good at that language.

C is not some kind of fundamental programming language. It's an imperative language just like the dozen of imperatives language out there. Being a "good programmer" means knowing how to look at a problem in various ways and knowing a wide range of programming technics to write elegant and efficient code. C give you literally zero tools to abstract over things and forces you to think about trivial bullshit over and over.
>>
>>83803689
better one
grep -m 4000 -Ezaoi '[a-z]' /dev/urandom | fold -w 100 | shuf | nl | 
sed -E 's/\s+/ /g; s/\s([[:digit:]]*)\s(.*)/insert\(\&hashtable, "KEY\1", "\2"\);/g'
>>
>>83804173
That sounds like monkey cope from being unable to think of those "technics" yourself and copy pasting syntax that does it for you in a generic slow way that you can't fuck up with your monkey brain. Elegant and efficient for you and me are opposite, I like to read pure sequential logic, you like to read syntax you've memorized spread over 1000s of files calling 1000s that you don't care about it's inner workings since it's pandora's box inside them.
>>
>>83802908
>As a Rust user
>you want to free the old linked lists
>>83803199
>you should free those old lists
kek the meme is true, rust trannies really can't do linked lists. I always thought it was due to some limitation in the borrow checker, but it turns out they're just fucking retarded and can't deal with pointers without that crippled borrow checker propping them up. he's *rehashing* - all he should do is relink those nodes into their new correct lists.
>>
>>83804282
You are a fucking idiot who thinks he's "le epic hacker" because you only know a language which is utter dogshit by any modern standard. The fact that you have to write the same garbage spaghetti code and are unable to write (or understand) any kind of useful abstractions doesn't mean that you know anything about performance, it doesn't even mean that the code you write is "close to the metal". If you want to learn about performance, learn about how optimizers and how memory works. You obviously never read about any of that else you wouldn't be claiming that "muh abstractions and monomorphizations are inefficient". Kill yourself.
>>
>>83805414
Cope wagie, all those things were invented to let stupid people in, your standards only exist to let you fit in with the bottom of the barrel of intelligence, which may be you.
>>
>>83802514
>>83802754
assembly doesnt have this problem
>>
>>83801398
lol
it's not difficult. just do it.

i know the basics taught in the primers (c/c++/c#) but i am unable to implement libraries since i am unable to understand them.

this is where my teachers failed me and i failed myself, we are all to blame, yet none want to take responsibility.
>woah, is me?
>>
>>83801445
he's making a statement where he alludes to the OP being a troll while giving the OP the benifit of the doubt that he might be mentally retarded.
both being possible, he gives the OP the opportunity to chose.

this is quite ingenious in itself, since it counteracts the bait that the OP put by disparaging the theme of his thread, while at the same time, if the OP was sincere, he allows the OP to acknowledge his ignorance in humility, which would allow for a redemption through other users of /g/.

i'm a retard btw, i sincerely dont know where i am.
>>
>>83801549
the first language i learned was c#
when i look at c it makes more sense than c#.

c# is dependent on intricate knowledge of the whole framework in order to utilize it, while c allows the individual to build everything from scratch, meaning that the individual (not just the program) is being built up in the process.

had i learned c first, c# would've made more sense to me when i first began
>>
>>83805772
>when i look at c it makes more sense than c#.


In most modern languages, you can read iteration code like a book:
 iter1
.cartesian_product( iter2 )
.filter(..)
.take(S)


In C-land its:
 Object** resulting_list = ..; 
int list_cursor = 0;
for (int i = 0; i < N; i ++){
for(int j = 0; i < M; j++){
if( filter_predicate && list_cursor < S ){
resulting_list[list_cursor++]=&list_of_items[i][j];
}
}
}


You are not gonna convince anyone that C not a fucking mess. Reading C code is one step removed from reading assembly.
>>
>>83807518
it's not a mess.
what the previous code doing it's being done in the latter.

it's just hidden

in the latter you know what the formula is, in the previous you only now what it's called and dont understand how it works.

it's like comparing scriptkiddies running the code with the people that actually wrote the scripts code

one is retarded the other one works on not being retarded.
>>
>>83801246
>Pragmata Pro Font
very nice
impressive
>>
File: 1483888302909.jpg (100 KB, 1440x810)
100 KB
100 KB JPG
>gotten quite good at C from adding features to softwares that I use (mostly suckless software)
>there's a bug in a cpp software that's bothering me
>shouldn't be too hard to fix
>the code seems to be abstracted beyond insanity

is this supposed to be how all cpp projects are written in? i cant figure a damn thing out on how this shit works. on suckless stuff i literally just search a word, like "bar" and look for matching function and i'll figure things out, here it seems like it's all magic. wtf.
>>
>>83801246
>(get it? >.< )
stopped reading there, fuck off
>>
>>83801549
This is how they get you. First they make you worried about memory management and before you know it you've cut off your dick.
>>
>>83808403
Welcome to Bjarne's wondrous, magical realm.
>>
>>83802708
>C is the same as the fundamentals of programming
it's sad that many people think this
>>
>>83801549
>new to programming
>recommends the most difficult languages, Rust and C++
absolute retard take
>>
>>83802708
i bet you can't invert a binary tree
>>
>>83808403
C++ is insanity. It gives abstraction as a whole a bad name.

Don't waste time with C++ like I did, fully accept that it's a broken language beyond saving and move on.
>>
>>83802908
>This API might make sense if you were using PIMPL, but you have exposed the implementation of your data structures in your header file, effectively locking you into that implementation for forwards compatibility.
Thank you for explaining the real reason why C++ classes are fundamentally broken.
>>
>>83808539
No it isn't. C#, Java, Kotlin and Go ( this year) are decent options for your first language.

C is worth learning only because it is currently the "glue" that binds everything together, but that will inevitably change. So yeah implement some data structures in C, do a few small things in it, but ditch it immediately once you get the gist of it.
>>
>>83804296
are you fucking stupid?
>>
>>83803184
>C is a fundamental language for understanding what good programmers do.
Which is avoiding C (and C++, for the matter) whenever possible.
>>
>>83804282
I know this is bait but I'll bite:

People who think this shit in real life are insufferable faggots who have 0 concept of how much abstraction there already is between them programming in "real" languages bare metal. The amount of abstraction that's achieved by going from logic gates to C is fucking astronomical, and you could probably never achieve writing a C compiler from bare metal in your entire life if it weren't for the work of hundreds of years of mathematicians working all this shit out for you. Comparatively, the jump from C to Python is minuscule in the grand scheme of things. Sure it might abstract away a few data structures and make things nicer to use, but it's nothing compared to carefully organizing bits of sand together in such a way that they perform actual computation.

Computer science and abstraction are tied together at the hip. Losers who can't understand that the continuous abstraction of mathematics is the very essence of computing are the most obnoxious fucking faggots in the world. The losers who can't understand that it's actually harder to think abstractly are the funniest of them all. Sure you can do the equivalent of hand-holding a modern abacus. You're not accomplishing anything by reinventing the wheel for the thousandth time, you're just doing it because someone needs some retarded shit to be fast, but you're not furthering the field of computer-science. You're not developing new fucking algorithms in C, you're implementing something that someone (far smarter than you) has already thought of in a slightly different flavor just so you can get a paycheck.
>>
>>83801549
C++ is the single worst language out there, especially for beginners. It will make them (wrongly) think that programming is about remembering what a prxfervalue or avoiding the most vexing parse, when it's not.

Anyone who genuinely recommends C++ as a first language is almost certainly a terrible programmer.
>>
>>83808652
>denies it
>instantly backpeddals
retard
>>
>>83808717
I didn't backpedal on anything fuckwit. Using C for most software projects is 2021 is absolutely fucking retarded.
>>
>>83801549
>Do yourself a favour and use Rust
That's like sawing off your balls before trying out a skateboard.
>>
>>83808740
in what way is a learning exercise like the OP a "software project", my retard anon
>>
>>83808740
I agree, but C++ and Rust are even worse.
>>
>>83801246
The language in which you can express yourself and get the most result is your best language.
Whether that's C, C#, Python or haskell
>>
>>83809493
I agree.
>>
>>83808712
Not really desu. I tried JS as my first language 5 years ago, didn't like its design so I made a switch to C++. I mainly learned from Bjarne's books back then - they're written fairly well and don't throw any complicated concepts at newbies in the first 500-600 pages. After that, I learned C and NASM. The more complicated and abstract C++ came later, when I was prepared for it.
It may not be the perfect language; it's far from it actually. But it has some nice features and it's not that bad if you're willing to learn it.
>>
>>83809493
You don't program.
>>
File: sensible-chuckle.gif (1.91 MB, 250x250)
1.91 MB
1.91 MB GIF
>>83801549
>mfw i learned programming with java
>>
>>83808429
Kek
Actually chuckled.
>>
>>83808429
Memory dysphoria
>>
File: free.png (101 KB, 804x775)
101 KB
101 KB PNG
>>83801246
>Update
Am I doing the freeing properly anons?
>>
>>83810397
of course I forgot the
free(map);
after the
free(map->slots);
>>
>>83801246
is there a specific reason why you ordered those structs in that particular way?

why is list_t **slots; the first element and not the last one?
>>
>>83810742
there's no difference, I just wrote things as they came to me
>>
>>83807518
even though your c example is written in a nigerlicious way and nobody would actually do it this way, its still way more readable than whatever nigger garbage that first example is
>>
>>83802708
you first learn to breathe before you learn to walk alien.
>>
>>83809493
>express yourself
if you said rust you would of confirmed yourself a tranny
>>
>>83810924
I could read those C lines but not the niggercode above. just shows how C is actually still viable and I didn't even touch C
>>
>>83802708
>he fundamentals of what programming languages do under the hood
Hint: programming languages other than C don't have to be implemented in C, and in fact they often aren't.
>>
>>83801246
Is there a reason your API uses a double pointer to the map? Seems to me like a single pointer would be sufficient?
>>
>>83808712
>>83808539
yeah dude just learn with C and reimplements dynamic arrays a thousand time while leaking memory, using your brain to remember to call free() and work around C garbage type system is more important than learning how to write real code, that’s what real programmers who love coding close to the metal do!

you fucking idiots. During my first year at uni we used C++ for the introductory course to programming and it was piss easy for everyone. We used std::vector on the very first day.
>OH MY GOD HOW ARE BEGINNERS GOING TO UNDERSTAND WHATS A TEMPLATE
you fucking retards drive your cars everyday without understanding the engine. I guess it’d be better to teach dynamic allocation and C whack-ass syntax on the first day instead of doing anything interesting. you piss on C++ without even realising that the causes of its accidental complexity is precisely because it try hard to make things simple for beginners.
>>
File: 1622097031193.png (446 KB, 750x632)
446 KB
446 KB PNG
>>83812312
FP is a meme, imagine making a whole new language and syntax for everything just to get around POTENTIAL problems with mutable state if the programmer fucks up, it's almost as bad a Rust trannies safety meme...
>>83813743
Allocate memory to the heap, remove it, wow that is hard, better learn 1000s of syntax in my programming socks so I don't have to remember to free my memory when it's done, if only it reminded you that you didn't free it by maybe slowing down the program or crashing.
>>
>>83813777
imagine trying to use the word "tranny" as an insult while being an unironic tranime poster
>>
File: 1627789480266.png (379 KB, 534x584)
379 KB
379 KB PNG
>>83813873
Actually I don't think essex ever appeared in the anime.
>>
>>83802508
the compiler will optimize to puts anyway
>>
Friends,
Does anyone have a minimal working TCL-based test setup? I tried to look into both redis's and sqlite's test suites but they seem very complex.
Alternatively, how can I test C code? I'd prefer to do write the tests in a scripting language so I can develop the tests faster.
>inb4 u test it by running it lul
>>83814291
I've been bamboozled.
>>
>>83813777
>C is a meme, imagine making a whole new language and syntax for everything just to make everything worse
At least the FP guys think they're making something better. C guys knew their language was worse than what came before and they still shilled it anyway.
>>
File: 7e1.png (358 KB, 680x680)
358 KB
358 KB PNG
>>83813903
All anime posters are trannies. That's why it's weird /pol/ getting upset about trannies. Most of the AWOOOO, maga, anime posters were trannies. Same with /ptg/.
Why did they suddenly start getting upset with trannies. Why did it correlate to Biden becoming president.?
Wtf?
>>
>>83814821
>t. tranime poster
>>
>>83813743
>During my first year at uni we used C++ for the introductory course to programming and it was piss easy for everyone
That's because you didn't actually use it. University courses don't really show you anything, you haven't seen the whole horror of it. Also
>the only alternative to c++ is c
>>
>>83813777
Why are you bringing up FP?
>>
>>83801246
1. don't make 'load' a float, and remove it if you can. having lots of ints then just a sole float hurts vectorization
>>
>>83815443
2. try to use uint8_t* instead of char*, keys and data don't appear to be strings so it seems wasteful to treat them as such
3. try to manually unroll your hash function i.e.
size_t map(char *key, size_t len, size_t mapSize) {
size_t idx = 0x811c9dc5;

for (size_t i = 0; i < len / 8; i++) {
idx = (idx ^ *(size_t*)(key + i * 8)) * 0x01000193;
}

for(size_t i = len / 8; i < len; i++)
idx = (idx ^ key[i]) * 0x01000193;

idx %= mapSize;
return idx;
}


i haven't compiled above code (can't figure out the shitbox you just posted) so idk if it works but you get the idea
>>
>>83815555
alternatively,
size_t map(char *key, size_t len, size_t mapSize) {
size_t idx = 0x811c9dc5;
for (size_t i = 0; i < len; len += 8) {
idx = (idx ^ *(size_t*)(key + i)) * 0x01000193;
}

for(size_t i = len / 8; i < len; i++) {
idx = (idx ^ key[i]) * 0x01000193;
}

idx %= mapSize;
return idx;
}


4. always put braces, even around single-line control flow statements
5. simplify your struct initialization. If you're initialising heap memory to 0, you can use calloc:
map_t *createMap(size_t mapSize) {
map_t *newMap = (map_t *) calloc(sizeof(map_t), 1);
newMap->slots = (list_t **) calloc(mapSize * sizeof(list_t *), 1);
newMap->size = mapSize;
return newMap;
}

6. linked lists aren't necessary for buckets. Just use unsized arrays. It will invalidate pointers, but in a hashmap that's a given.
>>
>>83815769
whoops
size_t map(char *key, size_t len, size_t mapSize) {
size_t idx = 0x811c9dc5;
for (size_t i = 0; i < len; i += 8) {
idx = (idx ^ *(size_t*)(key + i)) * 0x01000193;
}

for(size_t i = len - (len % 8); i < len; i++) {
idx = (idx ^ key[i]) * 0x01000193;
}

idx %= mapSize;
return idx;
}

it's been a while, the point isn't the tedium, just the idea of merging loop iterations
>>
File: girl.jpg (80 KB, 500x749)
80 KB
80 KB JPG
>>83801246
>That Pragmata Pro.
>>
>>83802729
I can mentor you kid. But I will require compensation if you catch my drift
>>
>>83816225
What kind of compensation
>>
>>83810397
no. use python
>>
>>83814821
congrats on coming out
>>
>>83801246
stop.
use python
>>
>>83802414
in haskell this is just
main = putStr "Hello, world! \n" *> exitWith (ExitFailure 3)
>>
>>83802908
>PIMPL
Don't search this shit on DDG.
>>
>>83807518
Now explain what this actually looks like running against a CPU.
 iter1
.cartesian_product( iter2 )
.filter(..)
.take(S)


No one knows. It's all abstract, there are hidden inefficiencies. You can't tell me what that reduces to.
The latter program you can at least make some predictions about what machine code it will output.
That's why C is preferred for high performance applications - because it maps better to what a physical machine actually does.
>>
>>83815769
>4. always put braces, even around single-line control flow statements
pajeet-tier advise
>>
>>83818996
t. rajesh
>>
>>83818960
The compiler can evaluate as much as possible at compile time in a normal language, but in C, it has to call a library function that happens to manage a free list of memory blocks, add an integer to pointers, and call a function on each pointer. The C doesn't know anything about arrays or lists. The normal language can tell that this is an array or list (it's generic) and if it's given constant expressions, the whole thing is a constant expression and you can get an array or list at compile time.
>>
>>83819477
Yes, the compiler can evaluate a lot of things but the problem is that YOU can't. You have no idea the kind of job the compiler is going to do. You're off on Pluto hoping some machine will take you home.
>>
>>83819477
The compiler does optimize pointer and memory manipulations, the compiler can optimize much more than you realize
>>
>>83818960
It doesn't matter. Same as knowing the layouts for circuits responsible for arithmetic opcodes look like.
>>
>>83801549
Nigger not every problem requires c++. When efficiency is absolute must, you use c.
>>
>>83821680
It does matter if you're building a spice layout that you can't actually look at and an autorouted bus is going all over the place so you end up with shitty latency and poor bandwidth.
>>
>>83821715
>knowing what X does exactly if you're directly interacting with X
you're grasping at straws and you know it

Also, if your point is "I need to know EXACTLY what it does when run", using a simulator is a really bad example. The machine you're interacting with doesn't actually contain the thing you're designing, it's literally one giant abstraction layer between the computer simulator is run on and the desired simulation.
>>
>>83801549
>that’s like learning to drive with a car from the 1900s.
Oh no, you will learn to drive better and know how to care for your car, how terrible?
>>
>>83801246
no idea what the fuck is happening in your code, documenting your own code is important.

Use header file.
>>
>>83821975
It's very simple - you can look at the C, look next to it at assembler output and have a very clear idea of what you need to do to get it to optimal machine code. You do not have that with other languages. The change of a single method could result in significant downstream changes which means you effectively lose control of the processor or, if you do manage to wrangle it somehow, someone else could come along and change your routine in some very subtle way breaking all of your optimization efforts. The more abstractions you pile on, the more control of the hardware you lose.
There is a price for that syntax sugar.
>>
>>83822097
it's very simple, you're backpedaling
and don't bundle us together, just because YOU don't understand doesn't mean we're all as retarded
>>
>>83822174
>backpedaling
>i m going to sling random words against the wall without knowing what they mean
k
>>
>>83822235
>abstraction bad
>it doesn't matter
>n- no, in this here case having no abstraction is a must
>it's literally one giant abstraction layer
>b- but abstraction bad
>>
>>83822097
>optimal machine code
if you were being honest with yourself you'd acknowledge that only a small fraction of code in most pieces of software need to be aggressively optimized. This is why profiling is important. Reducing asymptotic complexity of the code is more important and yields the biggest speed gains. Also most software has to run on multiple architectures so trying to squeeze every fucking cycle out of the machine is a fucking waste of time and money and is often impossible.
>>
>>83822253
>strawman
>black and white fallacy
>strawman
>black and white fallacy
>strawman
>if I engage repitition
You're breaking down. Incidentally no backpedaling was done. I haven't reversed my position, I simply realized you were too retarded to understand an analogy in a domain you yourself brought up by way of analogy that you clearly don't understand - likely hoping I didn't understand it either so as to score points over my lack of expertise.
You were the one who first went off in an unnecessary tangent on digital circuits. Own it and don't accuse me of going where you led after I called your bluff.
With circuit design you can at least see the board being created. I doubt you've looked at the assembly output of that code you produced. You probably don't even care.
People who design high performance software care just like people who design ICs and boards want to physically see what routes are being created. They don't just plug some shit in and ignore the results.
>>
>>83822288
That's always been a nonsense position to take invented by arrogant, lazy programmers to explain away their laziness. Maybe if you weren't so pigheaded you'd understand a simple concept - you aren't the sole owner of the machine your software runs on. When thousands of other programmers become as lazy and greedy as you are then the whole thing becomes a tragedy of the commons scenario where OSes and software are collectively bloated shit and no one wants to take responsibility for it even though they all are.
>>
>>83822308
>You're breaking down. Incidentally no backpedaling was done. I haven't reversed my position, I simply realized you were too retarded to understand an analogy in a domain you yourself brought up by way of analogy that you clearly don't understand - likely hoping I didn't understand it either so as to score points over my lack of expertise.
lmao buddy try not to break down crying

>You were the one who first went off in an unnecessary tangent on digital circuits. Own it and don't accuse me of going where you led after I called your bluff.
My example was consistent with my opinion. Yours wasn't.
>With circuit design you can at least see the board being created
>want to physically see what routes are being created
There is no board, no routes are being created, it's a simulation. You're interacting with an abstraction layer, an abstraction layer to which you convey the meaning of what you desire, "a circuit like this", rather than the precise implementation of computing what you want. Same as product, filter and take convey the meaning, rather than the precise implementation. Same as a opcode conveys the meaning, rather than the precise implementation. Same as a multiplication circuit conveys the meaning rather than the precise implementation. Same as logic gates convey a meaning rather than a precise implementation. Same as transistors convey a meaning rather than a precise implementation.

You seem to think that if you understand what the abstraction is modeling then it ceases to be an abstraction. I can only conclude that you can't understand the functional approach to iteration, which isn't that surprising since C fags have problems grasping anything more complex than a for loop. Maybe stop posting and go study up because "I know the asm for that" is typical brainlet behavior and you keep coming back to that particular cope
>>
>>83801549
>that’s like learning to drive with a car from the 1900s
what's bad about learning to drive in a car from the 90s?
>>
>>83822553
you forgot to put your glasses on again, grandpa cnile
>>
>>83822510
And in these "abstractions", like A*, have visible results. When you build a board you see the board. You're looking right at it. The computer worked the paths out, true, but you're get to see the results and make sure nothing crazy is going on. The board is itself the printout of the application.
In your case, however, you have no machine printout. You throw it away. What you have is a black box with presumably board in it and no idea what's going on underneath. You don't want to look at it either because you know it's a nest of wires that cannot be unwound by a person.
And that's why I pointed out your black and white fallacy. You strawman my position by claiming I said the argument is between abstraction and no abstraction. No, the argument is between targeted abstraction and abstractions piled so high you don't even know what you're standing on.
If I wanted to say fuck abstraction altogether, we'd be talking about assembly vs everything else. I'm talking about C because it's abstract enough to be an order of magnitude faster to write a working program in vs assembly but still close enough to reason about what's going on. The gulf between C and assembly in terms of productivity is much wider than C and insert your favorite language X... and the gulf in performance between C and assembler much narrower.
You've gained less and given up more.
>>
What I really dislike about people criticizing C is that, while they do point out many valid flaws, they end up recommending shit like Sepples which is even worse by every metric.
>>
>>83822566
training without assistants and abs and power steering and stuff will obviously make you the better driver, why wouldn't you take advantage of that?
>>
>>83810397
May want to turn recursion into a loop.
>>
>>83822607
>What you have is a black box with presumably board in it and no idea what's going on underneath.
This applies to the simulator. You don't care whether it really has a board inside it or not, you only care about the output being right.
>You don't want to look at it either because you know it's a nest of wires that cannot be unwound by a person.
You're confusing the analogy of the circuit simulation program being an abstraction layer with the analogy of what you're modeling in it. And once again it's a (You) problem, if you can't understand it

Do you think the functions in >>83807518's first example are run just for fun? That
>You throw it away. What you have is a black box with presumably board in it and no idea what's going on underneath.
The output, the meaning you want to extract in both examples (well, the 2nd one is wrong, but in principle) isn't an array, or a tack of iterators that can lazily evaluate. It's the values that fit the conditions of the product of two collections, filtered by some condition, then first 5 of those values.
The 1st example gives you that answer (and 2nd would too if it was written right).
You keep arguing for implementation-focused approach, but your example is decisively result-focused and I don't know how are you still failing to grasp it.
>>
>>83822639
please grandpa, glasses
>>
>>83822935
>This applies to the simulator. You don't care whether it really has a board inside it or not, you only care about the output being right.
If you only have one concept of being "right" - it produces correct output. There are other formulations of right - namely it gives the correct, or even an approximate answer that is "good enough", and meets a whole bunch of performance, timing requirements and cost requirements.
That's the difference between practical computer engineering and abstract pie-in-the-sky-wannabe-mathematician computer science. The end user doesn't generally care about how pretty your code is. They'll never see it. It's effectively masturbation.
And those circuit simulators are not as abstract as you think, using none of the features you believe would qualify as a good language.
More importantly than that, DSLs that simulate circuits are in the exact opposite direction of abstraction/generalization and more towards high specialization. They don't throw away relevant information about circuits. C is a language that doesn't throw away relevant information about the CPU. The languages you offer to replace C do throw away relevant information - tons of it. I don't even know why you brought the subject up to begin with.
>>
>>83823004
what are you trying to say?
>>
>>83823091
>If you only have one concept of being "right" - it produces correct output. There are other formulations of right - namely it gives the correct, or even an approximate answer that is "good enough"
those are the same definition, but one of them has looser tolerances than the other
>and meets a whole bunch of performance, timing requirements and cost requirements.
none of these criteria are part of the "right answer" criteria, they're part of the efficiency criteria.
>And those circuit simulators are not as abstract as you think, using none of the features you believe would qualify as a good language.
Again you're messing up what is being talked about. We're not talking about the abstractions inside the code of those simulators. We're talking about the entire concept of simulation which by definition is an abstraction.
>They don't throw away relevant information about circuits. C is a language that doesn't throw away relevant information about the CPU. The languages you offer to replace C do throw away relevant information - tons of it.
At this point you're resorting to a literal word soup. Stop desperately trying to conjure up a point about things you clearly don't understand and go back to learning.
>>
File: file.png (2 KB, 150x33)
2 KB
2 KB PNG
>>83823161
https://youtu.be/QxfHMtgg2d8?t=300
pro tip: none of this is even remotely relevant to handling a modern car, with the sole exception of "it rolls on wheels and you turn the steering wheel to turn"
>>
>>83823091
>I don't even know why you brought the subject up to begin with.
>>83822607
>You throw it away.
>>
>>83823174
>none of these criteria are part of the "right answer" criteria, they're part of the efficiency criteria.
Which brings us back to where we started. Language A is too abstract to achieve efficiency easily, language B is not. But it is part of the "right answer" criteria. Right answers don't matter if you don't finish turn in your test on time.
>Again you're messing up what is being talked about. We're not talking about the abstractions inside the code of those simulators. We're talking about the entire concept of simulation which by definition is an abstraction.
That's what your strawman version of what we're talking about is. What I'm talking about is the right level of abstraction vs overabstraction. The right abstraction doesn't throw away relevant information. Overabstraction does - and it's my contention that example A throws away too much relevant information about the CPU on which it operates. You have somehow transformed this into some kind of referendum on abstractions in general; suggesting I want none and you can't move on from your own misconceptions.
>At this point you're resorting to a literal word soup. Stop desperately trying to conjure up a point about things you clearly don't understand and go back to learning.
Seems I struck a nerve because I refuse to stay boxed into your false conception of what my argument is. Stay triggered.
>>
>>83823197
lmao, maybe i SHOULD get my eyes checked
but then it's not that good of an analogy anymore since you're still using all of the C stuff in Rust
>>
>>83823233
Yes, in your case... by ANALOGY, your highly abstrated faggotry is wholly unlike a circuit simulator because you throw away relevant information about the architecture you run your software on while the simulator MODELS it! It's not that hard to understand that your analogy is shit.
The simulator is an appropriate abstraction. Your code is not.
>>
>>83823233
By comparison C is also based on an abstract machine - but the abstraction is close enough to how a real machine operates that you can make certain predictions about what it outputs.
You cannot do that with the kind of languages you describe. They're not modeled off of hardware, but an academic masturbating in his own mouth.
>>
>>83823235
>Language A is too abstract to achieve efficiency easily
no it isn't
>Right answers don't matter if you don't finish turn in your test on time.
yes they do, knowing whether it will produce the right answer determines whether it will be run at all

>The right abstraction doesn't throw away relevant information
>it's my contention that example A throws away too much relevant information about the CPU on which it operates.
like what?
>>83823259
>you throw away relevant information
It's your claim, argument your position instead of simply repeating it.
>>
>>83823290
Both programs produce the same output. You're confusing the output of a compiler with the output of a program compiled with it.
>>
>>83823298
>no it isn't
The proof of the pudding is in the eating. Shit slow software, high memory usage and long compilation times.
>yes they do, knowing whether it will produce the right answer determines whether it will be run at all
Doesn't matter if it runs when the purpose of it running in the first place has evaporated.
>It's your claim, argument your position instead of simply repeating it.
Why do I need to? Look at that 4 liner and tell me about how it impacts the stack, what registers it will load, its iteration behavior, its cache behavior (does it miss?) branch predictions. Convert it into assembly code by hand. You'll have an easier time with the latter program than the former.
>>
>>83823310
>Both programs produce the same output.
And they both take different routes to get to the same output... except in the first you don't easily know how it got there and the second you can at least reason about that. The map is not the territory.



Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.