/dpt/ - Daily Programming Thread

What are you working on, Sup Forums?


Previous Thread:

Other urls found in this thread:

gitlab.com/abonnet/pasclang
godbolt.org/g/76W1jF
stackoverflow.com/questions/39725190/monad-interface-in-c
pastebin.com/raw/L6uKdVfE
en.wikipedia.org/wiki/Autism
twitter.com/AnonBabble

>What are you working on, Sup Forums?
Distributed NVME disk driver (not NVMEoF, but something different).

I am a salesman. I sell promises. I make the engineers make those promises a dream. They are sometimes forced to work long hours because of this. I don't really care though, because I make a lot more money than they do!

>templates
Please use a proper language with parametric polymorphism and type inference like an ML or Scheme instead of whatever bullshitte this is, thanks!

Note I said dream, not reality, because the projects never get done in time. They are inevitably shelved, and the engineers' time and effort are permanently wasted.

If your company fail to deliver, then how can they still afford to be in business?

I don't really care, because I make a lot of money! I'll just retire early when the company goes under, but the engineers will have to slave away trying to find another job.

>he has no options or stock in his own company
Sounds like they're cheating you out of a lot of money, desu senpai. You could have earned more + had incentives for making the business do well.

More testing, I'll move on to floating point numbers today I think.

Your own language?

I am a salesman. There is a graph consisting of N villages, I need to take the most efficient path in order to trade with all the villages and then return to the place I started from.

That's a compiler for a rather bare-bone version of Pascal.

I will delegate this task to my team of 50 trained indians. I can offer the solution to this problem for a paltry sum of 2000 dollars.

Still cool though. Do you have a github?

You are in massive denial right now, it's funny.
The damage control is amazing. C fags will do anything to defend their pride, won't they?

You don't understand compilers at all, you don't understand how they optimize.
Compilers are not magic, a lot of C programmers believe that they are.
There are some situations where the compiler simply can't optimize, let me tell you why:

qsort is an external function, the compiler doesn't have access to the source code, it's in glibc as compiled object code. Therefore the compiler simply cannot inline the function pointer call and optimize away the indirections, it's simply impossible.

std::sort on the other hand is a template function, that means the source code is available in a header, for the compiler to see. That means the compiler is able to optimize std::sort to the specific use case (this is one of the strengths of templates) to inline the lambda and optimize away the indirections.

>carposter.
What?

>dollars
Never heard of this coin, I am willing to offer 50 Trenni silver coins however.

Please don't bring your autistic fight here. Keep it in the other thread.

What the hell, no point keeping it private I guess.
gitlab.com/abonnet/pasclang

it's C++ you dingus

What is wrong with modern C++?

Nothing. It's only getting better.
Ctards are just salty.

Autism doesn't actually exist. It is the result of outside observations by xenophobic scientists who do not understand "autistic" behavior.

>I know nothing about type theory AND compilers
--You

>qsort is an external function
>the compiler doesn't have access to the source code
Not necessarily.

>Therefore the compiler simply cannot inline the function pointer call and optimize away the indirections
Nothing stops a well-made implementation from doing so.

>std::sort on the other hand is a template function, that means the source code is available in a header
As you can see again, the problem lies in the design of the specific implementation, not in the language.

Thanks

>t. autist

>Nothing stops a well-made implementation from doing so.
Except for the source code not being available, of course.

qsort is defines as a function taking a pointer to a function, there's nothing a compiler can do about it.

In a well made implementation the source would be available.

When will C++ get multiple dispatch?

>qsort is defines as a function taking a pointer to a function
Yes and? All of us know that.

>there's nothing a compiler can do about it.
How so?

>he doesn't know about function overloading
It already has it, m8.

It already has functors you can implement it with, so it's not going to be added any time soon.

If I wanted to study C++ in depth, should I use the newest standard?

It's called function overloading.

That's not C++

"""modern""" C++

You should use the newest standard in everything you use, idiot.

C++ has templates.

C++ templates are the shittiest templates in the history of mankind. It's embarrassing.

>If I wanted to study C++ in depth, should I use the newest standard?
Yes, although you could also get away by learning C++11 or 14 at first, and then just look at the C++17 features afterwards. Stay clear of C++98 and 03 though, a bunch of newer features deprecate some C++98 stuff and idiomatic 98/03 code is considered harmfull in 17 now that proper move semantics have been introduced.

This is incorrect. A new standard with no implementation is useless. The term "idiot" is meaningless, as intelligence is a subjective measurement of cognitive ability.

>How so?
Because there's no source code available for it. But go ahead, show us a C compiler inlining qsort call in godbolt, because it doesn't: godbolt.org/g/76W1jF .

>C++ has templates.
And? Still not C++.

>C++
Have they added Monads yet? Personally I think they are missing out on the Monad market and I know 100s of people who would use C++ if it only had Monads.

See The standard says nothing about implementations of the language being forced to be separated between the language and the library and these two parts not having access to the source of each other.

>monad market
kek

stackoverflow.com/questions/39725190/monad-interface-in-c

>A new standard with no implementation is useless
Good thing both GCC and LLVM have an implementation of C++17, so go use it.

Illiterate retard. Read the original post >whatever bullshitte this is
It's C++.

>Monad market
An entire 2 people?

So show me, we have all the major C compilers in godbolt, show me any of them inlining qsort.

wow that is horrific

>(You)
>Illiterate retard. Read the original post (You)
I did, I wrote that post after all.

>It's C++.
No, it is not. I am pretty sure that it's D or something shitty like that.

How is that relevant to the discussion? We were talking about languages, not implementations.
I am not aware of any, but even if I was I am unsure how it would be relevant.

What did you expect? Only Haskell users would be so autistic that they'd expect something that complex and poorly optimised being executed by computers to be a built-in to the language.

Oh, you're referring to the OP image.
I thought you were making a general jab at templates and C++.

A U T I S M

I know this is a meme post, but std::optional is a thing now and you can implement something similar to rust's unwrap macros in C++
pastebin.com/raw/L6uKdVfE

>std::optional
That's more similar to a maybe than a generic monad, though.

>Oh, you're referring to the OP image.
Of course! This is why I quoted her in my post.

>I thought you were making a general jab at templates and C++.
It can apply to any language that has templates actually.

So after 40 years of C compiler optimizations no compiler do this hypothetical optimization you're talking about, but it's ok because it's theoretically possible so it's as good as std::sort optimization every C++ compiler does for 20 years now.

Wrong thread.

>her
Did you just assume OPs gender?

See

>So after 40 years of C compiler optimizations no compiler do this hypothetical optimization you're talking about
Nobody said that. All I said is that I am not aware of many compilers than can. That being said, I am not aware of many optimising C compilers and neither are you.

>but it's ok because it's theoretically possible
Yes, it is theoretically and trivially possible.

You can't inline qsort's comparator, simply because the compiler has no way of knowing it's source. It may be a function in the same file, it may be a different file. Your code might be dynamically linked as a library, and the function pointer is passed from way outside your code etc.

>simply because the compiler has no way of knowing it's source. It may be a function in the same file, it may be a different file. Your code might be dynamically linked as a library
In the first two cases the compiler has a way of knowing it's source.

>autism doesn't actually exist
Thanks for the input, Fox News.

en.wikipedia.org/wiki/Autism

Who decides this? That's right, outside observers who are afraid of people who are different.

>In the first two cases the compiler has a way of knowing it's source.
Not the way a compiler is supposed to be implemented. The function isn't known until the linker stage, which is too late. Also, the comparator might be determined in runtime, which complicates things.

Well, plenty of autistic people take pride in calling themselves autistic though.

>Not the way a compiler is supposed to be implemented
There isn't a standard way that a compiler is supposed to be implemented. Also, both gcc and clang support LTO anyway.

not?
void print_sum(T: add + show)(T x, T y)

And homosexuals take pride in being homosexual.

> hat being said, I am not aware of many optimising C compilers and neither are you.
You can test it on godbolt, it has gcc, clang, msvc and icc. Neither of these compilers do it, I wonder why, if it's so trivial and so beneficial.
>BBBBUT IT'S POSSIBLE
Rrrright, maybe in C41. Meanwhile, std::sort inlining just works.

Honestly, I have no idea why are you even arguing, is it so hard for you to accept idiomatic C++ can be faster than idiomatic C? It's like you're ignoring all the evidence just because they don't reinforce your beliefs.

>There isn't a standard way that a compiler is supposed to be implemented
Uhm, yes there is. The C standard, specifying how preprocessor directives etc should work, limits how a compiler can ble implemented.

>Also, both gcc and clang support LTO anyway.
That's irrelevant to function pointers.

Look, I can fucking construct the function I pass in as the comparator in fucking runtime, by calling mmap() and filling the section with opcodes manually. Or I can call dlopen on some other object file (also determined in runtime) and load the function I want to use for this. There's no way a compiler or linker would be able to optimise this.

>Not just writing your own sorting algorithm

Use merge sort for everything.

>maybe in C41
Wrong, it is already possible, we do not need a new standard in order to make it possible.

>is it so hard for you to accept idiomatic C++ can be faster than idiomatic C?
It can if you use an implementation that does not optimise C as well as the C++ parts of C++, I am not denying that.

So I tried using my compiler on FreeBSD. It builds fine but then segfaults at runtime, apparently because of static initialized objects. Does anyone with experience with the standard library used in FreeBSD have a fix?

>They just don't optimize C enough!
Wew, lad.

>Uhm, yes there is. The C standard, specifying how preprocessor directives etc should work, limits how a compiler can ble implemented.
I am aware of the standard and it does not force any kind of limit to the compiler as long as the behaviour is the expected one. If you believe that the C standard limits what an implementation can do related to the optimisation that we talked about please do post that part.

