Project

General

Profile

Actions

Support Request #4008

closed

EBPRODUCTSUPPORT-1226 Different behavior of the ADTF File Lib between Windows and Linux

Added by hidden almost 6 years ago. Updated almost 6 years ago.

Status:
Closed
Priority:
Normal
Customer:
ELEKTROBIT
Department:
SUPPORT
Requester's Priority:
Normal
Support Level:
2nd Level
Resolution:
Solved Issue
Product Issue Numbers:
Platform:
Ubuntu 16.04 64bit, Windows 7 64bit
Topic:
FileLibrary::Reader
FAQ Links:

Description

Support Anfrage:

das Verhalten beim Iterieren über die Stream Properties ist nicht stabil zwischen Windows und Linux (innerhalb eines Systems schon, also bei mehrfachen ausführen auf Windows oder Linux). Ich erhalte in Linux eine komplette umsortierte Liste.
Ist das so gewollt? Für meine Anwendung ist das kein Problem, allerdings ist es unerwartet.

Ausgabe unter Windows:

[Dump ] - Stream: Motor
id: 1
item/sample count:1461
timestamp (first, nano seconds): 45071342000
timestamp (last, nano seconds): 59715166000
metatype: adtf2/legacy
stream property count: 3
- Stream property name: major
value: 768
type: tInt32
- Stream property name: sub
value: 0
type: tInt32
- Stream property name: flags
value: 0
type: tInt32

Ausgabe unter Linux:

[Dump ] - Stream: Motor
id: 1
item/sample count: 1461
timestamp (first, nano seconds): 45071342000
timestamp (last, nano seconds): 59715166000
metatype: adtf2/legacy
stream property count: 3
- Stream property name: sub
value: 0
type: tInt32
- Stream property name: flags
value: 0
type: tInt32
- Stream property name: major
value: 768
type: tInt32

Lösung:

class DefaultStreamType: public PropertyStreamType, public StreamType
{
    ...
    private:
    ...
        std::unordered_map<std::string, std::pair<std::string, std::string>> _properties;
};

Da dürfte wohl die Implementierung der unordered_map unter MSVC einfach anders hashen und sortieren als die des GCC. Das ist eben eine unordered_map, weil die Reihenfolge bei Properties keine Rolle spielt.

Actions

Also available in: Atom PDF