/dpt/ - Daily Programming Thread

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

>>61040119
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!

File: 1491698549469.jpg (194KB, 1280x738px) Image search: [Google]

194KB, 1280x738px

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

>>61040147
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.

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

>>61040167
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.

>>61040177
>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.

File: Screenshot from 2017-06-23 12-06-02.png (103KB, 3600x1080px) Image search: [Google]

103KB, 3600x1080px

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

>>61040192
Your own language?

File: 1481658937518.jpg (37KB, 474x400px) Image search: [Google]

37KB, 474x400px

>>61040147
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.

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

>>61040204
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.

>>61040223
Still cool though. Do you have a github?

>>61040182
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?

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

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

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

>>61040148
it's C++ you dingus

>>61040119
What is wrong with modern C++?

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

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

>>61040233
>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.

>>61040247
Thanks

>>61040279
>t. autist

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

File: qosrt.png (38KB, 559x342px) Image search: [Google]

38KB, 559x342px

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

>>61040297
In a well made implementation the source would be available.

>>61040258
When will C++ get multiple dispatch?

>>61040307
>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?

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

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

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

>>61040315
It's called function overloading.

>>61040248
That's not C++

>>61040254
"""modern""" C++

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

>>61040356
C++ has templates.

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

>>61040347
>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.

>>61040359
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.

>>61040320
>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: https://godbolt.org/g/76W1jF .

>>61040359
>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.

>>61040369
See >>61040310
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.

>>61040378
>monad market
kek

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

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

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

>>61040378
>Monad market
An entire 2 people?

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

>>61040391
wow that is horrific

>>61040393
>>>61040370(You)
>Illiterate retard. Read the original post >>61040148(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.

>>61040398
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.

>>61040407
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.

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

>>61040421
>>61040398
>>61040386
>>61040369
>>61040310
>>61040297
>>61040320
>>61040307
>>61040282
>>61040233
A U T I S M

>>61040378
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++
https://pastebin.com/raw/L6uKdVfE

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

>>61040431
>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.

>>61040421
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.

>>61040442
Wrong thread.

>>61040452
>her
Did you just assume OPs gender?

>>61040442
See >>61040279

>>61040463
>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.

>>61040463
>>61040421
>>61040398
>>61040386
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.

>>61040490
>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.

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

https://en.wikipedia.org/wiki/Autism

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

>>61040499
>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.

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

>>61040510
>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.

>>61040119
not?

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

>>61040516
And homosexuals take pride in being homosexual.

>>61040482
> 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.

>>61040528
>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

>>61040550
Use merge sort for everything.

>>61040546
>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?

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

>>61040548
>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.

File: 1470882916016.jpg (44KB, 703x692px) Image search: [Google]

44KB, 703x692px

>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);
}

>>61040552
heap/smoothsort for everything.

>>61040592
>not in-place
What a meme language.

File: 1488018932678.png (481KB, 611x508px) Image search: [Google]

481KB, 611x508px

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

>>61040592
does anyone actually use D

>>61040610
>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.

File: 17796448.jpg (24KB, 460x458px) Image search: [Google]

24KB, 460x458px

>>61040592
>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

File: 1468927467686.png (29KB, 1920x1021px) Image search: [Google]

29KB, 1920x1021px

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

>>61040586
>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 <stdlib.h>
#include <time.h>
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]);
}

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

>>61040622
Andrei has recently hired a couple of Romanian students to shill for D on /g/. 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.

File: 1477286674675.png (463KB, 743x720px) Image search: [Google]

463KB, 743x720px

>>61040647
D is not for brainlets, anon

>>61040658
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.

>>61040675
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<String> = 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());
            }
        }
    }
}

>>61040704
Because D is a Romanian programming language.

>>61040712
does anyone actually use Rust

>>61040723
do you actually do any programming

>>61040712
Cancer

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

>>61040739
?

>>61040121
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.

>>61040745
Dear Imgui

>>61040204
I lolled

>>61040756
>I'm going to ignore inlining, the main reason why std::sort is faster than qsort, and focus on some secondary stuff
IN DENIAL

>>61040745
QT

>>61040772
>inlining
Show me the asm then.

File: 1489884202714.jpg (79KB, 1280x720px) Image search: [Google]

79KB, 1280x720px

>>61040772
>complexity of the algorithm
>secondary stuff

>>61040697
>The C standard does not force a linking stage that's applied after the compiler passes trough each file separately.
The point is that each file is considered a compilation unit, the whole concept of making a pass of each file separately is a limitation that is imposed on C compilers due to how C is specified.

A language that didn't allow external function definitions, for example, would be able to optimise more aggressively. A language that didn't allow C-style function pointers, might optimise even more aggressively.

Anyway, this is a separate debate. My main point here is that making multiple passes on separate compilation units is the result of an archaic design where memory and storage was limited resources.

>Or it could optimise it for both instances and call the correct one during the runtime.
In this case it could, but what if I did something like this instead:

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


typedef int (*fp_t)(const void*, const void*);

fp_t get_func(const char* filename, const char* funcname)
{
    void* handle = dlopen(filename, RTLD_LAZY);
    fp_t func = (fp_t) dlsym(handle, funcname); // compiler might complain here, don't remember exactly the semantics here
    return func;
}

int main()
{
    int* data = malloc(sizeof(int) * 300);
    for (int i = 0; i < 300; ++i) data[i] = rand();
    fp_t compar = get_func(argv[0], argv[1]);

    qsort(data, 300, sizeof(int), compar);
}

>>61040792
>std::sort and qsort has different complexity
Does the C standard require qsort to be implemented as bubble sort or what?

