[Bug libstdc++/90634] filesystem::path insane memory allocations

2019-05-30 Thread 1000hz.radiowave at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90634 --- Comment #15 from baltic <1000hz.radiowave at gmail dot com> --- (In reply to Jonathan Wakely from comment #14) > It's true that the standard does not require path::iterator to be usable in > generic algorithms that expect forwa

[Bug libstdc++/90634] filesystem::path insane memory allocations

2019-05-28 Thread 1000hz.radiowave at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90634 --- Comment #9 from baltic <1000hz.radiowave at gmail dot com> --- (In reply to Jonathan Wakely from comment #8) > The libc++ implementation also fails this test: As i've shown before, neither of those are failures. By the current C++

[Bug libstdc++/90634] filesystem::path insane memory allocations

2019-05-27 Thread 1000hz.radiowave at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90634 --- Comment #7 from baltic <1000hz.radiowave at gmail dot com> --- (In reply to Jonathan Wakely from comment #5) > So don't store them as filesystem::path objects then, store them as strings > and create a path as needed. Type sy

[Bug libstdc++/90634] filesystem::path insane memory allocations

2019-05-26 Thread 1000hz.radiowave at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90634 --- Comment #4 from baltic <1000hz.radiowave at gmail dot com> --- besides the 269 bytes you have mentioned, is still x10 overhead for a 20 chars string. and massively adds up, if you store a lot objects. for example, when i go around home

[Bug libstdc++/90634] filesystem::path insane memory allocations

2019-05-26 Thread 1000hz.radiowave at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90634 baltic <1000hz.radiowave at gmail dot com> changed: What|Removed |Added Status|RESOLVED|UNCON

[Bug libstdc++/90634] New: filesystem::path insane memory allocations

2019-05-25 Thread 1000hz.radiowave at gmail dot com
: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: 1000hz.radiowave at gmail dot com Target Milestone: --- std::filesystem::path allocates insane amounts of memory, even for short paths. for example, for a 20 bytes path it allocates 813 bytes. which makes it practically

[Bug libstdc++/89065] set::find always returns const iterator

2019-01-25 Thread 1000hz.radiowave at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89065 --- Comment #2 from baltic <1000hz.radiowave at gmail dot com> --- Ok, i see 26.2.6.6 section of the standard: iterator of an associative container is of the bidirectional iterator category. For associative containers where the valu

[Bug libstdc++/89065] New: set::find always returns const iterator

2019-01-25 Thread 1000hz.radiowave at gmail dot com
: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: 1000hz.radiowave at gmail dot com Target Milestone: --- by the standard there are 2 overloads of find: iterator find( const Key& key ); const_iterator find( const Key& key ) const; However, libstdc++ seem to retu

[Bug c++/56926] Crash (without ICE) while compiling Boost.Math

2013-12-28 Thread 1000hz.radiowave at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926 --- Comment #7 from baltic 1000hz.radiowave at gmail dot com --- (In reply to baltic from comment #5) worked fine with 4.6 This is not true anymore :) was probably working fine with previous versions of the Qt, because headers were smaller back

[Bug c++/56926] Crash (without ICE) while compiling Boost.Math

2013-12-27 Thread 1000hz.radiowave at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926 baltic 1000hz.radiowave at gmail dot com changed: What|Removed |Added CC