Welcome • User Guide
ToS • Privacy • Canary
Donate • Bugs • License

©2025 Poal.co

960

Microsoft has a framework called WPF. Whilst nice in some ways, it isn't portable, has tons of bugs, and insane, over the top architecture, and tons of issues which were never fixed. Whilst it can do a lot, a lot of the design decisions leave a lot in terms of questions. For example, why do tree views not have context to their parents? Why are dependency properties so retarded?

After a while, i looked into the world of GTK. Wasn't a fan. And QT came into the picture. Now, outside of not knowing jack about the framework, I somehow become more productive in C++ and QT than i did in WPF. Sure, the app wont have the look and feel polish, but it can run everywhere, it has tons of libraries, and its pretty fast. It also leaves you with tons of casting options out of the box, which makes IO super convenient.

Overall, I'm done with Microsoft, however look out for my new side project being released later on this month

Microsoft has a framework called WPF. Whilst nice in some ways, it isn't portable, has tons of bugs, and insane, over the top architecture, and tons of issues which were never fixed. Whilst it can do a lot, a lot of the design decisions leave a lot in terms of questions. For example, why do tree views not have context to their parents? Why are dependency properties so retarded? After a while, i looked into the world of GTK. Wasn't a fan. And QT came into the picture. Now, outside of not knowing jack about the framework, I somehow become more productive in C++ and QT than i did in WPF. Sure, the app wont have the look and feel polish, but it can run everywhere, it has tons of libraries, and its pretty fast. It also leaves you with tons of casting options out of the box, which makes IO super convenient. Overall, I'm done with Microsoft, however look out for my new side project being released later on this month

(post is archived)

You are currently inside a comment thread.
Click here to see all the comments (25).
[–] • 0 pt

You use memcpy and function pointers . . . just use storage size and one or two member functions.

Right. Ok. Gotcha.

calling memcpy with a propagated constant size) is optional depending on how the code is compiled, and it only happens when the function is inlined

"... only when inlined . . ." this is only (?) the inline-ing performing the function of parameter passing on the stack. It must be, cos if not, then you're saying that inlined functions operate differently. And that would be fucked up.

When you start tupling it up in C++ you need a new monomorphism for every combo, essentially duplicating the T code.

well, if that's a problem, then that's just an optimization error. But it's not a problem: These are types to start with. And if the three or twenty instantiations of some templated objects/classes and algorithms (int vs my-complicated-thing vs some-externally-manipulated-thing vs another templated thing) require different code, then so be it. Yes, inefficient. Yes not-runtime variable, Yes, C++ has again been shown to be fucked . . .

. . . well, I don't know. I think it's reasonable to have a compiler validate all possible paths, structures. That's kinda the deal with C++, it's completely uptight. What you are suggesting is a liberating and efficient freedom - yay for that - except.... except when you want to be sure (as possible) that a program is going to do what you want it too. Fail early.

I think you are basically saying:

  • the C method you suggest is more elegant

  • the C method can handle runtime (compile-time unknown) strucures

  • C++ templates are compile time only

  • C++ templates produce lots of code.

Yeah. sure. I agree with all of those. And with C++: what the fuck?

[–] • 1 pt (edited )

To sum it up: A <T> parameter must always be known at compile time. A function parameter list (T_size, T_compare, ...) doesn't have have this restriction yet can still be optimized when T is known at compile time. By using <T> you've mangled your code to make it less general and less reusable in order to get the compiler to write efficient code. This is the quintessential premature optimization.

There are other uses of templates. Parametric polymorphism is great. But templates actually suck at this too and so does C++'s type system. That's another topic.