Favorite Part About C++

>Ive never heard a clear explanation of zero cost abstractions.
You get type safety at the cost of increased compilation times. They're not technically zero cost (because it takes longer to compile), but it's referred to their runtime cost (which is the same, as these abstractions are synthesised down to the same simple assembly as C).

Okay yes but how does that work exactly? Templates are just safer #define macros overall

>Okay yes but how does that work exactly?
what do you mean? macros are also a zero cost abstraction
so are variables

You answered your own question.

Well thats a really pretentious way of describing a compile time cost.

how is it pretentious?
it's an abstraction and it has zero runtime cost
it's hard to be any clearer

monad is an interface
it says, that there is a function bind defined
bind is function composition, very similiar to `;` in regular languages.
it enables you to pass a value from one function to another without unwrapping it.

example
# common languages, but this also implies handling of anything that happens in getline, e.g. exceptions, errors, bad return values
string s = getline() ; putStrLn(s)

# with bind, composes also error handling w
getline >>= putStrLn

My favorite parts of C++ are zero-overhead exception handling and proper encapsulation both at compile time and runtime. Also a personal favorite is whenever something goes wrong you can always look at the stack trace and figure out where the problem is.

>favorite part about C++ is
C

Oh, another one I forgot, is how informative compiler errors messages are whenever something goes wrong with zero-overhead abstractions provided by templates. Me and my brother who is also autistic sometimes spend days reading and figuring out those.

They point is that you can do stuff like this
#include

template
T sum(const T& a, const T& b)
{
return a + b;
}

struct point
{
int a;
int b;

point operator+(const point& rhs) const
{
point p;
p.a = a + rhs.a;
p.b = b + rhs.b;
return p;
}
};

std::ostream& operator

template
T sum(const T& a, const T& b)
{
return a + b;
}

int main()
{
return sum(3, 4);
}

main:
push rbp
mov rbp,rsp
sub rsp,0x10
mov DWORD PTR [rbp-0x8],0x4
mov DWORD PTR [rbp-0x4],0x3
lea rdx,[rbp-0x8]
lea rax,[rbp-0x4]
mov rsi,rdx
mov rdi,rax
call 4004de
nop
leave
ret
push rbp
mov rbp,rsp
mov QWORD PTR [rbp-0x8],rdi
mov QWORD PTR [rbp-0x10],rsi
mov rax,QWORD PTR [rbp-0x8]
mov edx,DWORD PTR [rax]
mov rax,QWORD PTR [rbp-0x10]
mov eax,DWORD PTR [rax]
add eax,edx
pop rbp
ret
nop WORD PTR [rax+rax*1+0x0]

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

int main()
{
return sum(3, 4);
}

sum(int, int):
push rbp
mov rbp,rsp
mov DWORD PTR [rbp-0x4],edi
mov DWORD PTR [rbp-0x8],esi
mov edx,DWORD PTR [rbp-0x4]
mov eax,DWORD PTR [rbp-0x8]
add eax,edx
pop rbp
ret
main:
push rbp
mov rbp,rsp
mov esi,0x4
mov edi,0x3
call 4004b2
nop
pop rbp
ret
nop DWORD PTR [rax+0x0]

This is not a zero overhead abstraction.

>passing a pointer vs passing a value
At least don't be a dishonest little jew.

I am not dishonest. This is the proper way to do it with ints. This is the proper sum function for ints and it's the one you should compare to when you say no overhead.

>zero-overhead abstractions
>next generation proprietary memory allocation techniques.
STRINGS, VECTORS, STL, BOOST
all this shit slow as f-ck
INSTEAD OF USING NAMSPASES CREATE MUH OBJECTS
then use em for creating memory leaks everevere

Attached: CPP_TARD.jpg (567x432, 64K)

>std::ostream& operator

Comparing two different functions is not how you make a comparsion

>This is the proper way to do it with ints
Then make a template specification for ints or at least pass by value.

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

int main()
{
return sum(3, 4);
}

template
T sum(T a, T b)
{
return a + b;
}

int main()
{
return sum(3, 4);
}