>>61040793
>what is link time optimization
I agree that the C standard is dumb but C++ inherits that stuff.

>>61040772
>inlining, the main reason why std::sort is faster than qsor
This is not the reason, you are pants on head retarded.

qsort uses quick sort. GCC's implementation of std::sort uses introsort.

https://en.wikipedia.org/wiki/Introsort#Analysis

>>61040793
>the whole concept of making a pass of each file separately is a limitation that is imposed on C compilers
By you maybe, not by the standard however. If you disagree please quote the part of the standard that limits the compilers concerning that.

>In this case it could, but what if I did something like this instead:
We talked about this before.

>>61040808
>I agree that the C standard is dumb but C++ inherits that stuff.
Link time optimisation is irrelevant to std::sort, templates are handled compile-time. There is no linking to std::sort, std::sort is simply inlined compile-time.

File: qsort_vs_stdsort.png (123KB, 1913x967px) Image search: [Google]

123KB, 1913x967px

>>61040785
https://godbolt.org/g/sjwD4T

>>61040810
>qsort uses quick sort
False, the C standard does not dictate the algorithm to be quick sort. If I am not mistaken glibc uses a weird monstrosity where it tries to use merge-sort, if it fails due to not enough memory it goes to quicksort and in some cases it falls back to a heap-sort-like-thing, I don't even remember but it was weird like that.

>>61040810
They have the same complexity, the difference is not as significant as inlining the comparison function and the sorting function itself, see >>61040825 .

>>61040712
>TcpListener
>stream

>>61040842
>They have the same complexity
They have the same O, this does not mean that they will perform the same however. A big coefficient will fuck shit up really bad.

File: 1323595549415.jpg (34KB, 250x333px) Image search: [Google]

34KB, 250x333px

Are you guys serious when you talk about learning obscure languages like Rust and Haskell?

I've never seen a job advertisement for any of these meme languages, all the $100k+ jobs are embedded devices with C or useful software with C++.

Is this some kind of psyop to get people to waste their time?

>>61040765
Imgui at first glance looks really good and it looks like it will place nice with other libraries like SFML and OpenGL, but some of the other libraries I looked it appeared good at first until I started to dig deeper and found out they suck.

>>61040778
Implying like I've been under a rock and never heard of this.

>>61040832
You can see how different it is on that musical sorting video on youtube. But yeah gcc's implementation is far from trivial.

>>61040814
>By you maybe, not by the standard however. If you disagree please quote the part of the standard that limits the compilers concerning that.
See 5.1.1.1, the standard clearly specifies what a translation unit is and what the sequence of translation phases should be.

5.2.4.1 specifies limits to a translation/compilation (although it suggests that limits should be avoided if possible).

Section 6.2.2 specifies how symbols should be linked, so it clearly specifies a linking stage.

http://www.open-std.org/JTC1/sc22/wg14/www/docs/n1256.pdf

>We talked about this before.
The point is that your theoretical compiler-linker-hybrid is going to have to be able to handle all sorts of weird edge-cases, as you keep insisting that it might do this or might do that for every example.

how do you even become a programmer?

shit is overwhelming

>>61040857
>hurrrr durrr learning languages is difficult
>hurrrr durrr the language is important when you get hired and you can't learn whatever they use at your job in 5 days
>hurrrr durrr I do not want to learn about modern type theory, monads and functional programming so I will avoid haskell

>Not only doesn't C allow inlining of the comparison function into qsort, it also uses inefficient algorithm, making it, even more, slower than std::sort
How is this an argument for C again?

>>61040842
Runtime- (or even space-) complexity is not all that matters. Shell sort has the same complexity for all gap sequences, but the choice of gap sequences is significant for the runtime performance.

Same for quicksort, how you choose the pivot element can influence the performance severly.

>>61040832
You are correct, I am mistaken. However, it attempts to determine the best algorithm in runtime, rather than std::sort which does this in compile-time.

>>61040897
>How is this an argument for C again?
It's not, compile-time metaprogramming (aka templates) is extremely effective, even though /g/ have autistic tendencies and sperg out over template syntax.

>>61040916
Template syntax is pretty ugly in C++ to be fair.

>>61040926
>programming languages can be "ugly"
Lmao you're not living with German guys

>>61040926
It is, but it's also understandable why it is so. Bjarne based his syntax on C in the first place, so he had to invent a syntax for templates that didn't collide with C syntax in any way. Also, the insane requirement that still haunts C++ today, namely that it should be compatible with C code, is imposing all sorts of limitation on C++.

>>61040119
wtf language is that shit? here's a superior (Java) version

    public class Example {
    
        private static final Logger logger = LogManager.getLogger("example");
    
        public <T extends Addable> void print_sums(T x, T y) {
            logger.info(x.add(y).toString());
        }
    }

>>61040957
>imposing all sorts of limitation on C++.
>he doesn't look forward to the day where emojis become part of programming language syntaxes

>>61040874
>5.1.1.1
It does not dictate that the compiler should process them separately, only that it can process them separately if this is desirable.

>5.2.4.1 specifies limits to a translation/compilation (although it suggests that limits should be avoided if possible).
I am aware of these limits, they are more like the minimum of what an implementation may support (and quite irrelevant to this discussion)

I still can't see how these stop what I am suggesting.

>>61040897
The C standard says nothing about the algorithm of qsort. (other than that it's stable)

>>61040946
German is pretty aesthetic desu. Prefer Dutch personally though.

>>61040957

What do you expect with 40+ years of legacy? Ideally C++ should have simply looked like C and been able to link against it, but here we are living with these mistakes.

>>61040981
godverdomme

>>61040969
>emojis
Thank God for C++17 finally eliminating trigraphs

 // Will the next line be executed????????????????/
 a++;

>>61040968

Java generics are shit in every way

>>61040926
Templates also use duck typing and are basically glorified macros. This is why I like Rust's generics and can't wait for them to support HKT and constants in traits.

>>61040981
>Ideally C++ should have simply looked like C and been able to link against it, but here we are living with these mistakes.
I agree. D did the right thing here (but they fucked up on other things, sadly).

>>61040991

a //* nigs */ b
c

>>61041011
I mean

a //* nigs */ b
- c

>>61040976
>I still can't see how these stop what I am suggesting.
See >>61040874

>The point is that your theoretical compiler-linker-hybrid is going to have to be able to handle all sorts of weird edge-cases, as you keep insisting that it might do this or might do that for every example.

It is simply not practical to handle every sort of edge case in a special way. You'd end up with a compiler that requires 32 GB of memory and 128 CPUs to compile a Hello, world program.

>>61040999
>hurr i'm too stupid to use a real programming language

>>61041047

Java is made for moronic pajeets.

at work how often does your code get reviewed by others?

does anyone care as long as it's working?

File: result.png (2KB, 306x53px) Image search: [Google]

2KB, 306x53px

>>61040825
Run this:

#include <stdlib.h>
#include <stdio.h>
#include <algorithm>
#include <intrin.h>
// Type your code here, or load an example.
int cmp(const void* a, const void* b) {
    return *(const int*)a < *(const int*)b;
}

int qsort_test(int* v, size_t s) {
    qsort(v, s, sizeof(s), cmp);
    return 0;
}

int std_sort_test(int* v, size_t s) {
    std::sort(v, v+s, [](int a, int b) { return a < b; });
    return 0;
}

int main (){
#define ARRAYSIZE 1000000
 unsigned int dummy;
 int* arr=new int[ARRAYSIZE];
    for(int i = 0; i<ARRAYSIZE;i++ )
        arr[i]=rand();
    unsigned long long sortStart=__rdtscp(&dummy);
    std_sort_test(arr,ARRAYSIZE);
    unsigned long long sortEnd=__rdtscp(&dummy);
    for(int i = 0; i<ARRAYSIZE;i++ )
        arr[i]=rand();
    unsigned long long qsortStart=__rdtscp(&dummy);
    qsort_test(arr, ARRAYSIZE);
    unsigned long long qsortEnd=__rdtscp(&dummy);


    printf("QsortTicks=\t%llu\nsortTicks=\t%llu",qsortEnd-qsortStart,sortEnd-sortStart);
}

I'm not saying the difference should be this large. I don't know why it is in my case. So I'd be happy if someone showed me why.

>>61041072
Depends on team size.
Code review happens a lot at big companies because they can afford the overhead (it pays off).
Smaller development teams don't have as much code review as people discovering glaring flaws in your code months later and are mad at you (or they're being adult about it and just point it out and ask you to fix it).

>>61041083
That's just the cost of zero cost abstractions anon. How silly of you to not know this..

>>61040119
I'm working on writing an OS with C++. So far have only achieved a "printf" and managed to integrate googletest into my toolchain (fighting C/C++ linker problems is how they torture you in hell)

>>61040119
Or, you know, just inline the print statement.

Or use void pointers :^)

File: qsort_vs_stdsort.png (28KB, 765x787px) Image search: [Google]

28KB, 765x787px

>>61041083
There's an error in the original code, it should be sieof(int), not sizeof(s). After I fixed that I've got std::sort running 2 times faster than qsort.

>>61041218
Why would that matter though? Why would Qsort run faster when comparing the wrong size?

>>61041233
It actually didn't run at all on my machine, it segfaulted. I guess it has something to do with your platform.

>>61041244
Weird. Have you tried running it a couple times? It'd be interesting to see the differences here.

File: qsort_vs_stdsort.png (13KB, 307x377px) Image search: [Google]

13KB, 307x377px

>>61041261

>>61041288
I meant the failing version since adress randomization and memory pages might have been an issue. But whatever.

how difficult is learning javascript after python?

>>61041343
Not difficult.

>>61041288
>weird miscoloring by the colons
What's going on here?

>>61041083
>return *(const int*)a < *(const int*)b;
That's not how you implement a comparison function, you fucking idiot.

>>61041465
Enlighten us, how do you implement a comparison function for qsort?

>>61041479
>return *(const int*)a - *(const int*)b;

>>61041479

       The comparison function must return an integer less than, equal to, or greater than zero if the first argument is considered to be  respec‐
       tively less than, equal to, or greater than the second.  If two members compare as equal, their order in the sorted array is undefined.

>>61041479
It's supposed to return <0 for less than, 0 for equals, and >0 for greater than.
What you have there is just plain wrong.

int cmp(const void *arg1, const void *arg2)
{
    const int *a = arg1, *b = arg2;
    if (*a < *b)
        return -1
    if (*a > *b)
        return 1;
    return 0;
}

If you're not worried about overflow/underflow, you can also do it more succinctly like:

int cmp(const void *arg1, const void *arg2)
{
    const int *a = arg1, *b = arg2;
    return *a - *b;
}

>>61040148
Scheme has parametric polymorphism?

>>61040756
>qsort is a stable sort
false

File: qsort_vs_stdsort.png (38KB, 759x913px) Image search: [Google]

38KB, 759x913px

>>61041483
>>61041484
>>61041496
You're right, C still sucks tho.

