llvm dev - Aug 2009 - [LLVMdev] std::cout << *MyModule does not work anymore

Daniel Dunbar <daniel at zuster.org> writes:

[snip]
>> Is all this an unintended change or an intentional one, and if the
>> later, could you direct me to something that explains what we gain on
>> exchange of this restriction?
>
> Intentional. std::ostream has long been deprecated in LLVM, each
> release has increased the degree of deprecation. The coding standards
> document has various bits of information on this
> http://llvm.org/docs/CodingStandards.html.
>
> Among other things, you gain performance. raw_ostream is considerably
> faster than std::ostream. This is the performance difference on the my
> synthetic raw_ostream benchmark:
[snip]

First of all, thanks to Daniel for the answer to my questions.

To the LLVM library designers:

Okay, so your wheel is lighter and faster. Sometimes this is a good
justification for reinventing the wheel when everybody is eager to throw
away the old wheels and use yours instead :-). However, when LLVM is
just another library on an application (something that I hope often
happens thanks to the great JIT it provides) having to learn the quirks
and kinks of something that pretends to replace a common functionality
of the language's standard library *plus* integrating it into the
existing code can be a real burden. Maybe the LLVM ostream replacement
knows how to handle LLVM objects, but it certainly knows nothing about
how to deal with user's objects and this may create quite a bit of work
when you have a mixed series of output statements with both kinds of
objects.

Maybe there was a solution that was okay for those concerned with fast &
lightweight executables and for the others who care most about
consistency and code stability. I would appreciate if this changes are
discussed before applying them on the future (maybe I missed the
thread), flagging the subject with something that indicates that the
outcome of the discussion may break existing code.

Thanks for your mostly excellent work on LLVM's design and policy-making
;-)

-- 
Óscar

On Aug 24, 2009, at 8:04 PM, Óscar Fuentes wrote:
> However, when LLVM is
> just another library on an application (something that I hope often
> happens thanks to the great JIT it provides) having to learn the  
> quirks
> and kinks of something that pretends to replace a common functionality
> of the language's standard library *plus* integrating it into the
> existing code can be a real burden.
Right, this is exactly why we have raw_os_ostream.  If you have an  
std::ostream, you can can make LLVM output to it by using  
raw_os_ostream.  This way you get the internal performance wins in  
llvm plus the compatibility with std::ostream.  Bonus, it should  
faster than writing to std::ostream directly.
> Maybe there was a solution that was okay for those concerned with  
> fast &
> lightweight executables and for the others who care most about
> consistency and code stability. I would appreciate if this changes are
> discussed before applying them on the future (maybe I missed the
> thread), flagging the subject with something that indicates that the
> outcome of the discussion may break existing code.
raw_ostream has been a long time coming, it was started in 2008-08-16  
18:35:29.  The coding standards doc has *long* had wording that  
<iostream> (in particular) is evil.

-Chris

Hi Óscar,
> Maybe there was a solution that was okay for those concerned with fast
&
> lightweight executables and for the others who care most about
> consistency and code stability. I would appreciate if this changes are
> discussed before applying them on the future (maybe I missed the
> thread), flagging the subject with something that indicates that the
> outcome of the discussion may break existing code.
hopefully the 2.6 release notes will mention these changes and how
to handle them (I don't think anyone added anything yet though).

Ciao,

Duncan.

On Aug 25, 2009, at 12:25 AM, Duncan Sands wrote:
>
> hopefully the 2.6 release notes will mention these changes and how
> to handle them (I don't think anyone added anything yet though).
FWIW, the changes under discussion here are on trunk and not 2.6.

Dan