jonas@hobbes:~/prog$ diff template-c.s template2.s
1c1
< .file "template-c.c"
---
> .file "template2.cc"
3,6c3,6
< .globl sum
< .type sum, @function
< sum:
< .LFB0:
---
> .globl main
> .type main, @function
> main:
> .LFB1:
13,17c13,15
< movl %edi, -4(%rbp)
< movl %esi, -8(%rbp)
< movl -4(%rbp), %edx
< movl -8(%rbp), %eax
< addl %edx, %eax
---
> movl $4, %esi
> movl $3, %edi
> call _Z3sumIiET_S0_S0_
22,27c20,26
< .LFE0:
< .size sum, .-sum
< .globl main
< .type main, @function
< main:
< .LFB1:
---
> .LFE1:
> .size main, .-main
> .section .text._Z3sumIiET_S0_S0_,"axG",@progbits,_Z3sumIiET_S0_S0_,comdat
> .weak _Z3sumIiET_S0_S0_
> .type _Z3sumIiET_S0_S0_, @function
> _Z3sumIiET_S0_S0_:
> .LFB2:
34,36c33,37
< movl $4, %esi
< movl $3, %edi
< call sum
---
> movl %edi, -4(%rbp)
> movl %esi, -8(%rbp)
> movl -4(%rbp), %edx
> movl -8(%rbp), %eax
> addl %edx, %eax
41,42c42,43
< .LFE1:
< .size main, .-main
---
> .LFE2:
> .size _Z3sumIiET_S0_S0_, .-_Z3sumIiET_S0_S0_

inb4 Jow Forumsentoomen can't read diffs

