| comp.lang.c++@googlegroups.com | Google Groups |  |
| Unsure why you received this message? You previously subscribed to digests from this group, but we haven't been sending them for a while. We fixed that, but if you don't want to get these messages, send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
- size of std::istream object - 2 Updates
- Any tools for "refactoring" C++ code? - 1 Update
| "Öö Tiib" <ootiib@hot.ee>: Nov 16 02:34PM -0800 On Sunday, 16 November 2014 21:19:13 UTC+2, Mark wrote: > std::istream &stream = readerObj.stream () ; > std::stringstream str; > str << stream.rdbuf() ; You copy everything from stream to stream? > I'd like to determine the size of the istream object before extraction with > rdbuf(). How can I achieve this. You can't. There can be 'istream' whose size is not constant. For example it can be some fifo or pipe that other application is writing into from other side. So if the size matters then you have to read block by block. At positive side '.read()' (or '.readsome()') and '.write()' cycles are usually better performing than those copies. |
| Mark <ma740988@gmail.com>: Nov 16 02:55PM -0800 On Sunday, November 16, 2014 5:34:28 PM UTC-5, Öö Tiib wrote: > other side. So if the size matters then you have to read block by block. > At positive side '.read()' (or '.readsome()') and '.write()' cycles are > usually better performing than those copies. Thanks a lot. I switched over to usignt the read method unsigned int const MAX_SIZE_SUPPORTED ( 10485760 ); typedef boost::shared_array < char > BOOST_SHARED_CHAR_ARRAY ; BOOST_SHARED_CHAR_ARRAY ptrBase64Data ; ptrBase64Data.reset ( new char [ MAX_SIZE_SUPPORTED ] ) ; std::istream &stream = readerObj.stream () ; unsigned int offset ( 0 ); unsigned int const payload ( 1048576 ); do { std::streamsize const xxx = stream.read ( &ptrBase64Data [ offset ], payload ).gcount() ; offset += xxx ; //to offset against MAX_SIZE_SUPPORTED so we don't crash } while ( !stream.good() ) ; Mark |
| "Öö Tiib" <ootiib@hot.ee>: Nov 16 01:59PM -0800 On Sunday, 16 November 2014 20:50:35 UTC+2, David Thornley wrote: > > from that. > On the other hand, some code bases are large enough that going through > and doing everything yourself is going to take a while. It is quite likely going to take a while anyway. Regardless if refactoring is done manually or with a tool we need retesting and fixing. Something always breaks with refactoring. If the code-base is not small ... say 300 000 lines of code then it may even take some man months to make it to work again. If you only to moderately modernize the classes that you have to maintain anyway (because of defect fix or improvement needed) then that is not too large work even when whole code base is large. > and those I suppose you can just add as you modify things, like the > new for loop and "auto". I don't see any strong reason to go through > and convert "boost::shared_ptr" to "std::shared_ptr". Several families of smart pointers side-by-side will always cause quirks. *If* to replace those ('shared_ptr'/'weak_ptr') at all then better in whole code-base. 'std::unique_ptr' is the best smart pointer. It is better than 'boost::scoped_ptr' and it cooperates somewhat with 'std::shared_ptr'. Lot of 'shared_ptr' usages were actually where 'unique_ptr' is more appropriate (and far more efficient). So if to review 'shared_ptr' usages anyway then it is little work to replace it with 'std' version. > (when used as the null pointer constant) to "nullptr" might chase out > a few. I'm not real sure about "unique_ptr" vs. "auto_ptr", but > you might be able to get around that with a global replace. The 'auto_ptr' was quite confusing to people. On most cases when I used it (as performance optimization) some other maintainer later misunderstood what is going on. So it is good idea to hunt out all 'auto_ptr' if there are any left. Likely there aren't many. > Some of them might improve performance. Besides just compiling with > a modern compiler (which will bring in the better library), you might > add move constructors and assignment operators to your classes. Better is to try first to rewrite the classes in a way that compiler-generated copy and move will do the right thing. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment