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


Thread archived.
You cannot reply anymore.


[Advertise on 4chan]


File: cpp-3707286926.gif (451 KB, 1161x922)
451 KB
451 KB GIF
>templates are so powerful!
and they suck.
>verbose
>ugly
>fragile
>undebuggable
>>
>>107771943
just write it like C with some extra features and you will have none of these issues. Except maybe "verbose" I guess but to me that means nothing.
>>
>>107771958
>just write it like C with some extra features
The template language has more (structurally) in common with Haskell than it does with C.
>>
>>107771998
I was talking about the language in general. For templates it's really not that bad if you use them sparingly and stick to a C-like style for the rest of the language.
>>
>>107772029
>If you use them sparingly
And that's exactly the problem.
C with a system F omega type system (which templates are loosely equivalent to) is actually a really good idea. The problem is that templates genuinely fucking suck to use. The idea we have this immensely semantically useful language feature, but have to arbitrarily avoid using it because it destroys a codebase, is precisely the problem. They're hardly unique in that respect, but probably the one I'm most asshurt about.
>>
stick to python, jeet
>>
>>107771943
>>undebuggable
you can debug them, what are you talking about?
nocoder + skill issue
>>
Skill issue.
>>
>>107771943
Anybody who hates the mere idea of templates / generics really must not have worked on any significant, or are retarded or something. Even if they have downsides, they are essentially absolutely necessary
> C++
See the problem is you haven't experienced generics in a reasonably ergonomic language
>>
File: 1625679100405.jpg (307 KB, 800x1018)
307 KB
307 KB JPG
>>107771943
For 99% of real-world uses of templates, preprocessor macros are better and easier to debug (albeit admittedly somewhat less ergonomic).
>>
>>107774252
Templates are literally the worst possible mechanism ever devised for metaprogramming.

It's a shame, because metaprogramming as a concept is underrated and incredibly useful. Templates further tarnish its image.
>>
>>107774305
I like metaprogramming. C++ templates are a turd floating in the bathwater.
>>
They are all those things, but they also allow you to optimize dynamic code into a compile-time calculation with tremendous speedups, if you're pursuing that. There is no free lunch.
>>
>>107774501
how would you implement c++ templates better? everyone is waiting.
>>
>>107771943
Surely not just cpp sucking ass yet again...
>>
>>107774648
You read this off StackOverflow and substituted it for individual thinking.
>>
>>107774252
reading comprehension
>>
>>107774671
Lisp macros. Do not reply unless you have something constructive to say.

Hell, even >>107774285 is an acceptable solution for simple cases.
>>
>>107775391
The lack of generics in Go was never a real problem. Type-generic code is really not that common in actual practice, most of the time it's just academic masturbation.
>>
>>107774648
their whole problem is entirely due to shit-tier grammar and lack of compiler tooling for interactive debugging.
"there are no free lunches" doesn't apply here, none of the problems are due to their feature set, but because bjarne is a gigantic fucking retard who has fumbled the ball more times than your mother has sucked cock.
>>
>>107774671
For starters, having a single type system instead of two. Next, instead of having an autistic division between evaluation of forms in 3 different stages, type-level programming is performed in type-family declarations. Finally, actually have unification when binding type variables instead of whatever the FUCK is happening in sepples.
>>
>>107775713
It's incredible how an unusably autistic dynamically typed piece of shit has such a good metaprogramming system. Besides it and Prolog, I can't think of a single language with properly debuggable metaprograms.
>>
>>107775713
how can u do lisp macros if there isn't a runtime that can evaluate arbitrary code? these are impossible in the context of c and c++, as neither of these provide a runtime environment. sbcl compiled to a native binary still has a substantial runtime.
>>107775816
ok how would you implement that then? please provide pseudo code to convey your idea that would also allow backwards compatibility with c.
>>
>>107775698
I came to that conclusion after a two year stint with c++ where this type of optimization was fundamental, moron.
>>
>>107772140
>C with a system F omega type system (which templates are loosely equivalent to) is actually a really good idea.
Not when
array + 1
is pointer arithmetic and a "string" is a pointer to a single byte where you can keep adding 1 to it until it points to a 0 byte. A "system F omega type system" in C is just void* with extra complexity and no added type safety.
>>
>>107776230
void print('t a) { std::cout << a; }
print(0);


It's as simple as that.

>that would also allow backwards compatibility with c.
Go ahead and use templates in an extern "C" block. There is nothing C compatible about them. That's the point. Although, if parametric functions like this are inlined and treated properly, there's realistically no reason you couldn't use this version within C-linkage areas. Maybe if bjarne wasn't a fucking retard we could have had a decent implementation of parametric polymorphism instead of the garbage that we're stuck with now.

>>107776394
In some purist's idea of the word, probably. In practice, GHC Haskell has pointer arithmetic, null-terminated strings and type coercion etc. but I don't see you talking shit.
I don't care if type invariants are inviolable. I want recursive types and higher kinded types for expressive metaprogramming and soft logic boundaries, not as a serious replacement for formally verified code. Stop acting silly.
>>
>>107771943
C++ lost. Rust won. Rust has:
> Good documentation
> Better type system
> Much less oop cancer
> Allows you do cool, fun, functional programming and get C like performance
> No header file autism
> No cmake retardation
> Cool community of helpful friends waiting to answer your questions.
>>
>>107776609
>Allows you do cool, fun, functional programming
No it does not.
Functional programming without zero-overhead function composition and point-free style is absolute cancer. Rust has neither. Instead it encourages the exact same dogshit imperative-iterator style that modern C++ does where you get none of the expressive benefits of functional programming and all of the dogshit debugging experience.

Also the lack of interface files has resulted in Rust having keyword crap sprinkled all over source files just like C++. Yeah, just throw all those pub impls all over my code please and thanks! It's like I'm really programming in Java!

If Rust got a real module system and dropped the borrow checker I'd probably pick it up.
>>
>>107771943
Can't you just debug them with your brain or are you some sort of weak jawline glasses wearing code monkey?
>>
>>107776659
Based chad bullying the nerds on /g/
>>
>>107776659
Unlike you, I actually write serious software and not shitty web backends for a VC money laundering front.
>>
File: images.jpg (10 KB, 258x196)
10 KB
10 KB JPG
Not a problem in my language
>>
>>107776705
Literally the exact same shit
>>
>>107776725
not at all.
>not verbose
>not ugly
>not fragile
>easily debuggable
+ D also has good contract programming to pair with it
>>
>>107776740
It's all of those things. D copied all the anti-patterns of sepples metaprogramming verbatim.
>>
>>107776747
not sure you know what verbatim means
>>
>>107776756
Ill verbatim dez nutz all over your mom's face if you catch my drif
>>
>>107776756
I do and he did.
>>
>>107776772
considering the most basic thing (syntax) is different, it's not verbatim, so you don't.
>>
>>107776587
i dont really see how that is any different than using template <typename T> and does not solve any of the actual issues with templates. it is just a different naming convention.
>>
>>107776587
>In practice, GHC Haskell has pointer arithmetic, null-terminated strings and type coercion etc
?????
>GHC Haskell has pointer arithmetic
pretty much nobody deals with pointers doe
>null-terminated strings
"default" strings in haskell are singly linked lists
>and type coercion
coercion, as in implicit conversion, only happens for literals. `coerce` in haskell is just glorified wrapping and unwrapping of newtypes: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/coercible.pdf
>>
>>107775713
This is objectively correct. Bjarne was inspired by CLOS and templates are a horribly fucked up way of attempting Lisp macros/generic functions in C++ but the idea is exactly what C++ was attempting to do
>>
>>107778763
>pretty much nobody deals with pointers doe
And yet they exist, and there's nothing you can really do to keep them out of a codebase except just don't write them. Which is equivalent to C programmers saying "just don't make memory bugs".
>as in implicit conversion
No, I mean unsafeCoerce and everything in that module. All of them break type safety, none of them care about if a type is coercible or not. You can even strip monads away if you're a psycho.
>>
>>107778914
>and there's nothing you can really do to keep them out of a codebase except just don't write them.
And they're unavoidable if you work with foreign code at all*
>>
>>107771943
c++26 static reflection is looking very promising to replace templates
>>
>>107777507
probably because you asked for psuedocode for mostly implementation details
>>
>>107779241
he complains about having "multiple" type systems, and provides a solution with "multiple" type systems. lets use our heads here.
>>
File: ACK.png (388 KB, 760x704)
388 KB
388 KB PNG
>>107776609
>> Cool community of helpful friends waiting to answer your questions.

Oh boy can't wait communicate with mentally ill dudes on troonshine.
>>
>>107778995
>we fucked up
>here's the new thing to replace the thing we fucked up
>you still have to keep the old fucked up thing for compatibility btw
>ok well we fucked up again
>here's the new thing to replace the previous 2 things we fucked up
>...
sepple
>>
>>107780536
third time's the charm!
>templates
>concepts
>static reflection
>>
>>107771943
Only because u a brainlet.
>>
>>107781688
I kinda forgot that C macros are iteration 1
>>
hygenic macros with intermediate output visible would definitely be a lot better. i feel like templates are the reason that c++ value semantics got crazy with all the different value types and pitfalls to avoid
>>
>>107780412
Nothing I wrote implies two type systems.

>>107783674
No. No macros. Just literally have a properly designed type system with higher order kinds or functors. Semantically C++ has this, but in practice it's a royal pain in the ass to use where there are weird limitations over basic things because it's a slap-dash piece of crap cobbled together over decades. It's powerful, but poorly designed. Qualifier dropping, bad decisions in the deduction rules, etc. You can do a lot with templates, but actually utilizing that power is a game of pulling teeth.

Qualifier dropping is easily one of the stupidest, most asinine decisions that the language went with. A thousand curses on the standards committee for this shit.
template <typename T>
void overwrite(T ptr) {
*ptr = 99;
}

const int x = 42;
const int* px = &x;
overwrite(px);



It can't even handle this deduction case:
template <typename T>
void printTwice(T* ptr) {
std::cout << *ptr << " " << *ptr << "\n";
}

int x = 42;
printTwice(&x);


Speaking of the shitty deduction rules, a trivial case that sepples can't handle:
template <typename T>
auto half(T x) -> decltype(x / 2) {
return x / 2;
}
auto y = half(10);


Templates are a classic case of the 85/15 rule. They're 85% of the way to being a decent language feature, and the missing 15% makes them effectively an anti-pattern. The fact so many C++ users avoid them like the plague is a stronger indictment than I could hope to concoct.
>>
>>107784015
>template <typename T>
>void overwrite(T ptr) {
> *ptr = 99;
>}
>const int x = 42;
>const int* px = &x;
>overwrite(px);
What's being dropped here? This correctly doesn't compile. Would it make more sense for you if it did compile somehow? Why?

>It can't even handle this deduction case:
>template <typename T>
>void printTwice(T* ptr) {
> std::cout << *ptr << " " << *ptr << "\n";
>}
>int x = 42;
>printTwice(&x);
That compiles and runs just fine. Again, what did you expect? An error? Why?

>Speaking of the shitty deduction rules, a trivial case that sepples can't handle:
>template <typename T>
>auto half(T x) -> decltype(x / 2) {
> return x / 2;
>}
>auto y = half(10);
Also compiles and runs just fine. Did you expect this to error out? Why?
>>
>>107785955
the guy is very obviously a retard. besides him being wrong with every single code example provided if we were to use his "quote T" template system it would be the exact same thing. im not sure it would solve his "85/15" rule at all.
void overwrite('T ptr) {
*ptr = 99;
}

void printTwice('T* ptr) {
std::cout << *ptr << " " << *ptr << "\n";
}

auto half('T x) -> decltype(x / 2) {
return x / 2;
}
>>
>>107772140
>For templates it's really not that bad if you use them sparingly and stick to a C-like style for the rest of the language.
>And that's exactly the problem.

Pretty much, but the problem goes a bit deeper.
My problem with templates that even if I straight up ignore them on my original code, I probably will end up have to deal them if I end up using a 3rd party C++ library.

I code mostly in C++ following the original "C with Classes" style that was the original idea behind it and because of that whenever possible I use C libraries instead of C++ libraries in order to avoid having to deal with STL and other "modern" features that aren't compiled OOP and shouldn't really be part of C++.
>>
>>107772774
not op. what tools do you use to debug heavily templated code? the standard debugger integrations in most IDEs shart their pants with them

so much so I sometimes prefer to use C simply for projects simply because the debugger actually works out of the box and everything has nice printable values at runtime
>>
>>107778914
>And yet they exist, and there's nothing you can really do to keep them out of a codebase except just don't write them
you could use -XSafe (but this also prevents you from using template haskell so it's a no-go if you're using yesod or something)
>Which is equivalent to C programmers saying "just don't make memory bugs".
to check that nobody is doing pointer arithmetic in haskell, you can basically just check that nobody imported Foreign.Ptr, which is fairly easy. (in practice, it will almost never be imported)
checking that allocated memory is freed, OOB reads/writes don't happen, etc, is much harder in C.
>>
>>107785955
Admittedly, I didn't even bother looking at what the clanker spit out. That's my bad. Whatever, just strip everything after "A thousand curses on the standards committee for this shit."

>>107786662
>if we were to use his "quote T" template system it would be the exact same thing.
My "quote T template system" is meaningless pseudocode I snarkily provided because you asked for a syntactic example when 2/3 things I mentioned are semantic behavior that aren't visible at a syntactic level. So no, it would not "be the exact same thing". That's the entire point. That's why you don't see anything different. I was making fun of you, and I'm sorry for that, but anon god damn you've got a skull thicker than a print out of the sepples standard.
>>
>>107789393
Fair enough.
>in practice, it will almost never be imported
I know in most of the shops that use Haskell, you're rarely ever interacting with foreign code yourself so this holds. It still depends on the domain though. A long time ago in college I wrote a shitty Haskell game engine with a bunch of C dependencies and Ptr was unavoidable and indispensable.
>>
>>107789774
>I didn't even bother looking at what the clanker spit out
>I didn't even bother looking at what the clanker spit out
>I didn't even bother looking at what the clanker spit out
Anons, how are we gonna deal with faggots like this?
>>
>>107789874
Continuing to defend the honor of sepples is probably the best way to get back at me.
>>
>>107789774
c++ templates are zero overhead and generated at compile time. there is nothing you could do to improve them while keeping their advantages. their main downside is you have to recompile the function/class/etc every time a new overload is used. this means you cannot link against precompiled templates. your naming convention could not in the slightest imply anything more than a naming convention because it doesn't address the core issue with them. you have clearly never written code that uses templates if this is the best thing you could come up with.
>>
>>107780436
Get with the fucking times and stop being such a disgusting, bigoted chud.
>>
>>107790278
>c++ templates are zero overhead and generated at compile time
I can only think of Java and Go as examples of AOT compiled languages where generics impose a runtime cost. C++ isn't unique in the slightest.
>there is nothing you could do to improve them while keeping their advantages
There are lots of things you can do to improve them like fixing inference, doing away with the shitty qualifier mechanics, having deeper integration with the language, a better compilation procedure, etc.

Anon, every time you post you make it clear to me that you really don't understand this level of language design. The focus on syntax and surface level details, they have nothing to do with what I'm talking about.
template<class T>
T add(T a, T b);
auto x = add(1, 1);
auto y = add(1.0f, 1.0f);


How does the compiler deduce the types of a and b for x and y? How does it deduce the types for x and y?
>It looks at what's being passed in....
No. How do you go from the AST to the type checker? If I had you write a parser for this purpose, what data structures are you using? How are you walking and working with those data structures?
There is no singular way to accomplish this. Though not apparent on a surface level, different algorithms change what is possible within your type system. Hindley-Milner is popular in type theory, which is a type system that uses an algorithm called unification to deduce types. C++ has a very haphazard and poorly designed type system that lacks even basic equational reasoning.

Consider this:
template<class Container<T>>

Container here does not name a real type, but is itself also a generic type. This is invalid C++, but in Haskell it's perfectly valid and you essentially never even need to write this or type annotations in general, because the type system is capable of proper HKTs and equational reasoning during deduction.
>>
>>107791023
>I can only think of Java and Go as examples of AOT compiled languages where generics impose a runtime cost. C++ isn't unique in the slightest.
they have a runtime cost, they have a runtime and if you are compiling a native binary then you might as well get the performance benefit of c/c++. it has become clear you have no idea what you are talking about, especial with language implementations. your solution to c++ templates is to add more complexity, where does the "quote T" play into your haskell inspired metaprogramming for c++?



[Advertise on 4chan]

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

[Enable Mobile View / Use Mobile Site]

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