On January 30, 2016 1:31:09 PM EST, Noah
On 1/29/2016 7:00 PM, Rob Stewart wrote:
Have a look at boost::intrusive_ptr.
If I understand boost::intrusive_ptr correctly, and I'm not totally sure that I do
You missed, and snipped, the context. You were discussing ways to inject your logic. intrusive_ptr uses free functions, found via ADL, to manage the reference count. That approach could work for you.
Many times I don't want to initialize a variable because the branches in the subsequent code select the value. Do your wrappers provide a constructor that permits leaving the value uninitialized?
So first let me say that I'm not proposing a total ban on primitive types. When you need the performance, and primitive types give you the performance, use them. But that should be small fraction of the world's total C++ code.
Okay, but I was asking whether you provide for that case.
What is antiquated, in my opinion, is that primitive types are the still the default. In terms of not wanting to initialize due to subsequent conditional assignment, I would say don't underestimate the compiler optimizer. When the optimizer can figure out that the default initialization is redundant, it will remove it for you, right?
You also can't assume that the optimizer will recognize such things.
I should note though, that I found it difficult (or impossible) to fully mimic all the implicit conversion rules of primitive types, so there are going to be some cases where the substitute classes can't be used (without rewriting some of your code) for compatibility reasons.
That could prove to be a stumbling block, but you can propose your ideas.
And they also address the bug prone implicit conversion between signed and unsigned ints.
Once you do that, shouldn't you go the rest of the way and check all conversions? For example, what about overflow during marketing narrowing?
I don't know what "marketing narrowing" is,
I don't either. (Actually, it was my attempt to Swype "narrowing", which was interpreted as "marketing", but I didn't fix it correctly.)
but recently on this newsgroup people have been discussing a "safe integer" or "safe numerics" library that seems to have taken it all the way, and maybe even a bit further. My types do check ranges when converting to different integer/char types.
That's what I was alluding to.
By default, an unsigned integer minus another unsigned integer should really return a signed integer, like my primitives do.
I understand what you're trying to do, but that's a narrowing conversion. The signed type may not be large enough to hold the difference. ___ Rob (Sent from my portable computation engine)