>I can fucking construct the function I pass in as the comparator in fucking runtime, by calling mmap() and filling the section with opcodes manually
Not standard C and actually it's technically UB. Even then however the C compiler will be able to deduce which calls to qsort use an existing function.

>There's no way a compiler or linker would be able to optimise this.
There might be if it does some weird-ass jit magic or whatever, even then, I am not arguing for this specific case but for the case where the callback is known.

>Quick sort
Let's see
import std.algorithm: filter;
import std.array: array;

int[] qs(int[] arr) {
if(!arr.length) return [];
if(arr.length == 1) return arr;
return qs(arr.filter!(a => a < arr[0]).array) ~ arr[0] ~ qs(arr[1..$].filter!(a => a >= arr[0]).array);
}

heap/smoothsort for everything.

>not in-place
What a meme language.

>when you realise that the actual reason that qsort is slower than std::sort is due to the different algorithms that they use.

does anyone actually use D

>ignoring all the evidence about inlining you can check for yourself on godbolt
>inventing false reasons just to keep your incorrect opinion intact
C-tards are in denial again.

>return qs(arr.filter!(a => a < arr[0]).array) ~ arr[0] ~ qs(arr[1..$].filter!(a => a >= arr[0]).array);
I don't understand anything

>ignoring all the evidence about inlining you can check for yourself on godbolt
I can't, why are you lying?

>it does not force any kind of limit to the compiler as long as the behaviour is the expected one
That's true, but the expected behaviour limits the compiler.

For example, calling a function within a compilation unit requires only that the compiler knows the declaration, meaning that any code optimisation has to wait until the linking stage.

Even then, the definition might not be known (because it might as well be dynamically linked in at runtime). This limits how calls to the external function can be optimised.

>Even then however the C compiler will be able to deduce which calls to qsort use an existing function.
#include
#include
int compar0(const void* a, const void* b)
{
return -1;
}

int compar1(const void* a, const void* b)
{
return 1;
}

int main()
{
int* data = malloc(sizeof(int) * 300);
srand(time(NULL));
for (int i = 0; i < 300; ++i) data[i] = rand();

int (*compar[2])(const void*, const void*) = { compar0, compar1 };

qsort(data, 300, sizeof(int), compar[rand() % 2]);
}

~ probably concats
arr[1..$].filter probably applies filter to all elements of arr after the first.

Andrei has recently hired a couple of Romanian students to shill for D on Sup Forums. You can see they post only trivial, self-contained code snippets 10 lines long or less and never any part of a larger project. Obviously, because they have none. It looks like they're using some kind of bot that monitors /dpt/ so they start shilling after someone post something positive about Rust, Go or C++, since these are the languages Andrei is rightfully afraid of.
Other than that, I don't think anyone uses D.

D is not for brainlets, user

The C standard does not force a linking stage that's applied after the compiler passes trough each file separately.

>qsort(data, 300, sizeof(int), compar[rand() % 2]);
It's clear here that you put a dependency on rand(), which in turn has a dependency on an internal state thing which in turn changes with srand and which in turn uses time (whose output depends on the runtime). A proper compiler might be able to deduce that.
Or it could optimise it for both instances and call the correct one during the runtime.

Why romanian?

A simple TCP server written in Rust
use std::env;
use std::process;
use std::net::TcpListener;
use std::error::Error;

fn main() {
let args: Vec = env::args().collect();
let mut addr = String::new();
let mut ip = "127.0.0.1";
let mut port = "8001";

if args.len() == 1 {
} else if args.len() == 2 {
ip = &args[1];
} else {
ip = &args[1];
port = &args[2];
}

addr.push_str(ip);
addr.push_str(":");
addr.push_str(port);

let listener: TcpListener;
match TcpListener::bind(addr) {
Ok(l) => {
listener = l;
println!("Bind {}:{} successfully.", ip, port);
},
Err(e) => {
println!("Bind {}:{} error: {}.", ip, port, e.description());
process::exit(1);
}
}

for stream in listener.incoming() {
match stream {
Ok(stream) => {
let peer = stream.peer_addr();
match peer {
Ok(p) => {
println!("Client address: {}:{}.", p.ip(), p.port());
},
Err(e) => {
println!("Connection error: {}.", e.description());
}
}
}
Err(e) => {
println!("Connection error: {}.", e.description());
}
}
}
}

Because D is a Romanian programming language.

does anyone actually use Rust

do you actually do any programming

Cancer

Do all the widget toolkits suck? Recommend me a modern C++14+ GUI library.

?

Iirc qsort and std::sort don't have the same requirements.
qsort is a stable sort. If you want that in C++ you use std::stable_sort.
So comparing them as if they're he same is foolish. Of course a more constrained sort will (potentially) be slower.

The arguments about expressiveness is just silly. Clearly doesn't apply here. Just look at the implementations.

Dear Imgui

I lolled