I don't think itd be ok, personally. My impression is regulations and regulatory institutions can be very slow to evolve after technological advances, unless the government is financially liable. A scheme I would be more comfortable with is mandatory insurance and insurance companies with a financial incentive absorbing the liability. On top of that probably add some bare minimum regulatory requirements/certifications.
Clang can target windows just fine afaik, although I'm sure the whole process could be improved.
That said, as long as windows is the bigger more profitable market I wouldnt expect a switch, unless the dev tooling situation becomes dramatically better on linux
> In addition, success is generally pretty well-defined. Everyone wants correct, performant, bug-free, secure code.
I feel like these are often not well defined? "Its not a bug it's a feature", "premature optimization is the root of all evil", etc
In different contexts, "performant enough" means different things. Similarly, many times I've seen different teams within a company have differing opinions on "correctness"
"life of the program" might imply it needs to begin life at program start. But it can be allocated at runtime, like an example in the list shows. So its rather "lives until the end of the program", but it doesnt need to start life at the start of the program
Not who you were asking but for me about 1800 hours of study+srs+reading+listening for simple shows (not "tons of idioms". Or at least not ones Im not already familiar with). This was for japanese, european languages should be easier.
Speaking as an argentinian, every time I hear about someone using crypto in that way its to avoid taxes, which seems legally murky/gray (if not directly illegal, but not currently prosecuted) to me.
Of course, but there are some oddities in tool use compared to other industries. At my job we use Perforce for version control for example, which I think is more common in the game industry than other solutions for whatever reason. Naturally everyone here hates it.
> Perforce for version control for example, which I think is more common in the game industry than other solutions for whatever reason.
The last game I worked on was like 80gb built. The perforce depot was many terabytes large, not something you want to have on every person's workstation. Games companies use Perforce for a very good reason.
But not everybody here has to try and manage many GB or even TB of assets in their VCS. I wager game company build/dev engineers know what they are doing in picking Perforce.
> Entity–component–system (ECS) is a software architectural pattern mostly used in video game development for the representation of game world objects. An ECS comprises entities composed from components of data, with systems which operate on the components.
> Entity: An entity represents a general-purpose object. In a game engine context, for example, every coarse game object is represented as an entity. Usually, it only consists of a unique id. Implementations typically use a plain integer for this
> Common ECS approaches are highly compatible with, and are often combined with, data-oriented design techniques. Data for all instances of a component are contiguously stored together in physical memory, enabling efficient memory access for systems which operate over many entities.
> History
> In 1998, Thief: The Dark Project pioneered an ECS.
So, according to wikipedia:
- An entity is typically just a numeric unique id
- Components are typically physically contiguous (i.e an array)
- Their history began with Thief pioneering them in 1998
I was rather expecting code examples, so that we could deconstruct the language primitives being used for the implementation from a CS language semantics point of view.
