This looks cool, I find myself wishing for a language and introductory tutorial that isn't so targeted at Python programmes however (though I understand from a commercial point of view why that may make sense).
It seems like this is actually an elegant typed functional language but the Python syntax looks ugly and verbose and like it's trying to hide that compared to something more ML/F# or Haskell inspired.
I'll try and get past that though as it does look like there's something pretty interesting here.
Modules, standardised in C++20, are the official solution both for the standard library and for other code but they are not universally well supported by all major compilers and build systems yet.
Transitioning existing code to use modules is also not entirely straightforward, though probably no more problematic than introducing unity builds.
> though probably no more problematic than introducing unity builds.
A "Unity build" really just means typing #include "foo.cpp" a few times. It's trivial.
Meanwhile, neither Clang nor GCC support standard library modules. They have only partial support for modules themselves. C++ module support is non-existent in almost all build systems. https://en.cppreference.com/w/cpp/compiler_support
The idea of C++ modules is great. It's badly needed. In practice I'm not sure if they're ever going to be genuinely functional and widespread. Which makes me sad. Toy projects don't count.
It's been a lot of chicken-and-egg, but C++ modules finally have momentum. FWIW, Clang does support `import std` with `libc++` now. While I've implemented CMake support for modules, I've worked on laying the groundwork for compilers to be able to provide the required information (P1689) and I've been involved in advocating support from a number of build systems (e.g., Bazel, xmake, Meson, Tup). Some have been more receptive and made progress; others have had less.
This is true but in practice it's pretty common to find this sort of code seems to work fine on x64 because the compiler doesn't actually reorder things and then sometimes blows up on ARM (or PowerPC, though that's less commonly encountered in the wild these days).
Yeah, this is one of those things that while it may be more technically correct causes a lot of unnecessary confusion. I remember being confused by this as a C++ programmer learning Java when resources claimed that Java was always pass by value where the actual behaviour in almost all cases (due to Java going almost all-in on objects) is what a C++ programmer would expect from pass by reference.
I still see even relatively experienced programmers who don't understand this, particularly working with Unity where a lot of programmers came from C++ to C# and don't realise for example that a C# function that takes a List 'by value' and modifies it is actually modifying the same instance that was passed in by the caller.
No, Java really is pass by value. You can rely on this in Java:
String s = "hello";
foo(s);
assert s == "hello";
In C++, if the function takes a non-const reference, you can't.
Yes, Java always passes pointers to objects. But you can pass pointers by value. And passing a pointer by value is not the same as passing by reference!
I think the origin of the confusion around a function taking a list by value and the like is the implicitness of pointers in Java and its cousins. This Java method:
void foo(List<String> strings)
Is the equivalent of this C++ method:
void foo(shared_ptr<List<string>> strings)
True systems languages make the pointers explicit.
That's only because strings are immutable in Java. It's not true for reference types in general.
In C++ passing a pointer by value is effectively the same as passing a reference, the only real difference being that the syntax for accessing the underlying value is more implicit for a reference.
No, in Java, this is true for reference types in general. The method receiving the pointer can mutate the object, but it can't change which object the original variable points to.
This is also true when passing a pointer variable by value in C or C++. It is not true when passing a reference in C++ - the receiving method can change which object the original variable points to.
Ok, that's not really what your example showed though. You seem to be relying on string interning to have two different "hello" literals refer to the same underlying object and therefore be equal? Coming from other languages, and specifically C++, I tend to see `==` as value rather than reference equality so that wasn't immediately obvious to me.
The equivalent code in C++ has different semantics but a function that takes a non const reference in C++ cannot change what the reference refers to (references are immutable in that sense in C++, they can only ever refer to one object). What a non const reference allows in C++ is for the called function to change the value of the object referred to and since strings are not immutable in C++ that means that the value of string s could change, not the object identity.
With pointers to pointers, or references to pointers in C++ you can further change the object pointed to / referred to but not with references (there's no such thing as a reference to a reference in C++).
The implementation of inheritance (more specifically, polymorphism and dynamic dispatch via vtables) is a problem in games, because it adds an extra layer of indirection, and screws with cache locality. But the semantics of inheritance (X ISA Y) still apply. In an ECS, the implementation is different (struct-of-arrays) but you can still think of an entity as "inheriting from" the various components its built from.
That's not really accurate. Component based systems are designed specifically to address situations that traditional inheritance doesn't handle well.
Examples are usually something like having a base entity, a player that inherits from entity and an enemy that inherits from entity. Then you have a magic user and a barbarian inherit from enemy but now you also want your player to be able to use magic. Traditional OOP doesn't make it easy to share the implementation.
Even with composition and interfaces you still have problems with most traditional OOP languages when you want to do things like change the set of components of an entity dynamically at runtime (player gains or loses the ability to use magic during the game).
"Is a" is often not the relationship you want to model. A player and an NPC both have the "has a" relationship to an inventory, not the "is a" for example.
> you can still think of an entity as "inheriting from" the various components its built from.
If it's based on components, wouldn't that mean you would think of it as being... _composed_? I typically don't hear "it's made of many components" and think of inheritance
Well, it does work well for the engine part of game engines, and graphics related code in particular as the GP says - it's just gameplay code where OO falls a bit flat.
Not really, the data oriented design movement in games programming that eschews OOP is driven by performance concerns of traditional OOP code on areas like rendering.
As a graphics programmer for many years I can also say that OOP is not really a good fit design wise for modern rendering engines, it mostly just gets in the way.
I only really know of Bevy that uses ECS for the rendering backend, but iirc even that doesn't really use entities and components, but rather its resource system, such that rendering commands are stored in the ECS "world" but as globally unique resources, rather than entities and components. But, my knowledge doesn't extend to AAA engines, perhaps things are done more extensively there.
I don't follow - role playing games are often most suited to ECS, because you want the kind of emergent gameplay that independent gameplay systems acting on component composition gives you - and the kind of flexibility it allows in composing weapons, spells, buffs/debuffs, and so on, vs a strictly hierarchical OOP approach.
If we're talking server tech then why does the article claim that 10gbps is becoming retail commodity? 10,40 and 100gbps is already the baseline for servers since a decade, I have not seen a server with 1gbps NICs for anything else than remote management or off band communication in a decade.
CableLabs.com, the creators of the DOCSIS standard for cable modems are part of an industry wide push towards 10G internet for ISPs. According to Neilsen's law, we should see 10G internet become more common than 1G internet is today within 10 years.
According to Neilsen's law, we should see 10G internet become more common than 1G internet is today within 10 years.
That's a cool thing. Let's look forward to it, and the rising tide that lifts all boats. The world will be a much more connected place 10 years from now, and the 10G target from CableLabs.com as well as DSCP packet tagging, L4S and other technologies will make the internet a lot better than it is today.
- Pattern matching (arguably a more flexible and general way to do the type of thing you have in your number 4 if syntax)
reply