>>61041560
do the - version

File: qsort_vs_stdsort.png (39KB, 793x831px) Image search: [Google]

39KB, 793x831px

>>61041564
Here, but it's already been demonstrated the problem is qsort's inability to inline and to be inlined, not some minor details.

what code snippet could you take back to the past with a time machine to make a ton of money?

is there even such a thing?

>>61040119
>templates
>generics
"ok"

File: 1490011419158.jpg (194KB, 2038x1505px) Image search: [Google]

194KB, 2038x1505px

>/dpt/ makes 2(TWO!) errors while trying to use qsort
>both of them are caused by C's idiosyncrasies
>compiler catches none of them
>C++ code is shorter, cleaner, type safe, free of bugs and 2(TWO!) times faster
You can't make this shit up.

>>61041677
Now put even more programming languages into this.

File: haskell.png (71KB, 900x655px) Image search: [Google]

71KB, 900x655px

>>61040592

>>61041677
>trying to use qsort
But the first error was with trying to use std::sort
The second error was a C++ programmer who assumed qsort was used exactly as std::sort.

>>61040592
Now profile it.

>>61041597
Could you compare stable_sort vs qsort now?
Why are we comparing two completely different functions for completely different purposes?

>>61041699
>using a function that is 2x faster
>an error
Only if you're a C-tard.

File: qsort_vs_stdsort.png (42KB, 557x357px) Image search: [Google]

42KB, 557x357px

>>61041714
>C-tards are desperate
>still incapable of understanding of the importance of templates and inlining for performance
qsort is explicitly defined as not stable, m8.

>>61041677
Now make it a mesh, like this:
D and Ada laughing at C++ for still being uncomfortable and insecure
C++ laughting at D and Ada for being DOA
Rust laughing at all three for being less secure where it matters
Jai laughing at all for caring about security and not having full compile time interpretation and an AST manipulation API

why cant senior developers fizzbuzz

>>61041748
*explicitly not defined as stable

>>61041677
>Rust
lol

>>61041722
Anon did you not follow the discussion?
He made an error that caused a segfault on his machine which ran 'fine' on another.

>>61041782
The first error was caused by taking sizeof of a wrong variable in the qsort call, it has nothing to do with std::sort, but everything with qsort being unintuitive to use.

Is qsort vs std::sort the new "average two ints" meme?

>>61041772
If an algorithm doesn't' guarantee stability it's not stable. qsort doesn't guarantee stability.

>>61040233
>what is __builtin_*
GCC doesn't do that as of right now, but it could. Whether or not the compiler knows the internal workings of libc doesn't matter; it can still replace internal functions with known optimized inlines.

>>61041677
This

Also, I lol'd at your image, although it should have included D.

>>61041832
The algorithm /could/ be stable and would still meet the qsort specification.

This is the third or fourth /dpt/ we discuss this meme, who is the fucking autistic C fag who can't face it when he's beat?

>>61041850
Yes, but qsort is still defined as not stable.
>>61041845
Yea, it should be Go < C < C++98 < D < C++17 < Rust.

>return to /dpt/
>still an argument about qsort
is this the only advantage C++ has over C or what?

File: 1495810988855.png (549KB, 1920x1080px) Image search: [Google]

549KB, 1920x1080px

rolling

>>61040857
>Rust
>obscure
>getting paid to write Rust right now

pls

>>61041866
Go < C < C++ < D < Rust < Go

>qsort vs std::sort
Great. Because people who wanted speed would use qsort and std::sort of course.

People forget how compilers aren't magic. If you use enough C++ features they will puke all over themselves.
https://youtu.be/rX0ItVEVjHc?t=2587
They even fail with basic things like this.
Can you imagine how quickly they will fail if you stack function call upon function call through using <algorithms> for instance?
You have to check every piece of code. It's not worth it.
Unless you really don't care about speed and in that case I recommend using just about any other language.
>>61041851
>this meme
Not really. Anon you're just slandering programmers for no reason. I doubt people are even C programmers in this thread. Nobody pointed out the error with Qsort.
Personally I'm a C++ programmer by profession.

>>61041866
No, explicitly qsort is not defined as stable.
It is not defined as not stable.

>>61041874
>design an esoteric language
>difficult
>window manager
>medium
>bootloader
>fuck you
this shits all backwards

>>61041871
No, it's just that the C++ hating C fag doesn't understand how their language works. Before you ask, yes I believe it's only one incredibly autistic guy who refuses to go to bed.

>>61041866
>Yes, but qsort is still defined as not stable.
Brainlet.

>>61041884
>Personally I'm a C++ programmer by profession.
I don't care. I used to program C++, now I'm (forced) to work with C. But I still find this "discussion" pointless, it's clear that most people here doesn't know how compiler optimisations work, nor how stable vs unstable sorting algorithms work, nor how templates (compile time) differs from run-time selection of the best algorithm.

It's either trolling or a meme at this point.

>>61041896
No, you are just retarded. You have been proven wrong multiple times.

I did literally nothing, fuck me

>>61041935
How have I been proven wrong? That post is literally my first post in this thread. I'm just observing the arguments ITT.

>>61041923
>nor how templates (compile time) differs from run-time selection of the best algorithm.
It's more a misunderstanding of the constraints C/C++ face with function pointers. The confusion was about inlining the function that was passed by reference, which you might say the compiler should obviously be a allowed to do when it's a static value like that.

I don't think anyone thought the template version would not inline.

>it's a meme or trolling
Yes.
>people don't know compiler optimizations
Yes. But I think this might educate some.

>>61041954
>should obviously
Sorry, poorly phrased. I mean that it might seem intuitive that it should be allowed to do that.

>>61041954
>The confusion was about inlining the function that was passed by reference
But a function passed by reference cannot be inlined, it's in every fucking documentation about function pointers everywhere.

>>61041887
>>61041898
I'm talking about qsort from the standard, not a concrete qsort implementation. If you can't rely on the algorithm being stable when you call it, it's not stable for you, regardless of how it's implemented. Not stable sorting algorithm can occasionally keep the elements in order, that doesn't mean "it's not defined as not stable".
In any case, there's no reason to compare qsort with std::stable_sort.

>>61041971
>its in every documentation everywhere
I know. But people don't know.
I'm just saying you put it as if people are confused about templates. But they're really confused about passing function pointers.

>>61041971
Sure it can if the implementation allows it.

>>61040233
Compiler-level optimization is for people who are too stupid to optimize code themselves.

>>61041986
I think you are confused, nobody is confused about passing function pointers.

>>61040530
Shitty code.
Why not make sum polymorphic, and then use print on the return of sum.
And who fucking prints sums.

>>61040254
It's tedious, bloated, and looks like shit.

>>61042011
>nobody is confused about passing function pointers.
See the posts this replies to:
>>61040490
Among others.

>>61041986
>I'm just saying you put it as if people are confused about templates. But they're really confused about passing function pointers.
Fair enough

>>61041998
>Sure it can if the implementation allows it.
No implementation does it, so what's the point in pretending that some magical implementation that does it, and somehow have found a solution to it, exist?

Is this some form of extreme autism or just old fashioned baiting?

>>61042025
I did.

>>61042037
Ok lets just disagree then.

>>61040592
>quicksort
for what purpose
just use the standard library sort

>>61042033
>No implementation does it
Irrelevant

>so what's the point in pretending that some magical implementation that does it
Nobody is pretending anything like that.

>>61042043
This is a homosexual way to end an argument.

File: inline.png (28KB, 1069x306px) Image search: [Google]

28KB, 1069x306px

>>61041971
>But a function passed by reference cannot be inlined
>>61041986
>I know. But people don't know.
>>61042033
>No implementation does it
Why do you keep talking about things you have no idea about? https://godbolt.org/g/iAyvtR

>>61042021
So, no technical arguments then.

>>61040658
I'm not the C tard, but even in that case, std::sort wouldn't be able to inline it.

>>61040279
Autism is just psychopathy minus charisma.

>>61040712
>string vectors
>unless they're string with the same lenghts , I don't see the point.
Lists make more sense if the strings are dynamically lenghted.

>>61042052
>This is a homosexual way to end an argument.
Anon we have disagreements in perception. It's useless to argue. If we can't agree on reality then what's the point in arguing about it?
I agree with you generally. Agreeing to disagree isn't productive for the subject.

>>61042052
>Nobody is pretending anything like that.
They are, read ITT.

>>61042060
>Why do you keep talking about things you have no idea about? https://godbolt.org/g/iAyvtR
You are retarded. Compilation units have already been mentioned ITT, about 50 posts up. I suggest you fucking read it, you mongoloid toilet scrubber.

>>61042060
Because they enjoy circlejerking.

>>61042060
So make qsort inline the cmp function? Any compiler. I'd be glad to see it.

>>61040712
>

let mut ip = "127.0.0.1";
let mut port = "8001";

>mut
The fuck is wrong with you?

>>61042088
>They are, read ITT.
Did so.

>>61042098
He's setting them as defaults and then setting them if passed as arguments.

He could be using clap and avoid all that shit tho.

>>61041519

