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

©2025 Poal.co

1.2K

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)

[–] • 1 pt

Probably best not to identify your self here though. Never get too comfortable.

[–] • 0 pt

This, you better believe the ADL or someone else watches this place.

[–] • 0 pt

Indeed. We need you happy, healthy and safe.

Never give our enemies a hairs worth of ammunition to get to you.

[–] • 1 pt (edited )

I worked with WPF for several years and damn, it is so fucked up to find out some details don't quite work and stuff missing in the platform. Having to do special stuff for some mundane operation and spend days for a workaround. Passing messages, dispatcher wizardry... it sucks. Microsoft, fuckers.

[–] • 1 pt (edited )

Not a programmer so I didn't know what you guys were talking about.

This nice Asian man I found on youtube explained what the fuck a QT is:

https://www.youtube.com/watch?v=eiZe6C0SnC4

edit

https://www.qt.io/pricing

$329 per MONTH!!??

Is that hard to just write your own GUI within an operating system? Shouldn't the OS have a lot of the crap written into it already?

Don't you just tell the OS "put a button here", "put a scroll bar thingy here"?

[–] • 1 pt (edited )

C++ sucks.

<T> templates are a premature optimization very similar to #define functions in C. Modern compilers can recognize and propagate constants so that type agnostic functions e.g. (void *data, void *fptr, int size, int offset, int stride) have equivalent performance. Type agnostic functions are the most generic of generics, where the same source code is both runtime flexible and compile time optimized depending on how it is compiled. A type agnostic C function can be both inlined from a .h or linked into python. With <T> you need to forsee all future type arguments and ensure each combination is represented in object code. The C function remains runtime generic if you want it to. If you want the C++ <T> behavior you can always wrap a type-agnostic function that calls it inlined with certain constants.

And that's only functions. <T> invites all sorts of abuse in memory layout. This is bigger than the AoS vs SoA debate. Object code for <T<U>> is specific to those arguments. In C the <U> would be kept in a separate container, allowing the same object code to process the <T> part. This argument boils down to preferring composition over mixins and inheritance.

One thing <T> does nicely is bundle a bunch of attributes/concepts/whatever (can't use either word without overloading common meanings) so that T::next() and storage and all sorts of ideas go with it. The type agnostic C function requires tracking these things by other means. Ultimately this is a language deficiency in C. That's another topic. But I stand by my argument that the best part of C++, <T>, actually sucks.

[–] • 0 pt

I don't care about C++ sucking or not sucking (it sucks), but.

With <T> you need to forsee all future type arguments and ensure each combination is represented in object code.

But "all future type arguments" can't be forseen, so are not represented in object code. Of course. And why would they be? There are these things pointers and references.

The C function remains runtime generic if you want it to. If you want the C++ <T> behavior you can always wrap a type-agnostic function that calls it inlined with certain constants.

what are you talking about? What are you going to cast your C's void to, inside your C "type-agnostic function"?

<T> invites all sorts of abuse in memory layout.

Let's say you're right, and the rest. Even if it's a screaming goat fuck, it doesn't matter if a 500kb program becomes a 30MB, a 30MB a 300MB. No one even notices, and so what?

In C the <U> would be kept in a separate container,

"Container" ?

Hey, don't get me wrong: Great, thoughtful post, but ..... what?

[–] • 1 pt (edited )

You don't cast your c void* into anything. You use memcpy and function pointers that are passed in. The type agnostic algorithm uses only basic machine types for control flow. That's all it needs. Numerous sorting and searching algorithms and structures can be implemented this way. Think about what your typical <t> algorithm actually needs. Most of these just use storage size and one or two member functions. These can be function parameters instead of type parameters, making the code applicable to different sizes and types at runtime if needed. This makes the C "generic" twice as generic as the C++ template, which is hamstrung to be a compile time generic only. Monomorphism in C ( e.g. 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. C functions can be inlined inside a wrapper that makes certain parameters constant, yielding equal performance to <t> monomorphisms. C++ <t> is always monomorphic once compiled.

By "container" in C I mean a separate retrieval structure. Usually an array. So you have an array of T and an array of U and then have a single monomorphic function handle T for all U. When you start tupling it up in C++ you need a new monomorphism for every combo, essentially duplicating the T code. </t></t></t>

[–] • 0 pt

Your perspective seems to be focused on a comparison of void* in C to templates in C++.

You use memcpy and function pointers that are passed in.

Those function ptrs are typed. This is not "generic".

These can be function parameters instead of type parameters, making the code applicable to different sizes and types at runtime if needed.

This is also done in C++, and with a large set of type-safety features that C lacks. Function pointers are not inherently better than functors.

This makes the C "generic" twice as generic as the C++ template

and it confers no benefit, whatever "twice as generic" means here

, which is hamstrung to be a compile time generic only.

C++ virtual tables are not an inherent improvement over C, and modern C++ development eschews vtbls for performance reasons. (It's not hard to implement vtbls in C, but it's kind of ugly, and undesirable.) Not sure why you would want run-time polymorphism in C, to be honest.

Inlining a function in C++ is perfectly fine. constexpr-ing an expression is better. If you can tolerate larger data segments, a constant-expression carries all of the benefits of the C++ type system that C simply does not have. There is no equivalent to this in C, and it provides case-specific optimization limited only by the lexer's expression memory. And that's without templates or preprocessor symbols.

There are optimizations that can be done with C++ templates and template-constraints that easily outstrip even the smartest SSO AST optimizers. The C++ WG did this in part to remove the need for code so highly customized that it begins to operate like a DSL, while still providing best-case performance from a conformant compiler.

[–] • 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?

[–] • 0 pt

Mane brah look up dis game called mugen

U can learn dat c++ threw notepad mane

[–] • 0 pt

C++ sucks balls.

Say what you like about Ms but c# is the best fully fledged language by far.

C++ devs spend far more time debugging and less time producing code

[–] • 1 pt

Or maybe you know, you suck massive nigger faggot dick

[–] • 0 pt

Glad to upset an c++ apologist.

Such a shiity language that produces buggy expensive apps.

C++ is obsolete

[–] • 1 pt

I cAn'T wRiTe cPluZPluZ bCuZ iZ tOo HaRd lol

Yes, seven-hundred and ninety-three point nine seven motherfucking terabytes of CLR (*) is worth it. That's the answer.

Yes.

Clearly.

(*) This number is hyperbole. Don't be a nigger about it.

[–] • 2 pts

as someone who tried calculating the black hole of the CLR, still debating whether .NET CLR or NodeJS suck more dick

[–] • 0 pt

C# isn't easily portable. Java and C++ are.

[–] • 0 pt

Garbage. For starters Java is a dying pig of a language.

But fact is dotnet mvc core is extremely portable.

Actually if portable is the main desire build any web app. Far superior to crappy other apps.

[–] • 0 pt

Out of the top 25 websites in the world, only 2 aren't using Linux. 96.3% of the world's top 1 million servers run on Linux

[–] • 0 pt

I've worked with Qt (Linux mostly, and windows) for over a decade, using it's various python bindings (PyQt, PySide). Pretty powerful. I think you do virtually everything in Python more concisely than you can with C++ with Qt uis.