Re: [Stlport-devel] delete 'no library' mode?
Brought to you by:
complement
From: Petr O. <pt...@is...> - 2006-01-14 18:12:04
|
On Saturday 14 January 2006 17:18, François Dumont wrote: > > > François, > > > > 'benchmark before adopt'? I disbelieve in this. > > I expect this motive is more like 'lazy and unskilled'. > > > No doubt that this mail is from you :-) Yes, it's me... ;-) > , you are really far from marketing diplomacy... Well, this pleasure on the daily work suffices me. STLport is 'just for fun', so play in marketing games with low level managers (that was never programming good to speak about technology aspects, and don't have sufficient powers to discuss 'can you do it for me?') isn't interesting for me. > > A solution might perhaps be to rename _STLP_NO_IOSTREAMS in something > like _STLP_ONLY_STL as most of the time when I see people saying that > they do not need iostreams it means that they are using only STL > (including string). And STL only mode could be also simplified, that is > to say that this mode should be cleaned to avoid use of any class with > static datas. For instance all node_alloc implementation could be moved > to the src folder, pure STL users would rely on new/delete or > malloc/free one. > > Your opinion ? François, I am suspect that the only argument to detect boundary of 'simplified' ('restricted', etc.) STL is presence or absent of library. Most of men that require 'simplified' STL really don't know what they should do with library---and (often) erroneously expect that rest of functionality (or compatibility with previously compiled libraries) they take from STL from compiler's set. And what we have? We have compromises in performance, design, code size just for men that are out of conceit with STLport in a two days (it don't justified expectations, and can't justify ones indeed). In short, I don't see use cases (except mentioned in beginning of this message) of STLport usage without library (at least static). But, I can imagine platform without filesystem (and files), so skip fstream (in library) for such platforms is a correct way. The same is for locale (even the case 'not really implemented' or 'too hard to implement'). Good luck, - Petr |