(defun print-sum (x y)
  (println (+ x y))

>>61042088
>You are retarded. Compilation units have already been mentioned ITT, about 50 posts up. I suggest you fucking read it, you mongoloid toilet scrubber.
Irrelevant to what he posted, tard.

>>61042094
You can't because the compiler doesn't have access to qsort source code. Still, claiming "function pointers can't be inlined" is a retarded thing to claim. I bet it can even be inlined between compilation units with LTO enabled.

File: tenor.gif (189KB, 500x375px) Image search: [Google]

189KB, 500x375px

>>61040712
Is that what Rust looks like? I never even heard of it until yesterday's /g/ thread, but it's... beautiful. Where can I learn it?

>>61042063
>but even in that case, std::sort wouldn't be able to inline it.
That was my point

>>61042066
Psychopaths don't get startled, autists do: Look up "Emotion in the Criminal Psychopath: Startle Reflex Modulation" (4chan thought the link was spam)

Also, autists have troubles recognising faces and tend to have trouble with intimacy and maintaining eye contact. Psychopaths have none of these issues.

>>61042122
>Where can I learn it?
Rust Essentials

>>61042120
>the compiler doesn't have access to qsort source code.
Not that guy but.
wat
How does it use Qsort then?

>>61042114
>Irrelevant to what he posted, tard.
And what he responded to was irrelevant to my post, so fuck you.

>>61042101
Even the poster below me pretends so, so fuck you too.

>>61042129
also why would C/C++ have a function that doesn't allow itself to be optimized?
Seems counterproductive to the purpose of the languages.

>>61042061
Coding is more than just a means to an end. It's art.

>>61042112
*print

(print-sum #c(1 9) 3) => #c(4 9) ; complex number
(print-sum 1/4 2/3) => 11/12
(print-sum 0 1) => 1

>>61042129
It calls it, see >>61040825 . Moreover, libc implementations are separate from compilers, this is why you can use glibc, musl, newlib, bionc and others with both gcc and clang.

>>61042136
>And what he responded to was irrelevant to my post, so fuck you.
No it fucking wasn't you braindead asshole.

>Even the poster below me pretends so, so fuck you too.
You are not making any sense.

>>61042120
>Still, claiming "function pointers can't be inlined" is a retarded thing to claim
Remove static from your function declaration then. The compiler has no way of knowing if that function will be called from another compilation unit.

>I bet it can even be inlined between compilation units with LTO enabled.
It can't.

>>61042060
You are declaring it static because you are fucking mongoloid. Remove static from function declaration, and the compiler will have no way of knowing whether or not the function is called from another compilation unit.

>>61040119
>NOT USING OVERLOADING

void print_sum(int x, int y)
{
     printf("%i", x + y );
}

void print_sum(float x, float y)
{
     printf("%f", x + y );
}

void print_sum(int x, float y)
{
     printf("%f", x + y );
}

void print_sum(float x, int y)
{
     printf("%f", x + y );
}

Why not use overloading? Or is C language so lame that it doesn't have overloading?

>>61042150
So basically this is all arguments about a very specific environment circumstance?
How stupid.

>>61042150
>libc implementations are separate from compilers
Optionally

>>61042154
>No it fucking wasn't you braindead asshole.
Yes, it fucking is. You're demonstrating the Dunning-Kreuger effect.

>You are not making any sense.
I'm responding to two different posters, you fucking retard.

>>61042163
>You are declaring it static
...because he wants to do so, nothing wrong with it, he still btfo the people he replied to.

>The compiler has no way of knowing if that function will be called from another compilation unit.
Irrelevant

>>61042007
lol'd

File: inline.png (43KB, 1064x330px) Image search: [Google]

43KB, 1064x330px

>>61042163
>static
>static
>static
I wonder how many times can you be btfo'd in a thread without risking your health.

>>61042112
even better

(defun print-sum (&rest ns)
  (print (apply #'+ ns)))

now we can sum any number of numbers (including imaginary #s)
you fags can't even do this

>>61042188
>...because he wants to do so, nothing wrong with it, he still btfo the people he replied to.
No, he didn't. He pretends to have a point when he's basically just avoiding the thing we have been trying to say the entire fucking post.

>Irrelevant
It's very relevant, and you're just pretending to have a point when you know you have fucked up and trying to backpedal.

>>61042187
>Yes, it fucking is
Keep acting like a retard, sadly it won't change the facts.

>You're demonstrating the Dunning-Kreuger effect.
If you say so, kek.

Just read >>61042060, he even quotes your bullshit.

>I'm responding to two different posters
No you are not you piece of shit.

>>61042199
>I wonder how many times can you be btfo'd in a thread without risking your health.
You don't btfo anyone by moving the goalpost. We were clearly discussing the standard library's qsort, and you decided to pretend to have a point when you fucking don't. Kill yourself for being a useless piece of shit.

>>61042167
>How stupid.
Yes it's all very dumb.

>>61041889
>everything is easy
I'm really looking forward to your C++ REPL.

>>61042211
>just avoiding the thing we have been trying to say the entire fucking post.
The posts said that "a function passed by reference cannot be inlined" which he proved wrong. Stop backpedalling you fuckface.

>It's very relevant, and you're just pretending to have a point when you know you have fucked up and trying to backpedal.
It's still irrelevant.

>>61042230
>No you are not you piece of shit.
So you're samefagging then, nice.

>Just read >>61042060, he even quotes your bullshit.
"he"
You just admitted to samefagging. Fuck off. Also, it doesn't matter if he quotes. He's still avoiding the very issue we have been discussing this entire fucking thread.

qsort does not fucking inline the compar function argument. Period. Pretending it does is all forms of retarded and/or trolling.

>>61041889
>>design an esoteric language
>>difficult
Yeah, you could do some HQ9+ tier sort of shit and call it an "esoteric language". It just depends if you want to design a language that's actually Turing complete.

>>61040926
No, it's fine.
It only gets ugly when type_traits are involved, which should be fixed when concepts land.

>>61042248
>The posts said that "a function passed by reference cannot be inlined" which he proved wrong.
You are taking the statement out of context, we have been discussing qsort the entire fucking thread. Stop pretending to be retarded.

>It's still irrelevant.
It isn't, we are fucking discussing qsort vs std::sort.

>>61042238
I wasn't saying they were all easy. I'd consider writing a good window manager to be quite difficult, I wouldn't even know where to start. But I'm a fairly inexperienced programmer and I'm writing a bootloader for my job right now, and it's not that hard, and I've written silly little esoteric languages before, they're certainly not difficult either.

Where did I mention a C++ repl? I wouldn't really know where to begin (unless I could somehow rip the parser from clang or g++)

>>61042258
Turing completeness is not difficult. Brainfuck is turing complete.

>>61042211
>It's very relevant, and you're just pretending to have a point when you know you have fucked up and trying to backpedal.
I'm not who you're replying to, but there is nothing from stopping the compiler from inlining a function, but still keeping the normal version around for use in other translation units.

>>61042232
>But a function passed by reference cannot be inlined

>>61042256
>So you're samefagging then, nice.
Nope

>You just admitted to samefagging
No, I did not.

Keep being a retard however.

>He's still avoiding the very issue we have been discussing this entire fucking thread.
He proven the bullshit in the posts that he quoted as wrong, he is not avoiding anything.

>qsort does not fucking inline the compar function argument
qsort is not a compiler so I am unsure how this is relevant.

>>61042232
I'm actually the C++-tard who proved std::sort is 2x faster, I just don't like when people post about things they don't know. My points are
1. Both C and C++ compilers can inline functions passed by pointers if they have access to the source code.
2. C compiler doesn't have access to qsort's source code, meaning it can't inline shit and qsort is inherently slower than std::sort.

>>61042285
That's the imaginary compiler argument again. No, there isn't anything stopping it from doing that, but most compilers known to man don't.

>>61042286
Just kill yourself, you mongoloid.

>>61042275
>You are taking the statement out of context
Nothing is out of context there. See >>61041954
He is talking about function pointers in general. Thus, you are wrong.

>It isn't, we are fucking discussing qsort vs std::sort.
Well, that post did not. You are being offtopic.

>>61042277
>Turing completeness is not difficult. Brainfuck is turing complete.
Yeah, I know. Implementing brainfuck is "easy" at best.
Being creative enough to come up with something original and actually interesting like piet is more challenging.

>>61042166
C doesn't have overloading

>>61042302
>damage control

>>61042288
was about to say that in the (rare) case that the comparison function is slow or big, the inlined version might be slower, but then both probably just wouldn't inline it

>>61042302
>but most compilers known to man don't
How do you fucking know? Just the fact that GCC has an option "-fkeep-inline-functions" proves you wrong.

>>61042302
>That's the imaginary compiler argument again. No, there isn't anything stopping it from doing that, but most compilers known to man don't.
Except, like, gcc?

    .file    "bullshit.c"
    .text
    .p2align 4,,15
    .globl    sum
    .type    sum, @function
sum:
.LFB0:
    .cfi_startproc
    leal    (%rdi,%rsi), %eax
    ret
    .cfi_endproc
.LFE0:
    .size    sum, .-sum
    .p2align 4,,15
    .globl    apply
    .type    apply, @function
apply:
.LFB1:
    .cfi_startproc
    movq    %rdi, %rax
    movl    %esi, %edi
    movl    %edx, %esi
    jmp    *%rax
    .cfi_endproc
.LFE1:
    .size    apply, .-apply
    .p2align 4,,15
    .globl    sum2
    .type    sum2, @function
sum2:
.LFB2:
    .cfi_startproc
    leal    (%rdi,%rsi), %eax
    ret
    .cfi_endproc
.LFE2:
    .size    sum2, .-sum2
    .ident    "GCC: (Debian 6.3.0-18) 6.3.0 20170516"
    .section    .note.GNU-stack,"",@progbits

>>61042288
>C compiler doesn't have access to qsort's source code, meaning it can't inline shit and qsort is inherently slower than std::sort.
A C implementation could technically implement it in a header file.

But it's not qsort's source code that is the issue, it's the code of the compar argument that is the issue.

>>61042199
>>61042060
Uhm, these functions aren't inlining any function pointers, you retards. sum2 is inlined, but apply still jumps to the rax argument.

>>61042319
>>61042303
KYS retards, se above.

>>61042361
See >>61042372

>>61042358
Lol wat, that doesn't prove anything....

>>61042361
Source code

int
sum (int a, int b) {
  return a + b;
}

int
apply (int (*f)(int, int), int a, int b) {
  return f(a, b);
}

int
sum2 (int a, int b) {
  return apply(sum, a, b);
}

compiled with $ gcc -S -Ofast bullshit.c
C++fag BTFO

>>61042372
>Uhm, these functions aren't inlining any function pointers, you retards. sum2 is inlined, but apply still jumps to the rax argument.
Holy shit, you really ARE a retard.

>>61042372
> A C implementation could technically implement it in a header file.
No it can't, C doesn't have the `inline` keyword, implementing it in a header would result in conflicting symbols on linking.
>Uhm, these functions aren't inlining any function pointers
>sum2 is inlined
You can't be this stupid.

>>61042394
sum2 is inlined, apply isn't.

Your claim is that function pointers can be inlined, but it clearly isn't.

reminder that C has inheritance

struct Base {
   int a;
};
struct Derived {
   struct Base super;
   int b;
};
int main() {
   struct Base *object = malloc(sizeof(struct Derived));
   object->a = 12;
   assert(((struct Derived *)object)->super->a == 12);
   return 0;
}

>>61042388
>See >>61042372
If you had any part of your brain still intact you would realise that it's sum2 that calls apply with the sum argument and not apply that calls sum or sum2, right?

>>61042403
>C doesn't have the `inline` keyword
It does.

>>61042411
>sum2 is inlined
The code of sum2 is not inlined anywhere.
It looks like that the C++ niggerian was trolling all along. Like the python troll from the past.

>>61042394
>C++fag BTFO
You are desperate, aren't you? C++ can inline function pointers as well, but it can also inline std::sort, while C can't inline qsort.

File: Screenshot_2017-06-23_16-04-38.png (122KB, 715x564px) Image search: [Google]

122KB, 715x564px

>>61042403
>No it can't, C doesn't have the `inline` keyword

Retard

http://www.open-std.org/JTC1/sc22/wg14/www/docs/n1256.pdf

Section 6.4.1 Keywords

6.7.4 Function specifiers

>>61042166
Old versions of C don't have overloading

>>61042431
>>61042441
Oh, right, the more you know.

>>61042415
It does not support multiple inheritance sadly, unless if you do some weird tricks with arrays of pointers or something.

>>61042438
Irrelevant to the topic.

>while C can't inline qsort
You are proving yourself to be a retard yet again, C is not an implementation.
Also, what would teh point of inlining qsort be anyway?

>>61042441
Inline doesn't really do anything right now. Compilers ignore it. I doubt they even use it when they've decided they can't decide.

>>61042445
*no version of C

>>61042465
>it does not support multiple inheritance
>SADLY
even the most far gone OOP programmers consider multiple inheritance a mistake now.

>>61042438
not him but C can inline anything
procedure for inlining anything:
>write the function body in place of the call to the function
>if the function is recursive, replace it with an iterative algorithm that simulates recursion using a pushdown automaton

>>61042465
>C is not an implementation
Yet no known C implementation does it for some reason.
>Also, what would teh point of inlining qsort be anyway?
2x performance gain?

>>61042467
>Compilers ignore it.
No they don't.

>>61042482
>Yet no known C implementation does it for some reason.
How is this relevant to what you said?

>2x performance gain?
Not possible. The time it takes to call qsort is nothing compared to actually sorting an 500MiB array.

>>61042490
Show me an example where inline made the compiler inline rather than not inline.

Ignore the C++ troll.

>>61042445

W A C K

>>61042479
C# does

>>61042481
Not if the source code of the function isn't accessible, idiot.

>>61042536
C# is not a version of C. This is like saying that C# is a version of Haskell.

>>61042507
Have you read the thread? std::sort outperforms qsort 2x on the same data because of inlining.
And the point is not to inline qsort itself, but by inlining qsort you can inline the comparison function as well.

>>61042479
>no version of C
C++

>>61042509
The `inline` keyword has nothing to do with inlining, m8, it's about linking duplicate symbols.

>>61042553
He's interpreting 'inlining qsort' as meaning inlining the function call to qsort.

>>61042467
>>61042482
>>61042509
Whether you use the inline keyword or not is irrelevant to the fact that C can inline. And here is exactly how it supports inlining: >>61042481
If this solution turns you off because you want to avoid code duplication, just use macros. It'll never be a problem, because you'll never have to write a recursive one.

>>61042553
>std::sort outperforms qsort 2x on the same
Wrong, there is nothing in the standard that dictates that this is the case.
Or do you mean in a specific benchmark of specific implementations?

>because of inlining.
Not because of qsort not being inlined, every sane person would consider this point as retarded.

>>61042561
Not a version of C.

>>61041874
It's weird how a lot of the ones marked "Easy" and "Medium" are things I have no idea how to do, while a lot of the ones marked "Hard" and "Fuck you" are programs I've actually implemented (at least partially) in the past.

>>61042542
>Not if the source code of the function isn't accessible
This should never be a problem. You shouldn't be trying to inline someone else's function, and if you're trying to inline your own, just use macros and #include. By the way, you shouldn't use closed source software.

>>61042619
I guess I should use the standard library then. Functions in it can't be inlined if they're external, which most are.

>>61042637
shouldn't*

File: [email protected] (60KB, 500x631px) Image search: [Google]

60KB, 500x631px

>>61040119
Working on my imageboard, 4kev.org

>>61042637
>implying anything in the standard library is actually difficult to implement yourself in a way that's trivial to inline by the process i describe

>>61042596
>Not because of qsort not being inlined, every sane person would consider this point as retarded.

C++ outperforms C because it's able to inline the comparison function.

It's able to inline the comparison function because it's able to inline std::sort that uses it.

Without inlining the sorting function you can't inline the comparison function.

Without inlining qsort you can't inline the comparison function.

Without inlining the comparison function you can't achieve C++-tier performance in C.

You can't achieve C++-tier performance in C because the compiler is unable to inline qsort.

Is this clear enough for you, or shell I repeat?

>>61042479
C does have overloading; you just can't do customized overloading like you can in C++.

>>61042656
>Cfags
C++ doesn't have this problem.

>>61042658
Why do you put two line breaks between each sentence?

Don't you see that it takes up twice as much vertical space?

Also it makes you look like you're retarded.

Kys.

>>61042664
C++ has 99 problems and being too much better than C ain't one.

>>61042675
Shorter sentences are easier to understand for people. I assume anon thinks that separating the sentences might help people understand that they're separate statements better.

>>61042675
Not him but putting only one line break between paragraphs is hideous and hard to read

>>61042675
A U T I S M

>>61042658
>C++ outperforms C because it's able to inline the comparison function.
*my specific implementation of C++ in my specific example outperforms my specific example of C because...
Which is irrelevant to what you said, you talked about inlining qsort, something totally different.

>It's able to inline the comparison function because it's able to inline std::sort that uses it.
Inlining the comparison function is a totally different step.

>Without inlining the sorting function you can't inline the comparison function.
You still claimed that it was faster because std:sort can be inlined, which is wrong.

>Without inlining qsort you can't inline the comparison function.
Irrelevant to the topic as even if qsort was inlined the change in performance would be marginal.

>You can't achieve C++-tier performance in C because the compiler is unable to inline qsort.
Wrong.

>>61042675
Because he is.

>>61041874
Rolling. Please be something cool.

>>61042731
It's shit. Reroll.

>>61041874
some of these, like 79 are just stupid

>>61042746
For fuck's sake.

>>61042711
>my specific implementation of C++ in my specific example outperforms my specific example of C because
Feel free to present a counterexample.

> Inlining the comparison function is a totally different step.
This is why it's a totally different step in my explanation.

>You still claimed that it was faster because std:sort can be inlined, which is wrong.
It's not because without inlining std::sort first the compiler couldn't have inlined the comparison function, the same way it can't inline it without inlining qsort first.

>Irrelevant to the topic as even if qsort was inlined the change in performance would be marginal.
Wrong. If qsort was inlined the compiler could have inlined the comparison functions since it would have all the call sites available to it.

>Wrong.
Wrong.