sb hermit posted:

The best thing about templates in C++ in the late 90s is trying to decode compilation errors

The second best thing is trying to find out why template code in msvc wouldn't work in g++. I think it was because you need to explicitly generate template code by defining its use (with a specific type) in a cpp file. MSVC, since it knows the entirety of the source used in the executables (unless it's a library, I guess, but this was for student assignments anyway), could automatically infer which code to generate for which type and save you the hassle.

Sapozhnik posted:

Anybody who claims to be able to bash out syntactically correct code involving generics on the first attempt is a filthy liar

In any language with a concept of templates or generics or whatever.

Zlodo posted:

It's the same with msvc versus clang and it's kind of a pita if you work on a project with a mix of target platforms using msvc and platforms using clang. Everytime I do template stuff i fully expect the CI to scream at me about the clang platforms being broken.

One of the reason is that clang parses templates as soon as you declare them. If you write for instance a declaration whose type is T::butt, since the compiler doesn't know T while parsing the template, it doesn't know whether T::butt is a type or a member function or a variable or what, so parsing fails. You are supposed to write "typename T::butt" in this case, which is kind of ugly but is the only way to tell the compiler "T::butt is meant to resolve to a type".

Msvc however doesn't need this, because it defers parsing template when you actually use them, at which point it doesn't need that explicit hint to know what T::butt is.

Another thing is that for the same reason, anything you use inside of templates must be declared before the template itself in clang, and in msvc it's fine not to do so as long as it's defined before you instantiate the template.

Msvc basically tolerate code that isn't supposed to compile because of less rigorous handling of templates. It also have its downside, like you write a bunch of template code and it compiles fine and then you start actually using it and it turns out to be choke full of dumb mistakes

MrQueasy posted:

I don't think this is that hard in a language that does it well and simply, like Kotlin.

MrQueasy posted:

I don't think this is that hard in a language that does it well and simply, like ... Haskell

Zlodo posted:

It's the same with msvc versus clang and it's kind of a pita if you work on a project with a mix of target platforms using msvc and platforms using clang. Everytime I do template stuff i fully expect the CI to scream at me about the clang platforms being broken.

One of the reason is that clang parses templates as soon as you declare them. If you write for instance a declaration whose type is T::butt, since the compiler doesn't know T while parsing the template, it doesn't know whether T::butt is a type or a member function or a variable or what, so parsing fails. You are supposed to write "typename T::butt" in this case, which is kind of ugly but is the only way to tell the compiler "T::butt is meant to resolve to a type".

Msvc however doesn't need this, because it defers parsing template when you actually use them, at which point it doesn't need that explicit hint to know what T::butt is.

Another thing is that for the same reason, anything you use inside of templates must be declared before the template itself in clang, and in msvc it's fine not to do so as long as it's defined before you instantiate the template.

Msvc basically tolerate code that isn't supposed to compile because of less rigorous handling of templates. It also have its downside, like you write a bunch of template code and it compiles fine and then you start actually using it and it turns out to be choke full of dumb mistakes

gonadic io posted:

This is what happens when you can't pay off your technical debt

Powerful Two-Hander posted:

incorrect, you sell it as a collateralised technical debt obligation

Powerful Two-Hander posted:

collateralised technical debt obligation

Captain Foo posted:

Zlodo posted:

One of the reason is that clang parses templates as soon as you declare them. If you write for instance a declaration whose type is T::butt, since the compiler doesn't know T while parsing the template, it doesn't know whether T::butt is a type or a member function or a variable or what, so parsing fails. You are supposed to write "typename T::butt" in this case, which is kind of ugly but is the only way to tell the compiler "T::butt is meant to resolve to a type".

Msvc however doesn't need this, because it defers parsing template when you actually use them, at which point it doesn't need that explicit hint to know what T::butt is.

Xarn posted:

It is standardized. Shocking exactly noone, MSVC is not compliant.

sb hermit posted:

I think I got one of the release copies of J++. I remember it being far better than any other Java IDE at the time.

To think that Microsoft could have made a ton of money off of Java tooling if the execs just played nice and not attempt the classic Microsoft extend and extinguish strategy.

