Shuffling off this mortal coil



  • @tsaukpaetra said in Shuffling off this mortal coil:

    I can't wait until 2098 release of c++...

    I'd feel bad for anyone that speaks of C++98 in the 2100's and is faced with the ambiguity of referring to the recent spec or the over a century old one they still use at his workplace. I hope it's not a common enough problem that people will need to disambiguate.



  • @kian said in Shuffling off this mortal coil:

    I find it funny that the table says "to be determined" for the 2017 and 2020 versions, the versioning scheme seem's pretty clear.

    I think the "TBD" is indicating that the new feature lists in these versions have not been fully established yet.



  • @kian said in Shuffling off this mortal coil:

    No ambiguity: make it a rule that you don't use raw pointers for owning resources, which is easily enforced by running a search for "new" in the code base and flagging any ocurrences, and every raw pointer in the codebase is now not owning.

    But non-owning pointers can still point to arrays or single objects. Guess you need another rule about no-arrays.



  • @kian said in Shuffling off this mortal coil:

    No ambiguity: make it a rule that you don't use raw pointers for owning resources, which is easily enforced by running a search for "new" in the code base and flagging any ocurrences, and every raw pointer in the codebase is now not owning.

    Nice in theory, but not as simple as it sounds (third-party code, ...). Most raw pointers don't come from "new" anyway, they are mostly returned by various APIs (mapping resources/buffers, non-standard memory allocations, APIs using pointers as handles, ...).

    It's easier to start using something like observer_ptr in a few cases (e.g., when returning a pointer: if it's an observer_ptr, the callee can just eventually forget about it; if it's a raw pointer, it's off to the documentation to see what should be done -- the latter hopefully becoming increasingly rare).


  • Discourse touched me in a no-no place

    @kian said in Shuffling off this mortal coil:

    Shared pointers are only really supposed to be used for sharing ownership across threads, where it's impossible to know who is the last user of a resource and so you have to share the ownership.

    There are other scenarios which need that sort of thing. The key factor isn't whether threads are in use, but rather whether the lifetime of the object can be tied at compile time to a particular scope. Threads aren't the only way in which that can become … well, complicated to determine. A classic example is with an implementation of an interpreted language: the lifetime of an object is often determined by a scope, but not a scope in C++ but rather in the other language.

    Simplistic rules are for noobs. We're not noobs round here.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.