/dpt/ - Daily Programming Thread

Old thread: What are you working on, Sup Forums?

Other urls found in this thread:

github.com/lattera/glibc/blob/master/string/strlen.c
twitter.com/NSFWRedditVideo

Friendly reminder that C is weakly typed and Cniles will defend this.

Second for C#

Cawfee

Lets all be friends!

gween tee!
say it again mong

Fizzbuzz and Pointers

>weakly typed
Like how?

Learning Rust senpai

A game in Haskell
Not even using FRP

trying to learn tcp sockets in boost::asio

Say one more thing and both of you get viciously raped till you vaginas are leaking pus.

CAWFEE!

Like any pointer can be cast to a void* and then recast as something else, my dude.

void foo(void* a)
{
int* ptr = a;
*ptr = 0xdeadbeef;
}

void bar()
{
char a = 'a';
foo(&a);
}

>weak static typing
The worst of both worlds.

There's no better red flag when talking to "developers" than when they start shitting on C and calling it unethical or "scary" because they have to use RAW pointers!!!

Don't start this again. look at last thread if you're curious.

...

Raw pointers are a thing of the past. Dump C poster

Writing in C is unethical.

Last thread didn't contain any arguments as to why weak typing was good though. Only some retard going on about how void* makes sense because of how typing in C works.

You know what time it is

Get your head out of your ass smug hasklel weenie.
There is memory and the values stored to that memory. You manage that. Forget your recursive types where everything is initialized, that's not how computers work.
You would make bad embedded developer or Digital circuit designer.

Last thread contained enough butthurt about the subject. I think it's wise to avoid it for now for the sake of the thread.

Static typing is okay. It's tedious when virtually all modern languages support type inference, but it's okay. The problem with static weak typing though, is that you might be led to believe that since it is statically typed it is also strongly typed. Which it obviously isn't, as const casts and type casts doesn't mean shit to C.

That anime is highly autistic

Static typing doesn't mean you can't have type inference, user.

You're free to avoid void pointers if you want, they make perfect sense for things like malloc. Even if you'd take them out, you could still cast manually. What's the problem here?

new > malloc without constructors

>There is memory and the values stored to that memory. You manage that
The problem is that different types occupy different length in memory, like shown in my example. Dereferencing a char pointer only loads one byte, whereas dereferencing an int pointer loads four bytes from memory.

>You would make bad embedded developer
I actually work with C for a living and my current project is a distributed NVMe driver.

C++ manages to use the same typing system and still be type-safe. C does not.

>Digital circuit designer.
These make the absolute worst C programmers though. Ask anyone working with embedded software.

I know, my point was that C doesn't.

>Even if you'd take them out, you could still cast manually. What's the problem here?
Invalid casts = compiler error

This.

Time for cawfee.

Those were caused by incompetent companies. I doubt the ones listed there were using the tools that ha mentioned. gcc-hardened-wrapper mitigates buffer overflows entirely, which is what his problem was. Goto fail had nothing to do with C.

>The problem is that different types occupy different length in memory, like shown in my example. Dereferencing a char pointer only loads one byte, whereas dereferencing an int pointer loads four bytes from memory.
That's not problem you fucking retarded millenial faggot.

>C is a portable assembly meme

I could still cast to a sufficiently large int and then back to pointer.

>That's not problem
That obviously is a problem.

>what are buffer overflows
>what is pointer aliasing

C is a godawful language, and should only be used where it is absolutely necessary, no more.

>>what are buffer overflows
>>what is pointer aliasing
You check for those if you know there's possibility for those.
You can always make functions to provide more abstraction and do those checks for you.
You can stop dumb any time now.

>lol just do it yourself

You can obviously implement a Python runtime and just write Python code and embed everything into a binary too, but that's massively impractical.

How does "just add more abstractions" become a defence for lacking basic type checking?

This oWo, C is for cute
char* stringCopy(const char *from)
{
char *to = malloc(sizeof(from));

for (int i = 0; from[i] != '\0'; i++)
to[i] = from[i];

return to;
}

>char *to = malloc(sizeof(from));
That doesn't work the way you think it works.

sizeof(from) will return 4 or 8 on x86, but you could obviously have strings of other sizes.

Threadly reminder that no one is defending it anyway, and that you're an autist who fails at basic reading comprehension.

>Threadly reminder that no one is defending it
See the old thread.

REEEEEEEEEEEEEE
I should have know that, because from is just a pointer to the first char of the string.

>defending C by posting incorrect C code

char* stringCopy(const char *from)
{
int bytes = strlen(from) + 1;
char *to = malloc(bytes);
memcpy(to, from, bytes);
return to;
}

>See the old thread.
I saw it, and nobody was defending weak typing. You're an autist that fails at reading comprehension.

>you can have a language providing both control and safety

std::string from = "aaa";
std::string to = from;
Wow reinventing the wheel in C sure is fun compared to this

>make a function called stringCopy
>if string to be copied is larger than 8 bytes, start writing into random memory

>malloc returns NULL and your program segfaults

Why does Sup Forums act so all uptight about this language, none of you are able to write correct code in it.

fn main() {
for ((a, b), c) in (0..6).zip(0..11).zip(0..21) {
if a * 5 + b * 10 + c * 20 == 100 {
println!("{} x 5c + {} x 10c + {} x 20c = $1", a, b, c);
}
}
}

