|Re: [eigen] An insistent plea for an input operator|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] An insistent plea for an input operator
- From: Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>
- Date: Tue, 20 Jul 2010 17:26:23 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=RixPqbZ5sk4En4QbB1GwrkkF3SjlaMnG3KC3SZ676EA=; b=r21SvOGcMfwehOKDYz3UzY489GsE8cYgXoEbbzdesFCEQTGzDA/F/sLF9w66cpMufl yrMk6rvAGblpNv+/EwgC5vZZC+9bXPNdO1nF+ijYSiVTO8wxnL8+1CvTfrWN6xwdQE6h uzwYp6ztszxwksUEeBSqcGLO7D2bwlPk6Q/gM=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Cg4SJDPVkchL20oh9FTQGGa9yJGpzNN1VBG+BXzzclFX/LKDDc9US/WFyx3Qltzrzf kWxsAf3bbmPLHmpM3Ud/jWEkd6kdCaXr2PTRnDtOSgUGkS3NPsiBmMDn3g1CwN6jmXiT 0MkAwGTLhAbdHl3CPyOlJ1Z9CRgdFpdQk23NQ=
On Tue, Jul 20, 2010 at 5:14 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> 2010/7/20 Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>:
>>> Sure! How is this a problem?
>> Not really but somebody might think hey, it accepts input from
>> std::cin in the form of
>> 1 2 3
>> 4 5 6
>> why not from a text file... I admit, we can easily deal with that. I
>> was more like brainstorming. ;)
> Just for the record: I don't see how allowing reading from a text file
> is a drawback, I see it as a feature :-)
Of course it is! But not if it does not work even though it compiles.
I requires a different method.
Your other proposal sound fine to me as long as its fine for the user.
I was actually hoping for something as the standard library does. You
know, there are these modifiers. I don't recall perfectly, but they
somehow look like this
std::cout << std::ios_base::hex << 10 << std::endl;
or then with Eigen types like this
std::cout << Eigen::Format(...) << m;
std::cin >> Eigen::Format(...) >> m;
I would like this a lot since it were following the standard approach
but the other one is fine too.