The only difference is namespace mangling and that the compiler placed the functions in different order (because template functions aren't exported/always static), pic related

Attached: Screenshot 2019-01-16 at 13.23.06.png (2290x2106, 596K)

>Favorite Part About C++
>no community BS
>job with advanced C++ is retard-free
>only whites and chineses use C++
>very fast
>templates

This is why no one is taking you zero overhead people seriously.
>you can do retarded shit with zero overhead! wow
Even the most basic example you provided is inefficient compared to the most simple straightforward implementation, and the best excuse you can come up with is, "but yours is technically different!"

And then this template function when used with large structs is highly inefficient because it's passing by value.

>zero overhead people
what the fuck are you talking about?

Is there a non retarded way to deal with strings in sepples? Everything wants me to use these fucking stream vector things for the simplest crap.

About people like you who keep spouting this zero overhead bullshit without having the slightest idea.

>And then this template function when used with large structs is highly inefficient because it's passing by value.
That's why you do template specialisation.

template
static T sum(const T& a, const T& b)
{
return a + b;
}

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

>mock cniles for needing special functions for every type
>no see its easy! Just write special functions for every type!

Dynamic dispatch isn't a 0 overhead abstraction. Everyone know that. What's your point?

>zero overhead bullshit
I pointed out that you were comparing two different functions
what the fuck are you talking about?
If you're butthurt about templates for some reason it has nothing to do with me

Yeah, good job, you fixed this one. My point still stands: you (or whoever that was) posted the most simple example of zero overhead abstractions you could come up with, and you still fucked it up big time. It is theoretically possible to have zero overhead with templates, but in practice your programs will be show as shit in comparison.

This has nothing to do with dynamic dispatch. Jesus. user. Please.

>type overloading is not an abstraction

void foo(int a);
void foo(float a);

Is a way better than
void foo_int(int a);
void foo_float(float a);

>It is theoretically possible to have zero overhead with templates, but in practice your programs will be show as shit in comparison.
In practice you'll use the STL and most likely Boost which have all the specialisations you'll ever need and then some more.

I am not comparing two functions, I am pointing that the particular example of abstraction that you wrote to demonstrate how it's zero-cost turned out to perform worse compared to the code written specifically for the task.

I didn't fuck up "big time", you posted a comparison of two different functions.... Cniles are really grasping for straws here.

>It is theoretically possible to have zero overhead with templates, but in practice your programs will be show as shit in comparison.
In comparsion to what? Templates basically just exist to copy and paste code for you. That has nothing to do with the runtime. If you've written templated code that is slower it's your own fault

You wrote two different functions and then said one was slower
that means nothing

The comparison is correct - just because you chose to do it in a retarded way to make abstraction possible doesn't mean that I also should when evaluating your solution.

One of them was yours, one of them was mine. Mine does the same thing yours does. This means everything.

You compared two different functions, and now you're defending your mistake like an autist on wheels.

>Mine does the same thing yours does.
It doesn't though, because one passes by reference and the other passes by value.

Stop assuming you know who you're rpelying to on an anonymous forum you idiot
I didn't write any code, I just pointed out you were falliciously comparing two different functions

Compile time evaluation.

I lol'd so hard

>Reference to Generic type
>Not dynamic dispatch
kek

Do you not understand how templates work?

turing-complete syntax tree parser
fuck those contex-tree syntax lisp kids, get on my level

Zero cost abstraction means that using it is as efficient as if you wrote the logic it abstracts by hand. It doesn't mean that you get the logic for free, it means that the abstractions has no additional cost.

constexpr, as it allows to replace dangerous macros

>constexpr
this do nothing
can save remove all "constexpr" from any programm

Hey you, don't use const ref for non compound types
#include
#include
#include

template
constexpr T sum(const T& a, const T& b)
{
return a + b;
}

template
constexpr T sum(T a, T b) noexcept
{
return a + b;
}

int main(void) {
std::cout

Who cares? This shit will get inlined anyway.

based TMP poster

that's not tmp that's just sfinae

Based

I can't really TMP, just some basic enableifs. In fact, I would love to see that snippet be done with one function body declaration conditionally taking by value or const ref

Can't be done without breaking template parameter inference. But like I said this will just get inlined any way so there's no point bikeshedding.

wait. doesn't TMP rely on sfinae?
I've never used TMP seriously since learning it so i forgot.

I can use "C" inside it so I don't have to use the "C++" shit heap.

#include

template
constexpr T sum(const T& v) noexcept
{
return v;
}

template >
constexpr T sum(T v) noexcept
{
return v;
}

template
constexpr T sum(const T& first, Args... args) noexcept
{
return first + sum(args...);
}

template >
constexpr T sum(T first, Args... args) noexcept
{
return first + sum(args...);
}

With fundamental types:
int main()
{
auto n = sum(1, 2, 3, 4, 5, 6, 7, 8, 9, 10);
return n;
}

.file "template4.cc"
.text
.globl main
.type main, @function
main:
.LFB12:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
movl $55, -4(%rbp)
movl -4(%rbp), %eax
popq %rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE12:
.size main, .-main
.ident "GCC: (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0"
.section .note.GNU-stack,"",@progbits

With compound types:

#include

template
constexpr T sum(const T& v) noexcept
{
return v;
}

template >
constexpr T sum(T v) noexcept
{
return v;
}

template
constexpr T sum(const T& first, Args... args) noexcept
{
return sum(first, sum(args...));
}

template >
constexpr T sum(T first, Args... args) noexcept
{
return sum(first, sum(args...));
}

struct tuple
{
int first;
int second;
};

constexpr tuple sum(const tuple& a, const tuple& b)
{
return tuple{a.first + b.first, a.second + b.second};
}

int main()
{
auto n = sum(tuple{1, 1}, tuple{2, 2}, tuple{3, 3});
return n.first;
}

.file "template4.cc"
.text
.globl main
.type main, @function
main:
.LFB13:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
movl $6, -8(%rbp)
movl $6, -4(%rbp)
movl -8(%rbp), %eax
popq %rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE13:
.size main, .-main
.ident "GCC: (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0"
.section .note.GNU-stack,"",@progbits

Now if this isn't a zero cost abstraction, then I don't know what is... Cniles BTFO

i think eigen uses a similar trick to avoid copies in matrix sum. cfags will never know what it's like to write expressive high performance code.

Saved for future Cnile asswiping.

In fact checking for compound types is not necessary when the call to sum is inlined.

#include

template
constexpr T sum(T v)
{
return v;
}

template
constexpr T sum(T first, Args... args)
{
return sum(first, sum(args...));
}

struct tuple
{
int first;
int second;
};

constexpr tuple sum(const tuple& a, const tuple& b)
{
return tuple{a.first + b.first, a.second + b.second};
}

int main()
{
auto n = sum(tuple{1,1}, tuple{2,2}, tuple{3,3});
return n.first;
}

.file "template5.cc"
.text
.globl main
.type main, @function
main:
.LFB11:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
movl $6, -8(%rbp)
movl $6, -4(%rbp)
movl -8(%rbp), %eax
popq %rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE11:
.size main, .-main
.ident "GCC: (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0"
.section .note.GNU-stack,"",@progbits

Cniles BTFO'd and destroyed.

Enable optimizations you BWAAAAAKA

B-but the kool kids on Jow Forums and irc told me evil templates are b-bloat! How is this possible?

You got memed

I work on massively huge C++ projects, millions of LOC, so my favorite feature is obviously the abysmal compile time that allows me to slack and shitpost at work.

«Specific to the performances needed in the game industry, Mr Fleury also details coding decisions that are needed for fast runtime execution (and the compile time they get):

* No RTTI: you prefer to control the memory details yourself ;
* No exceptions: they are simply slow because of the constraints of unwindable stack at any time ;
* No STL containers: std::vector is slow, and complex template code takes time to compile ;
* No boost: surely the library is impressive, but it's never a good idea to use it in serious applications ;
* Very small subset of templates: use it at mininum as it increases significantly compile times.

In definitive, game studios tend to use a "minimal C++", sometimes called C+. And all annoucements about the evolution of the C++ language (since C++11) has been regarded as useless. Indeed, as it often concerns templates of new STL features, the base language does not improve at all.»

It's (slightly) more difficult but also suboptimal in terms of performance.

how?

It sound like you need Rust.

Rust is as slow as C++ when it comes to compile time. May be even slower.

It is slower. Rust doesn't even have incremental compilation besides dumping preparsed ASTs.

kek

>zero-overhead abstractions
she doesn't know she pays for exceptions even without using them

In binary size only, not in execution time.

C++ was a mistake.
t. professional C++ programmer

>-fno-exceptions
>she

How am I supposed to pick just one thing? I like the simplicity, easy to use and modern build system, helpful error messages and blazing fast compile times.

What do you guys use c for on a day to day basis

>Exceptions
>Run-Time Type Information (RTTI)
>thread_local
now what huh?

>-fno-exceptions
More like - unless you're using standard library compiled with disabled exceptions, and then use this library to compile third parties, and then compile you project with disabled exception, you're paying for them.

I c++ what you did there

>fno-rtti
As for thread_local, it does have a small cost if you use it, but you're not required to use it, thus still abiding to the zero-cost abstraction principle.
I myself have used thread_local in several occasions, and it made the code simpler without any noticeable performance loss.
The only parts that admittedly do have some cost even if you don't use them are RTTI and exceptions, but fortunately every major compiler allows turning them off. The cost for RTTI in particular, however, has been significantly reduced in the most recent standards, as more checking is possible as compile time, and hopefully things will improve even further.

Compiling the parts you need without exceptions is easier than you think. Not to mention that, contrary to popular belief, a significant portion of the standard library can be used just fine without compiled exception support, such as the atomic library.
Plus as pointed out, exceptions only affect binary size (very little if you compile with -Os and use lto) and pretty much don't impact speed as long as excpetions aren't thrown. However, they shouldn't be thrown often anyway, using exceptions for control flow, as I've seen sometimes, is retarded.

>move semantics

idk, guaranteed NRVO is pretty cool, I think.

I love the AESTHETIC error reporting. Looks like my metaprogrammed brainfuck compiler needs a major redesign.

reduce your header interdependencies and use PCH properly

Not always. You can do pretty good TMP with overloading function templates.

use fold expressions, they are available in c++17:
template
constexpr T sum(T... args) {
return (0 + ... + args);
}