Then why the fuck do most bigger sepples projects reimplement strings and basic data structures themselves?

What's it like being 100% driven by your emotions?
It sounds like hell.

They don't. If they do, that's a huge red flag to stay the fuck away.

Only literal retards think that the standard library can't be """trusted"""

i think he wants cartesian product, i.e.
for a in (0..6)
for b in (0..11)

Better efficiency for their specific use case. That is the reason why you would use C++ in general.

This

>Better efficiency for their specific use case
Stop. See

A solver for Lagrangian particle tracking where the particles have some connecting forces holding them together. Working with OpenFOAM.

>Only literal retards think that the standard library can't be """trusted"""
t. retard
It's not about trust, it's about the standard library being designed for working in the most general case which means taking into consideration some cases that will never show up for you while impacting performance/usability/compatibility/etc. Using the standard library will work but is not optimal.

the itertools defines a cartesian product iteraror in this case:
extern crate itertools;

use itertools::Itertools;

fn main() {
for ((a, b), c) in (0..6).cartesian_product(0..11).cartesian_product(0..21) {
if a * 5 + b * 10 + c * 20 == 100 {
println!("{} x 5c + {} x 10c + {} x 20c = $1", a, b, c);
}
}
}

The standard library, both for C and C++ will exploit literally ever trick in the book.

Case in point: github.com/lattera/glibc/blob/master/string/strlen.c

Prove me wrong by implementing a more efficient vector class than std::vector .

Neat. Anything pretty to look at?

Different user, but you are cherrypicking. If you want a counter-example, see std::map, for which it's rather easy to implement a more performant replacement.

Fallacies: the post
>will exploit literally ever trick in the book
Not every trick is known, and not every trick is known to implementers. And no, it doesn't.
>implementing a more efficient vector class than std::vector
Most game engines do that.

>Not every trick is known
Are you saying that CPUs don't have specifications? That's news to me.

>Most game engines do that.
Post an example then.

>more efficient vector class than std::vector
>more efficient vector class than the vector class that pretty much never frees memory
Stop posting.

...

I suspect that you're forgetting that std::map has ordering requirements.

in haskell this is just

import Text.Printf (printf)

solts = [ (a,b,c) | a

>I can do better than C++ standard library
Prove it.

std::unordered_map does not, but is still garbage

What does /dpt/ think of this? It's not really fleshed out yet but you get the gist of what it'll be like when it's finished.

unordered_map is implemented as a hashtable, that's literally the most efficient way to do it.

>the most efficient way to do it
Prove it.

I'm not a checkers fan, but in chess it's nice to have a history of moves played by you and the opponent.

Nothing really visual about it so far. Trying to get orientation distributions of the connected particles at certain points so have only been working on implementing the numerics. My code is godawful at this point though

O(1) insertion
O(1) deletion
O(1) look up

I woud like some ______

In case anyone still had any doubt.

should I take as3 job my lads

You clearly have no idea what you're talking about. There are many different ways you could implement a O(1) hashmap, and the C++ standard library one is not even close to a silver bullet for every usage case.

Yet you chose to provide no examples at all, only to reiterate the original claim that the implementation is suboptimal for some cases.

>THE C++ standard library

>when all else fails, memes away

>provided no argument other than "you disprove my claim that the C++ standard is optimal"
That's not how it works, friendo.

Does anyone know how I can get the timing on this right? I can't seem to find the sweet spot between waaay too slow or too fast.
Yeah I as well never really played checkers. My first idea was chess but I wanted to do this first just because checkers is a lot simpler. I used C, but for Chess I think I might use Java. I can see Chess being a lot more complicated.

standard library*

I implemented parts of STL library at least 3 times, a lot of companies strictly forbid any use of stl or boost

Uh, that's exactly how it works. I can't prove that there aren't any situations where the C++ standard library is suboptimal, that would be the equivalent of proving that unicorns doesn't exist.

You, on the other hand, claiming that there ARE cases where the C++ standard library is suboptimal, can easily prove that point by providing an example of such case. Much like you proving that unicorns do exist by showing me a fucking unicorn.

>what is strdup

>I implemented parts of STL library at least 3 times,
Show that it is more efficient.

>a lot of companies strictly forbid any use of stl or boost
And this is a huge red flag.

>Yet you chose to provide no examples at all,
Since you're the one making unsubstantiated claims based on ignorance, why don't you just google it when corrected by people who know better, for your own education?
E.g.:
tessil.github.io/2016/08/29/benchmark-hopscotch-map.html

You're fucking retarded.

That's pretty easy since std::vector uses the heap and the standard custom allocator API is complete garbage.

Not an argument.

>Yeah I as well never really played checkers. My first idea was chess but I wanted to do this first just because checkers is a lot simpler. I used C, but for Chess I think I might use Java. I can see Chess being a lot more complicated.
I wouldn't say chess is more difficult. Chess simply has more rules. Board games in general are relatively easy to implement. It gets interesting once you start writing AI.

Pretty cool.

It's the truth as proven by your own posts. Read all the other posts you ignored as for the arguments about the argued fact.

I didn't ignore any posts.

Oh, so it simply is that you are unable to read then.