[haiku-commits] Re: BRANCH midar-github.master - headers/os/support

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Tue, 20 Nov 2012 20:49:55 +0100

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 [0] 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


Other related posts: