Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #68002

Re: Weird use of maps.

Show all headers | View raw

On 8/29/19 4:24 AM, David Brown wrote:
> On 29/08/2019 02:58, James Kuyper wrote:
...
>> The part numbers are sequential in the order that the parts should occur
>> in. They are sent out sequentially, but in general, they don't arrive
>> sequentially. They are 1-based, not 0-based.
> 
> I would expect that while the parts /could/ arrive out of order, they
> will come mostly roughly in-order.

That was my expectation, too. Reality didn't cooperate. During
debugging, I never saw the parts arrive in strict sequential order, and
they often arrived completely jumbled. Sometimes, for small messages,
the final part would be the first one to arrive.

That triggered another bug, but I've simplified my explanation of the
code too much to explain why without adding a lot more details. Suffice
it to say that the author apparently expected the final part to always
be the one that arrived last - despite the fact that, if the parts were
guaranteed to arrive in order, he could have simply appended each part
to a string containing the parts that had already been received. That
bug didn't puzzle me as much as the other issues I've mentioned, which
is why I didn't mention it.

> Since you know how many parts you will get (once you have received one
> part), and you know the part numbers are all 1 .. n, it seems strange to
> me that you have a map at all.  I'd expect to use a vector,
> pre-allocated to the right size when the first part of a new message
> arrives.  Perhaps you'd want the vector elements to be optional<string>,
> or just have empty strings for parts that haven't yet arrived.  You
> might also want to track a counter of "parts waiting" so that you can
> easily see that the last part has arrived, without running through the
> vector.

I thought about the vector approach, but with the map approach, the
size() member serves as parts_received, and the total count of parts is
received with every part, so parts_waiting is just the difference. With
the vector approach I'd have to keep track of one additional quantity
(either parts_received, as I thought, or parts_waiting, per your
suggestion). That adds just a little additional complexity, but enough
to discourage me from using that approach.
...
> There are other possibilities for this odd data structure - other than
> stupidity or inexperience.  It could be that the requirements or planned
> handling system changed underway - maybe the parts had a different
> identification system originally rather than simple integers.  It could
> be that the code was prototyped in a more dynamic language, such as
> Python, or at least one where "variant" types are more common, such as

That's plausible - some parts of this project are written in python.

...
>> Agreed - the messages are provided by users, and therefore don't arrive
>> frequently enough for the inefficiency of this approach to be a
>> significant problem. The inefficiency bothers me, but my boss wouldn't
>> have let me work on something this low in priority if I weren't
>> currently stuck between a project I've finished and a project I'm not
>> allowed to start work on (we're waiting for approval from the client).
>>
> 
> Inefficiency is often not a huge problem - incorrectness is.

The code is incorrect, but cases which trigger the bug are extremely
unlikely. With the inefficiency being small, and the incorrectness
unlikely, this is justifiably a low-priority bug. I definitely have more
important things to work on as soon as the work gets approved (I was
investigating one of those more important things when I found this bug).

Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Weird use of maps. James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-08-28 09:30 -0400
  Re: Weird use of maps. Jens Kallup <jkallup@web.de> - 2019-08-28 16:22 +0200
    Re: Weird use of maps. James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-08-28 20:46 -0400
  Re: Weird use of maps. Öö Tiib <ootiib@hot.ee> - 2019-08-28 09:00 -0700
    Re: Weird use of maps. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-08-28 14:54 -0700
    Re: Weird use of maps. James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-08-28 20:58 -0400
      Re: Weird use of maps. David Brown <david.brown@hesbynett.no> - 2019-08-29 10:24 +0200
        Re: Weird use of maps. James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-08-29 10:05 -0400
  Re: Weird use of maps. Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2019-08-28 19:19 +0100
    Re: Weird use of maps. James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-08-28 21:05 -0400
  Re: Weird use of maps. usenet@stegropa.de (Stefan Große Pawig) - 2019-08-28 20:22 +0200
    Re: Weird use of maps. James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-08-28 21:08 -0400
    Re: Weird use of maps. James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-08-28 21:16 -0400
      Re: Weird use of maps. usenet@stegropa.de (Stefan Große Pawig) - 2019-08-29 20:14 +0200
        Re: Weird use of maps. James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-08-29 20:14 -0400
          Re: Weird use of maps. David Brown <david.brown@hesbynett.no> - 2019-08-30 08:28 +0200
            Re: Weird use of maps. Öö Tiib <ootiib@hot.ee> - 2019-08-30 00:15 -0700
          Re: Weird use of maps. Manfred <noname@add.invalid> - 2019-09-13 17:49 +0200
            Re: Weird use of maps. James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-09-13 15:04 -0400
  Re: Weird use of maps. Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-08-28 19:33 +0000
    Re: Weird use of maps. James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-08-28 21:11 -0400

csiph-web