On Wed, Aug 28, 2013 at 4:02 PM, Roy Stogner <[email protected]>wrote:
> > I'm seeing the "1tdout.processor." behavior with libstdc++ from gcc > 4.8. > > On Wed, Aug 28, 2013 at 3:05 PM, Manav Bhatia <[email protected] >>> >wrote: >>> >>> Not sure why it is not behaving correctly with the filename passed >>>> throught >>>> the constructor. >>>> >>> > On Wed, Aug 28, 2013 at 5:18 PM, John Peterson <[email protected]> >> wrote: >> >> but I admit I don't know where the next input is supposed to occur when >>> you use this constructor. What compiler/OS are you using? >>> >> > Warning: amateur C++ standards-lawyering follows. > > On first glance (at draft n3337): > > A basic_ostringstream constructor from string is supposed to construct > its underlying basic_stringbuf from that string. > > That in turn is supposed to have the same effect as constructing an > empty stringbuf and then calling str(s). > > And that in turn is supposed to have the postcondition: "pbase() > points to the first underlying character"; i.e. the internal pointer > starts out at the *beginning* of the initialization string, not the > end. > > > So I think the "bug" we're seeing is actually our prior > misunderstanding of mandatory stringstream behavior. Thanks for the > catch and the fix, Manav! > Agreed. Would using a std::istringstream instead also fix the problem? -- John ------------------------------------------------------------------------------ Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
