[LLVMdev] std::cout << *MyModule does not work anymore

[Óscar Fuentes]

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