2

Starting with a more advanced C++ course, we have to implement an own Matrix, which is typical for first exercises. We received a skeleton to work on and i have got only one question left. The type of the access and size variables.

Here a simple constructor for 1D Matrix, with some Checking of the size.

Array::Array( int xSize )                                                                                     
{                   
    CHECK_MSG(xSize > 0, "Array size too small");
    array_ = new real[xSize];
    size_ = xSize;  
}

Does it make sense to use a size_t or unsigned int instead of an int? After reading the definition of size_t i would tend to use it instead. However in many codes i see just ints everywhere. Is it a java-like coding style? Has size_t any disadvantages i missed?

Edit:

The main question relates to the coding style. I fully understand the difference of size_t and (unsigned) int, as it was already explained here:unsigned-int-vs-size-t

Community
  • 1
  • 1
hr0m
  • 2,643
  • 5
  • 28
  • 39
  • 3
    Possible duplicate of [unsigned int vs. size\_t](http://stackoverflow.com/questions/131803/unsigned-int-vs-size-t) – cadaniluk Oct 21 '15 at 10:57
  • Using `int` is fine, unless you have some specific requirements. On a 64-bit system `std::size_t` is usually larger, which can be both an advantage (wanna create the world's largest matrix?) and a disadvantage (uses more cache space). – Bo Persson Oct 21 '15 at 11:29
  • Not a duplicate. I rather ask about the coding style, since i have also seen "never use unsigned int" type of styles. – hr0m Oct 21 '15 at 11:34

2 Answers2

1

The C++ standard library would almost certainly use a std::size_t for such a type.

Using a signed type is obviously not desirable and, ideally, you want to use a type that lends itself well to having an object that supports iterability.

From the outset I recommend you use typedef std::size_t MySize; within your class, mainly to future-proof yourself. That would be the most sensible choice.

Bathsheba
  • 231,907
  • 34
  • 361
  • 483
  • 7
    `using size_type = std::size_t;` would be closer to what stdlib has; also, I think it's past time to deprecate `typedef` :) – Bartek Banachewicz Oct 21 '15 at 11:02
  • Perhaps I'm an old fuddy-duddy cat but I *love* `typedef`. – Bathsheba Oct 21 '15 at 11:05
  • Sure why that `MySize` instead of common `size_type`? – Lol4t0 Oct 21 '15 at 11:05
  • In case you realise in the future that you don't want as many elements as `size_type` could give you. – Bathsheba Oct 21 '15 at 11:06
  • 5
    FWIW, in some talk (CppCon 2014 I believe) several committee members said that using unsigned integer types in the standard library was a mistake. I can look it up later today if people are interested. – Baum mit Augen Oct 21 '15 at 11:10
  • 2
    You... what? It's just about the naming. And my gripe with `typedef` is that now we have two ways to do the same thing (namely `typedef` and `using`) and one is strictly better than the other, so I don't see a reason to keep using the old one. – Bartek Banachewicz Oct 21 '15 at 11:10
  • @BaummitAugen: that would be interesting: I don't get it though. Why would you want a negative size? – Bathsheba Oct 21 '15 at 11:12
  • The thing is that you don't want mixed signed and unsigned computations. One way to avoid this is by not using unsigned types. – Bo Persson Oct 21 '15 at 11:18
  • Better ditch floating point or integers for the same reason. (This obdurate behaviour of mine is why I don't get invited to these conferences). – Bathsheba Oct 21 '15 at 11:20
  • 2
    @Bathsheba [This](https://channel9.msdn.com/Events/GoingNative/2013/Interactive-Panel-Ask-Us-Anything) panel. 9:50, 1:02:50 and I think on a third occurrence I cannot find right now. – Baum mit Augen Oct 21 '15 at 11:36
  • This comments are actually exactly what i expected. They sum up the different c++ coding styles, as people come from java/c or like old/new features. – hr0m Oct 21 '15 at 11:39
  • 1
    @Bathsheba Also 42:40. – Baum mit Augen Oct 21 '15 at 11:42
  • @Bathsheba One reason, I would image, is that using a signed type for size, allows you to use the same type for size difference which has its merits I believe. – luk32 Oct 21 '15 at 11:53
  • Indeed unsigned types are not closed under subtraction. But then integral types are not closed under division (unless you specify that division truncates). And then floating points are not closed under square root etc. You need complex types for full closure of everything! Where do you draw the line? I'm of the ilk that you always pick the type most appropriate to your requirements. In this particular case, that's an unsigned integral something. – Bathsheba Oct 21 '15 at 12:04
  • consider a bounds check like `if ( index -1 < 0) fail`. If `index` is unsigned the check (without any warning) will always be false. The problem is not unsigneds not being closed under subtraction; actually they are: unsinged X's denote the Ring Z/(2^sizeof(X)). It's the implicit wraparound (at 0) behaviour that often leads to confusion. – johannes_lalala Feb 10 '20 at 10:22
0

Can the size of anything ever be negative? No, so use unsigned for xSize to express the intent of the code more explicitly.

If you need it be able to handle really big sizes, use size_t.

Emil Laine
  • 41,598
  • 9
  • 101
  • 157
  • Quantities in C should be signed, even when they cannot be negative, except when they can either fit in an unsigned type *smaller than `int`*, or they may plausibly exceed the maximum value for a signed type but cannot plausibly exceed the maximum for its corresponding unsigned type. In 16-bit C implementations, objects could be larger than 32767 bytes but not larger than 65535 bytes, so the range benefit of "unsigned" made that type reasonably appropriate even though unsigned math is performed in ways that aren't really suitable for quantities. – supercat Jun 29 '16 at 23:11