[haiku-commits] Re: BRANCH midar-github.master - headers/os/support
- From: Jonathan Schleifer <js-haiku-commits@xxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Tue, 20 Nov 2012 17:53:07 +0100
Am 20.11.2012 um 17:29 schrieb Ingo Weinhold:
> On 11/20/2012 04:42 PM, Jonathan Schleifer wrote:
>> Am 20.11.2012 um 16:12 schrieb Ingo Weinhold:
>>> Rather use size_t.
>>
>> Oh, size_t is ok? I usually always use size_t and even overuse it (a habit
>> after 10 years of coding C ;)), but thought that in C++ unsigned long is
>> preferred, because this seems to be what the STL uses. Changed.
>
> We mostly avoid the standard built-in primitive integer types in favor of
> more expressively named typedefs. The BeOS API often uses int32 for
> counts/sizes, which is usually OK, since one virtually never uses more than 2
> billion elements anyway and, being signed, the type allows for -1 as a
> special value (invalid index). For pure size/count values like in this case
> size_t is definitely the right choice (also for the template parameter, BTW
> :-)).
Ah, I'm glad to hear you handle it that way. Most users of C++ unfortunately
don't seem to do it, while most users of C do.
What I usually do instead of signed is use size_t and return SIZE_MAX for not
found / invalid / error. Is that ok in the Haiku world or is using a signed
type preferred?
> I would remove the operator. I'm not opposed to it in principle, but only in
> cases where the object behaves like a function.
Agree'd. But I couldn't find a more fitting operator, see below.
> In other cases it possibly makes the code harder to read.
In this case it looks ok, IMHO. You declared the object before, so you *know*
it's not a function :).
> A cast operator for Type* would be nice. And if you also add the * and ->
> operators, one would virtually never have to call Array() anyway.
That would only be evaluated if explicitly casted, right? Or will this also be
evaluated when implicitly casted? If the latter is the case, this would
basically mean that in most cases no operator at all is needed.
As for * and ->, I don't see how this would be useful or look natural.
Accessing the first element is rarely done with * and if it is on an array, I'd
even say it's bad style. As for ->, that makes no sense at all, IMHO: The ->
operator can't be used on an array.
Ideally, you'd be able to use it exactly like an array, without any difference.
And adding () when needing a pointer seemed like the smallest difference
possible ;). That is, if the implicit casting does not work.
(Sorry for not knowing whether this is only for explicit or also for implicit
casts - as I said, I come from a C background and while I have spent the last
10 years writing mostly C (and later ObjC), I have never dug really deep into
the C++ as all C++ code I've seen before I read Haiku code just looked really
ugly and made the language look badly designed - luckily, Haiku could change my
opinion of C++, though ;))
--
Jonathan
Other related posts:
