Sharlock93

And more error prone.

All together :D

I'll have you know that I know of compilers that are deprecating c++17

This is the correct take. A few people chose A internally. Very sad day :')

We had an internal convo about which one someone should pick:

A)
If(const char* x = func()) {...}

Or

B)
const char* x = func();
If(x != nullptr) {...}

What do y'all think?

you can look types by name. and allows dynamically type construction. Renaming because you wanna
rename "basic_string<char, char_traits<char>, allocator<char>>" as "std::string" so you can look up it up easier.
why during static init? No earthly idea. They didn't profile this code.

Using A which needs updating now.
Internal structure doesn't keep track of relationships to make the update a minimal set thus testing against a lot of types.

This is an optimization I thought of to reduce it further beyond 8 seconds. However I was needed in other parts of the system and tasks :)

The problem is as follows:
You have type A, and then type B which is a templated type that has A as one of the template arguments.

The system allows type renaming so if you rename A => AA, the system will go through every templated type and reconstruct the names because one of those types might be

I mean this is the way to do it. I'm fairly certain if I had the time and the desire the stuff is as working on can be constexpred, not even need static init.

lmao

Final update on this for a while, this is now down to 8 seconds. Final piece of the puzzle was doing a compare against size of string check before the real check. And replacing string Compare function by strncmp. Memcmp might also work but, 2:07 to 8 seconds is a win.

I do my best to use vim and compile on the command line, even go as far as use a plugin on vim for debugging and running code.
It's just not programmer friendly.

My main gripe is I cannot watch a variable without pulling hair out.

There are considerations to be made around context free and non-context free grammars that might impact performance but that do not imply a specific choice in syntax.
In either case, not my circus not my monkeys.

I do not understand what this means tbh again my point and what i understood from the previous statement is that "zig is awkward because it wants faster parsing" which implies if you want "non-awkward syntax" you will have a slow parser which is not as far as i know a correct statement.

I'm not sure i agree with the implied "faster parsing" is mutually exclusive with good syntax.
In either case at this point I'm stuck on C and probably wouldn't respec into another language. C is almost perfect, the newer C version add good things.
Waiting for Cuik to mature at this point.

Man when you use Xcode and then go back to visual studio you realize how much ergonomics and use QoL is missing from Xcode. Like good god. Wish Microsoft didn't abandon the Mac version and fully added the ability to build projects in Visual Studio. So much better than Xcode.

I bounced off zigs syntax quite hard but that is just me.

Thank you both for taking the time to reply to my queries. Very useful discussion.

Yes this is the main issue with the "=" operator. It hides things that should be explicit. After all it's just a function call and I'd much rather have that function call be named something other than "=". The "copy()" function is a great idea.

I have yet to write a full ECS system and deal with these things/see what alternatives exist. But this seems like a useful use.

Yes, operator overloading for math types is the only place i know where operator overloading is useful.
I'm very much against overloading the "=" being overloading. To me it hides information which should be explicit in the code.

I personally have only had bad experiences with both variadic templates and operator overloading. First in the context of debug and second on the context of understanding the code.
I'd be curious if you had examples where you like to use variadic templates?

What is a feature you really like in C++ that other languages don't have?

Yet another update on this, I further optimised this to 12 secs under debug by skipping string allocation along some other minor optimizations. Ideally I wanna knock off the extra two secs and get a solid 10 or under 10 secs for debug.

bro is posting fake symbols.

Yall did a great job on it! I'm waiting for our console partners to fully support it before we move all the people at work on it. So much better experience compared to 2022

Always something with Sony, you never know what they are up to. This genuinely is scary because it means they might pull the plug on Nixxes and its a shame to put the talents job in jeopardy. All rumours so far ofc. Fingers crossed this isn't true.

Cat to cheer you up bud

my g is dying