We write science data processing software 
(github.com/bluequartzsoftware/dream3d) and there have been more than a few 
times where we load up past 32 bit signed int number of elements in an array. 
We are adding out-of-core to our software now which means we are definitely 
going past signed 32 bit indexes. We rewrote our core software library to 
remove any Qt codes from them so that we can have this kind of access using 
std::* containers.

My guess is that if you are NOT in the data processing realm the Qt containers 
are probably just fine for your use cases. If you need something more you have 
already made the changes necessary to move your code forward. 
Std::shared_ptr<std::vector<T>> also works well to pass around data as does the 
usual "const ref" passing which helps you keep ownership figured out.

Just my 2 cents.

--
Mike Jackson


On 9/5/22, 13:56, "Interest on behalf of A. Pönitz" 
<interest-boun...@qt-project.org on behalf of apoen...@t-online.de> wrote:


    Hi all.

    In order to base my potential arguments in a certain discussion on a
    neighboring list not purely just on my own experience with both Qt and
    (independently) large data (a.k.a. "gut feeling") I would appreciate
    if /you/ could help me to find a - very rough, readily admitted in
    advance to be completely unscientific - estimation for an answer to
    the following question:

      How often do people /need/ /Qt/ containers with /more than
      1 billion elements/ ? 

    The question is really meant as conjunction, i.e. I'd like to count
    only setups meeting both criteria at the same time:

       1. /Some/ relevant data set is really > 1e9 entries,

       2. It really needs to be a /Qt/ container because of some Qt container
          feature (e.g. reference counting or e.g. because of Q(5)List's
          "indirect" storage etc) that a std:: container does not offer
          out-of-the-box and it /needs/ to be like that, i.e. there is no
          simple / straightforward replacement like using std::*, and
          benefits do not exceed drawbacks like more expensive write
          access.

    Problems meeting only one of the two criteria won't count, but I'd
    accept "Would have needed in the past, but since Qt < 6 didn't offer
    it I had to go through big trouble and create a hand-crafted solution"
    ;-)

    In case of proprietary/personal/otherwise non-disclosable examples
    I'd be happy enough to get a private mail. In any case: Any feedback
    is appreciated.

    Andre'
    _______________________________________________
    Interest mailing list
    Interest@qt-project.org
    https://lists.qt-project.org/listinfo/interest


_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Reply via email to