Shaggar posted:

as a client application language java was worthless without j++. it was either let microsoft take over the language and provide extensions to make it useful on the one client OS that matters OR kick microsoft out of java and resign the language to server side only.

Shaggar posted:

as a client application language java was worthless without j++. it was either let microsoft take over the language and provide extensions to make it useful on the one client OS that matters OR kick microsoft out of java and resign the language to server side only.

Sagacity posted:

it's really annoying to see that the only 'good' way of creating fairly lightweight crossplatform UIs is still Qt, after multiple decades. perhaps juce, if you're an audio developer, i guess. if you're not a c++ toucher you're pretty much out of luck. electron is a thing simply because other stuff was worse and that legitimately pisses me off somewhat.

meanwhile, the developer behind 'druid', one of a million half-finished UI crates for Rust, wonders why people aren't adopting it even though they've rewritten the core multiple times in a breaking way. (to be fair: he has a ton of really interesting ideas on UI toolkit development, it just never seems to go anywhere super concrete).

Sagacity posted:

it's really annoying to see that the only 'good' way of creating fairly lightweight crossplatform UIs is still Qt, after multiple decades. perhaps juce, if you're an audio developer, i guess. if you're not a c++ toucher you're pretty much out of luck. electron is a thing simply because other stuff was worse and that legitimately pisses me off somewhat.

meanwhile, the developer behind 'druid', one of a million half-finished UI crates for Rust, wonders why people aren't adopting it even though they've rewritten the core multiple times in a breaking way. (to be fair: he has a ton of really interesting ideas on UI toolkit development, it just never seems to go anywhere super concrete).

champagne posting posted:

doesn't help that smartphones / tablets were thrown into the mix and took a big ol crap on how UIs are designed

Sagacity posted:

it's really annoying to see that the only 'good' way of creating fairly lightweight crossplatform UIs is still Qt, after multiple decades. perhaps juce, if you're an audio developer, i guess. if you're not a c++ toucher you're pretty much out of luck. electron is a thing simply because other stuff was worse and that legitimately pisses me off somewhat.

Soricidus posted:

the only thing wrong with desktop java these days is that people still remember desktop java 15 years ago

Sagacity posted:

it's really annoying to see that the only 'good' way of creating fairly lightweight crossplatform UIs is still Qt, after multiple decades. perhaps juce, if you're an audio developer, i guess. if you're not a c++ toucher you're pretty much out of luck. electron is a thing simply because other stuff was worse and that legitimately pisses me off somewhat.

meanwhile, the developer behind 'druid', one of a million half-finished UI crates for Rust, wonders why people aren't adopting it even though they've rewritten the core multiple times in a breaking way. (to be fair: he has a ton of really interesting ideas on UI toolkit development, it just never seems to go anywhere super concrete).

redleader posted:

actually phone uis are easy! just make everything really big and minimize the amount of things you put on the screen. anything that users might actually want to use should be hidden behind undiscoverable ui actions (double tap here! swipe there!). the beauty of this approach is that you can just reuse the ui without changes on desktops because they're basically the same as phones

chaosbreather posted:

imo the biggest problem with these gui frameworks is they're all just 'here's how to build a form', not 'here's how to build a studio application'.

chaosbreather posted:

if one of the demos isn't a straight up rich text editor writing to a custom schema with embeddable custom widgets you can move around, and that code doesn't make you want to die, that ui framework is not ready. i've looked and man there isn't a single one that meets the textedit challenge, except web, which has like a dozen pretty good well maintained hugely popular libraries for doing that poo poo, and about 3 actually good ones.

cool av posted:

ugh please don’t try to put rich text editing in your apps just don’t you don’t need it

chaosbreather posted:

if one of the demos isn't a straight up rich text editor writing to a custom schema with embeddable custom widgets you can move around, and that code doesn't make you want to die, that ui framework is not ready. i've looked and man there isn't a single one that meets the textedit challenge, except web, which has like a dozen pretty good well maintained hugely popular libraries for doing that poo poo, and about 3 actually good ones.

champagne posting posted:

laugh-cries-emoji in Microsoft Teams