On 11/20/2012 05:53 PM, Jonathan Schleifer wrote:
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 can't think of a case where it is done that way in the Haiku's API, so I'd rather stick with a signed type. With Haiku error codes being negative it is also common to use a signed return type in cases where discriminating between different error conditions is desirable (e.g. BFile::Read()/Write()).
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 :).
Well, if you know the code, reading it is usually easy. Ideally code is written in a way that you don't have to read the whole function (or even class/file) to understand a part of it. That's why using unusual constructs should rather be avoided.
For the same reason Haiku's coding style requires the use of unabbreviated names for identifiers. Having readable code far outweighs saving a few key strokes while typing.
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.
The cast operator is also used for implicit conversion.
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.
Since arrays and pointers are equivalent in C/C++ * and -> do work. I agree, though, that accessing the first element via  subscript is preferable.
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.
Fortunately it does 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 ;))
Good to hear. :-) CU, Ingo