On Thu, Nov 29, 2001 at 11:20:17PM +0100, Martin v. Loewis wrote: > > Well, the problem isn't so much with glibc anymore, since 3.0 doesn't use > > bits and pieces of glibc for I/O like we did in 2.x. (Not even on Linux.) > > That exactly is the problem. If stdio and iostreams were still > integrated, performance would be ok even if they are synchronized.
Oh, I see your point. I thought we were discussing something slightly different. > I think it is desirable to restore a state where they are. The HOWTO > answer you cite is misleading: It suggests that there is no better > solution than to require every application to avoid stdio. This is not > true. I don't believe it suggests that at all. And yes, there are better solutions, but most of them are not available to the casual programmer. The really good solutions must be done within the library. > IMHO, it is also bad advice: stdio is perfect for many > applications. There is nothing wrong with using it in C++, too, and > even together with iostreams. It is sync_with_stdio that is the hack. Nor do I believe that the HOWTO suggests that stdio is bad. It states one thing only: if a C++ program is not making use of stdio, then call sync_with_stdio to disable the (unnecessary) synchronization. If stdio is in use, then the synchronization becomes necessary. > Considering > > http://gcc.gnu.org/onlinedocs/libstdc++/explanations.html#cstdio > > perhaps Debian should use --enable-cstdio to build GCC 3? http://gcc.gnu.org/onlinedocs/libstdc++/configopts.html --enable-cstdio=stdio is the default already, since before 3.0. --enable-cstdio=libio will use pieces from glibc, and will break miserably because nobody has come up with a solution to the threading issues yet. Phil -- If ye love wealth greater than liberty, the tranquility of servitude greater than the animating contest for freedom, go home and leave us in peace. We seek not your counsel, nor your arms. Crouch down and lick the hand that feeds you; and may posterity forget that ye were our countrymen. - Samuel Adams
