The government, or the state in general decides. Whether the laws are problematic or not depends on someone's personal view. You view them as problematic, the parent commenter probably views them as unproblematic.
>soon will also consider mis gendering as hate speech.
I think it should be up to the individual case; deliberate misgendering can cause significant psychological trauma and distress, especially if in multiple occurrence.
"Non-discrimination on the basis of gender identity and expression may very well be interpreted by the courts in the future to include the right to be identified by a person’s self identified pronoun. The Ontario Human Rights Commission, for example, in their Policy on Preventing Discrimination Because of Gender Identity and Expression states that gender harassment should include “ Refusing to refer to a person by their self-identified name and proper personal pronoun”. In other words, pronoun misuse may become actionable, though the Human Rights Tribunals and courts. And the remedies? Monetary damages, non-financial remedies (for example, ceasing the discriminatory practice or reinstatement to job) and public interest remedies (for example, changing hiring practices or developing non-discriminatory policies and procedures)."
>If they could only do the same to weasel-wording and stating falsehoods on the internet...
and thank god they can't, at least not for now. i can still say any bullshit i want on the internet, as is my right.
from your own article:
>Non-discrimination on the basis of gender identity and expression may very well be interpreted by the courts in the future to include the right to be identified by a person’s self identified pronoun
nice precedent
>Policy on Preventing Discrimination Because of Gender Identity and Expression states that gender harassment should include “ Refusing to refer to a person by their self-identified name and proper personal pronoun”. In other words, pronoun misuse may become actionable, though the Human Rights Tribunals and courts. And the remedies? Monetary damages, non-financial remedies (for example, ceasing the discriminatory practice or reinstatement to job) and public interest remedies (for example, changing hiring practices or developing non-discriminatory policies and procedures). Jail time is not one of them.
oh ok, no jail time, but i'm forced to hire someone that identifies as an attack helicopter, great!
>So what does this mean for pronoun misuse? Well, refusing to use a person’s self identified pronoun is not going to be considered advocating genocide – unless the refusal to use the pronouns was accompanied by actually advocating genocide against trans and gender non-binary folks.
so its fine unless i promote genocide, kinda makes sense but its still a slippery slope imo
>Similarly, it’s hard to see the refusal to use the appropriate pronoun –without something else – rising to the threshold of hate speech. Hate speech laws in Canada have only been used- and only can be used – against extreme forms of speech – explicitly and extreme forms of homophobic, anti-Semitic or racist speech.
so pronoun misuse is still legal, unless it gets to "extreme", whatever that means. and who decides what "extreme" is?
>Moreover, prosecution needs the approval of the Attorney General.
while that is certainly true, using QML you can build native apps using almost only javascript (if you want), most people have no idea about that too i suppose.
but i agree, for many people C++ is a no-no, even though Qt C++ is pretty straightforward with all the helpers they provide (like the parent-child memory management).
You can write all of your Qt logic in javascript if you want to. It will probalbly still be much faster than a browser. But the thing is that Qt allows you to write your logic (and your ui) in C++ if you need to. It gives you somewhere to go when performance is an issue. And on mobile or embedded there is a high chance that only a compiled, no-vm, no-gc language like C/C++ or Objective C or Rust will give you the performance you need. One thing is for sure: If you have to build a cross platform native application be sure to first prototype the performance and processor/battery use of your technology choice. Even if you don't choose something like Qt at least you can write your backend in C++ and write a different native front end for each OS. But if you use e.g. web technology and don't prototype first there will be absolutely fire escape later. A lot of people have learned this the hard way.
> You can write all of your Qt logic in javascript if you want to. ... But the thing is that Qt allows you to write your logic (and your ui) in C++ if you need to.
Maybe that sounds appealing to some, but for me is just choosing between two evils. Unsafe dynamic language on one side - kitchen-sink low-level language on the other side.
I personally would like something in between, but still cross platform. F# with Xamarin looks most appealing to me, but Xamarin is unfortunately not free, so...
All these QML/js stuff smells rather artificially put (into Qt) to me... I mean, why not have a functionality to define the scene (and not just a logic) in pure C++? I think one reason for QML/js is to (try) attract contemporary js/web devs.
Last time I checked (Qt 5.3), I was forced to duplicate native widgets on my own, and write my own Framework wrappers on Android, with zero support for Windows Store applications.
From what I could understand in the Qt 5.5 release notes, this has hardly changed.
anytime i see shit like this, all i can think is: fuck the industry and the market, fuck commerce, mass production, mass consumption. fuck socialism, communist and capitalism. fuck "democracy" and the fact that it never existed in the first place. and most important of all, fuck class warfare and everything it represents!
this week is Indonesia fires, last week was china insane pollution from gadget manufacturing. next week will be something else. we wont ever be free while all the above exists..
I'm not sure the narrow field of vision is that important for a dev. kit. The goal is to let people work out how best to produce apps for this kind of interface.
If they can't sort it for consumer release, that's a much bigger issue of course. My guess (and it's just that) would be that they'll be trying to improve field of vision for the consumer release, as from the reviews I read it was the one major negative people cited.
The reason the narrow FOV is important is because right now, the FOV is so small that you can't see a person's hands and face simultaneously at a comfortable conversation distance. There's a huge number of applications where you won't know the suitability, or even be able to visualize/test if it'll work well w/o knowing a target FOV for a consumer revision.
well i would be more inclined to agree if they didn't announce their product with full view (at least 120º) capability.
i mean, we all saw the videos from the announcement, and the "live" demos. and that was just pure lies no matter how you want to paint them.
also even if they didn't lie, don't we need the dev kit to have the same full capabilities as the final product? would you acquire an early dev kit for some new console, only to find out that it has less ram, gpu and/or cpu than the final product? how can we actually test it fully?
> would you acquire an early dev kit for some new console, only to find out that it has less ram, gpu and/or cpu than the final product? how can we actually test it fully?
I guess for MS is important to have a good portfolio of apps before the product is launched to the public. This class of unpolished dev kits are not unheard in MS world, Do you remember when the dev kits for the XBox were Apple Power Macs?
oh sure, in an ideal world the dev kit would have all the capabilities of the live consumer device.
But when you're developing a new category of device, that's not always possible.
For a very related example, look at the Oculus Rift approach to VR. they've been iterating on developer kits slowly improving the hardware while letting people feel out how to use that class of device.
Ultimately it'll be down to individual dev. houses whether it makes sense for them to invest at this stage, or wait till it's closer to consumer launch
'narrow as hell' is your assessment based on what?
Is there some industry standard minimum field of view for AR glasses that this fails to meet? Have the people who tested HoloLens out who complained about the field of view being narrower than they would like said that it made the technology useless, or just that it limited it? Seems like you think it's a showstopper, I'd be interested to know why.
"nice one hackernews, downvoting the most important question in this thread... "
We're less than an hour in and the OP question is the top comment... I'm not sure what's so wrong to you about the HN community here?
Almost every AAA game I've seen didn't use the STL. Boost is a definite no-go for most studios.
Stack allocations are discouraged because they can introduce non-deterministic bugs (stack overflow depending on the call sequence which can't be predicted in advance).
Its nearly impossible to write a game without dynamic allocations. Most of the time they'll override the new/delete operators and on that level they work almost exclusively on void*.
You're working on a scale where a lot of the C++ features work against you.
- "Almost every AAA game I've seen didn't use the STL."
that’s probably because most of the AAA games you've seen used old in-house libraries that replaced the STL, since the earlier STL implementations weren't the best.
STL is not 100% the way to go every time, but i would say that nowadays unless there’s a really specific implementation need, it should be used at least 90% of the times, even if only for base for new data structures to be built on top of.
- "Stack allocations are discouraged because they can introduce non-deterministic bugs (stack overflow depending on the call sequence which can't be predicted in advance)."
i really don’t understand this problem, you can change the stack size on every compiler and every OS either on compile time or runtime. also, are you writing functions or methods with 10k LoC?
stack allocations are actually easier to follow than heap, its not even close..
- "Its nearly impossible to write a game without dynamic allocations. Most of the time they'll override the new/delete operators"
yes i agree, dynamic allocations are still really needed, and not only for games.
But, overriding new / delete operators in C++ when you can set custom allocators and deallocators for both unique_ptr and shared_ptr? once again i think that’s more of a legacy code update problem than an actually implementation need problem.
- "and on that level they work almost exclusively on void*."
only if they want to, that’s what templates (and again the STL) are here for.
I’m not saying pure C++11/14 features are the only way to go, i just think that at least in new code it should take priority, the cleanness and robustness it provides its just too good to ignore.
You arguably don't need that many data structures in a game engine, almost everything is tightly packed in linear arrays. Even hash-maps are frowned upon. The single most used structure I've seen in engines is the plain old array because of cache locality. Everything is pre-sorted, pre-looked-up and pre-crunched so the main use-case is a straightforward linear traversal with as little branches as possible. Also templates can greatly affect compilation times which are already horrible on projects of such magnitude.
On the last AAA game I worked on we had very tight memory constraints and running about a dozen threads. Almost all of them used the minimum stack size except for the main thread. There were still a lot of stack allocations, but only for very small temporary objects and when the call stack was known to be shallow. Using megabytes for stack sizes would consume a noticeable percentage of the available memory which was direly needed elsewhere.
I've seen one game using shared_ptr and it was far from being great. There's a big overhead to it when compared to custom allocators. You can't easily optimize for cache locality with shared_ptr (as far as I know!) and working around enable_shared_from_this can be a real pain. With custom allocators you can easily optimize according to the use-cases.
Finally, templates are required to know their type at compile time, which for things like allocators is just not possible in many cases. For example, we used a bump-the-pointer allocator for a frame's temporary values which could be of any type but still needed cache locality. We also used a fixed-size allocator when avoiding memory fragmentation was more important than cache locality. Both would be impossible to do on anything but void*.
I haven't tried Rust yet, but they all easily translate into D!
I've lost count of the number of times I've thought to myself "I wish C++ has this D feature." A lot of them are being added now but the interesting ones (concepts!) are still years away and some (inout functions!) are nowhere in sight.
And then there's templates, mixins, auto this, compile-time reflection, and so much more. Its far from perfect (nothing is) but constantly improving and rather productive. Of course also being a user of Clojure (and Emacs-LISP) I sometimes miss something like defmacro, which I can almost get with mixins and templates but often not as elegantly. On the other hand, I write shell scripts in D all the time and not in Clojure!
Did they ever fix the memory release semantics with std::vector?
Last time I looked std::vector::clear() wasn't required to release memory and caused a lot of headache when certain implementations wouldn't free the underlying memory.
I'm aware that the work around is to assign a new std::vector<T>() but that always felt like more of a hack then anything else.
this is a reply to vvanders comment, for some reason i cant reply directly to his comment, so ill reply to myself..
they didn’t really "fix" it, instead they added a method called std::vector<T>::shrink_to_fit() which i'll admit its not the most elegant way, but it works.
what it does is, it resizes the capacity() to be the same as the size(), deallocating all the extra memory.
About the reply issue: its simply HN's mechanism to prevent flamewars from escalading quickly. The deeper a comment is the longer you have to wait after it is posted to be able to reply to it.
