Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. General talk
  3. The Lounge
  4. returning size values as int instead of unsigned
Forum Updated to NodeBB v4.3 + New Features

returning size values as int instead of unsigned

Scheduled Pinned Locked Moved The Lounge
documentation uint vs unsignedbytesavailabledocumentation
6 Posts 4 Posters 2.8k Views 4 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • K Offline
    K Offline
    koahnig
    wrote on 8 Jul 2015, 10:50 last edited by
    #1

    Probably more of a philosophical discussion.

    Typically STL uses unsigned int for sizes to be returned by containers. Qt uses a different approach with returning signed numbers (e.g. qint64). bytesAvailable is one example. In general the differences of possible value dfo not play any role anymore. Personally, I appreciate the use of int instead of unsigned, since I tend to use most of the time int values.

    However, at the day's end this leaves some uncertainty of returned values. Number of bytes one would clearly expect a return from 0 to anything above within limits of value definition. Unfortunately this is left open in documentation (e.g. bytesAvailable ). For clarity it would be better to add everywhere where in question.

    Any other thoughts?

    Vote the answer(s) that helped you to solve your issue(s)

    J 1 Reply Last reply 8 Jul 2015, 14:37
    0
    • S Offline
      S Offline
      sierdzio
      Moderators
      wrote on 8 Jul 2015, 12:46 last edited by
      #2

      What are you not certain about? Is qint64 not clear enough?

      Quoting the documentation:

      This type is guaranteed to be 64-bit on all platforms supported by Qt.

      (Z(:^

      K 1 Reply Last reply 8 Jul 2015, 13:53
      0
      • S sierdzio
        8 Jul 2015, 12:46

        What are you not certain about? Is qint64 not clear enough?

        Quoting the documentation:

        This type is guaranteed to be 64-bit on all platforms supported by Qt.

        K Offline
        K Offline
        koahnig
        wrote on 8 Jul 2015, 13:53 last edited by
        #3

        @sierdzio
        That is safe, no question. However, it allows a negative value. That is the point. Certainly, it does not make sense to report number of bytes for instance with a negative number. However, at least theoretically it is possible (e.g. as substitute with a negative number in case of special conditions).

        Therefore, it would be completely unambiguous when there was a statement in the documentation similar to "0 or always greater".

        Vote the answer(s) that helped you to solve your issue(s)

        1 Reply Last reply
        0
        • K koahnig
          8 Jul 2015, 10:50

          Probably more of a philosophical discussion.

          Typically STL uses unsigned int for sizes to be returned by containers. Qt uses a different approach with returning signed numbers (e.g. qint64). bytesAvailable is one example. In general the differences of possible value dfo not play any role anymore. Personally, I appreciate the use of int instead of unsigned, since I tend to use most of the time int values.

          However, at the day's end this leaves some uncertainty of returned values. Number of bytes one would clearly expect a return from 0 to anything above within limits of value definition. Unfortunately this is left open in documentation (e.g. bytesAvailable ). For clarity it would be better to add everywhere where in question.

          Any other thoughts?

          J Offline
          J Offline
          JKSH
          Moderators
          wrote on 8 Jul 2015, 14:37 last edited by
          #4

          @koahnig said:

          Unfortunately this is left open in documentation (e.g. bytesAvailable ). For clarity it would be better to add everywhere where in question.

          That's reasonable. There's always room for improvement. Would you like to submit patches? (I don't think the signed integers are a big issue, so I don't want to pester the documentation team -- let them focus on more important stuff)

          Qt Doc Search for browsers: forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches

          1 Reply Last reply
          0
          • K Offline
            K Offline
            koahnig
            wrote on 8 Jul 2015, 16:22 last edited by
            #5

            @JKSH

            Thanks for response. You hit the point. That is also the reason I have started the discussion here instead of simply filing something on JIRA. The forum's lounge seem to be the better place.

            To formulate a sentence or two for places I come across is probably the easiest part. Since I have not been involved in Qt stuff so far, I am a bit reluctant to state a simple yes. If it is limited to a couple of sentences and one or two emails without having understood the complete process, it would be yes.

            On the other it is basically to get the ambiguity out of documentation and state what most will have to read between lines. However, it might have to be clarified as well, that the obvious is also what is implemented. Again not sure what procedures are in place.

            Vote the answer(s) that helped you to solve your issue(s)

            1 Reply Last reply
            0
            • C Offline
              C Offline
              Chris Kawa
              Lifetime Qt Champion
              wrote on 8 Jul 2015, 17:53 last edited by Chris Kawa 7 Aug 2015, 17:53
              #6

              I don't think the fix for this situation is sprinkling the docs with "is always greater than or equal to 0". I don't really think there is a doubt in someones head about whether or not a size or length function returns negative value no matter if it's unsigned int, qint64 or size_t.
              I think the opposite is more reasonable - document cases where it can actually return negative value and what it means, which Qt docs are doing pretty consistently (correct me if I'm wrong).

              1 Reply Last reply
              0

              1/6

              8 Jul 2015, 10:50

              • Login

              • Login or register to search.
              1 out of 6
              • First post
                1/6
                Last post
              0
              • Categories
              • Recent
              • Tags
              • Popular
              • Users
              • Groups
              • Search
              • Get Qt Extensions
              • Unsolved