[Bug libstdc++/90634] filesystem::path insane memory allocations
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 forward iterators or bidirectional iterators. Indeed! Ability to run a modifying algorithm on a path's elements is extremely useful. Sorting path's components makes a lot of practical sense. So does std::random_shuffle them. And ability to heapify them (std::make_heap) is basically unavoidable in any app, which has to deal with filesystem::path. But what weirdo would want to store hundreds of thousands of paths without x10 memory overhead, right? So i agree. Just screw the C++ standard and do what you think is best for ppl out there. Thanks for your great work!
[Bug libstdc++/90634] filesystem::path insane memory allocations
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++ standard at least. So, long story short: "I am not going to fix the x10 overhead, because I believe the standard is wrong." Ok. But damn! how good clang looks on the same test: about to quit. total allocated 0 bytes
[Bug libstdc++/90634] filesystem::path insane memory allocations
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 system is here for a reason. And it has advantages to type something, which is naturally a path, as such, not as an arbitrary string. > GCC's implementation creates the path components eagerly, so that > path::iterator meets the requirements of a forward iterator, whereas the > libc++ implementation creates them lazily during iteration, and so is not a > valid forward iterator. It doesn't have to be. See standard 30.11.7.5: A path::iterator is a constant iterator satisfying all the requirements of a bidirectional iterator (27.2.6) except that, for dereferenceable iterators a and b of type path::iterator with a == b, there is no requirement that *a and *b are bound to the same object. Its value_type is path. > The implementations have different trade-offs. That is not a bug. Poorly considered trade-offs are called "bad design" ;) Besides, your implementation breaks the fundamental C++ design principle "you don't pay for what you don't use". now everyone has to pay x10 memory overhead even if they are not ever going to iterate over a path object. I agree, that is not a bug, in C++ world, its a pure crime ;)
[Bug libstdc++/90634] filesystem::path insane memory allocations
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 folder on my machine and save all the found paths to vector, it takes 2.7GB, while should take ~150MB!! quite an overhead on a simple task, for a language which strives for efficiency. check out clang, for example: https://wandbox.org/permlink/u9dEfPh1Zc5pmJ34 it's smart enough to allocate such short strings inplace: about to quit. total allocated 0 bytes
[Bug libstdc++/90634] filesystem::path insane memory allocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90634 baltic <1000hz.radiowave at gmail dot com> changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED |--- --- Comment #3 from baltic <1000hz.radiowave at gmail dot com> --- (In reply to Jonathan Wakely from comment #2) > I'm not sure where the repeated 72 allocations come from, and can't check > the code right now, but the new code doesn't do it anyway. It comes from std::string creation, which then is passed to path constructor. > I think this can be considered fixed. hardly. the gcc 9.1 is even worse in that regard, as it allocates 2kB of memory for the same case see the line: about to quit. total allocated 2131 bytes in here: https://wandbox.org/permlink/u9dEfPh1Zc5pmJ34
[Bug libstdc++/90634] New: filesystem::path insane memory allocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90634
Bug ID: 90634
Summary: filesystem::path insane memory allocations
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: 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 unusable to store a lot of paths, while crawling through a
filesystem for example.
see the small test program:
#include
#include
#include
#include
using namespace std;
using namespace std::filesystem;
size_t total = 0;
// replace operator new and delete to log allocations
void* operator new(size_t n) {
cout << "allocating " << n << " bytes" << endl;
size_t *p = (size_t*) malloc(n + sizeof(size_t));
*p++ = n;
total += n;
return p;
}
void operator delete(void* p) throw() {
size_t *sp = (size_t *) p;
cout << "freed " << *--sp << " bytes" << endl;
total -= *sp;
free(sp);
}
int main() {
path p("/test/test/test/test");
cout << "about to quit. total allocated " << total << " bytes" << endl;
return 0;
}
the output is:
allocating 21 bytes
allocating 72 bytes
allocating 144 bytes
freed 72 bytes
allocating 288 bytes
allocating 72 bytes
freed 144 bytes
allocating 576 bytes
allocating 72 bytes
allocating 72 bytes
allocating 72 bytes
freed 72 bytes
freed 288 bytes
about to quit. total allocated 813 bytes
[Bug libstdc++/89065] set::find always returns const iterator
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 value type is the same as the key type, both iterator and const_iterator are constant iterators. Weird though. I think this could be closed as invalid. Thanks!
[Bug libstdc++/89065] New: set::find always returns const iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89065
Bug ID: 89065
Summary: set::find always returns const iterator
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: 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 return const iterator even on non const object.
Consider the example:
#include
#include
struct FatKey { int x; int ref_count; };
bool operator<(const FatKey& fk1, const FatKey& fk2) { return fk1.x < fk2.x; }
int main()
{
std::set example = { {1, 0 }, {2, 0 }, {3, 0 }, {4, 0 } };
auto search = example.find({1, 0});
if (search != example.end()) {
search->ref_count++;
std::cout << "Found " << search->x << '\n';
} else {
std::cout << "Not found\n";
}
}
It fails to compile with the error:
main.cpp: In function 'int main()':
main.cpp:11:26: error: increment of member 'FatKey::ref_count' in read-only
object
search->ref_count++;
While it shouldn't.
[Bug c++/56926] Crash (without ICE) while compiling Boost.Math
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 than. Now 4.6 version of MinGW-64 doesn't work with the PCH's full of Qt headers either.
[Bug c++/56926] Crash (without ICE) while compiling Boost.Math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926 baltic 1000hz.radiowave at gmail dot com changed: What|Removed |Added CC||1000hz.radiowave at gmail dot com --- Comment #5 from baltic 1000hz.radiowave at gmail dot com --- Experience the same while trying to build a project with massive amounts of Qt headers in a pch. Happens with mingw64 builds for versions 4.8.0 4.8.1 and 4.8.2 Can upload the pch, if needed. worked fine with 4.6
