Re: [eigen] An insistent plea for an input operator |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] An insistent plea for an input operator
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Tue, 20 Jul 2010 11:14:41 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=mZrUhvq4LX4wb7TpRFAJWsRdbimK9lccKAIo4PJ4PgM=; b=uBxe+CNR11lVP8rhIP5MHC9FhM/KTRqjOThVyVpjbSg1yzhhG234/YI5BIla0XlqTm ChkEE5j7dA0iEOLWkGErXA/92EPvrW/s8mkWrzmKzz7BjJ9J7Dby3Nkt5XANTgNjqL0D kXU58hh087Irkutzbpw7BecmuC5sWYLLuJC9M=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=n9wFZ6IbkkqdrRNiGeDI59gf0ay/+9U+R/2d1ZYua7gj7HoX9U5HsHA0st2EBBQuu7 0Hs6WQmtJukWJiXHqBbHqhoTt91gGX80bowf/8DgnLNnWjeDRtRXz4q6Ke32jsI4QzDg ubHFdpalc5QtMAB7wNWJEMes8R3nc4aFzPZIg=
2010/7/20 Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>:
> On Tue, Jul 20, 2010 at 4:51 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>> 2010/7/20 Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>:
>>> I am not a big fan of this mainly due to safety reasons and
>>> consistency reasons.
>>>
>>> Currently, you can even use an ifstream since it is an istream.
>>
>> 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 :-)
>
>>
>>> We
>>> also need to deal with the way in which the data is given. Why should
>>> it be given as 1 2 3 4 ... and not 1,2,3,4
>>
>> I think the whole point is that just because we support 1 2 3 4
>> doesn't prevent us from supporting other formats too. We can accept
>> multiple formats and for the general solution (in the future) I would
>> like input to support any Eigen::IOFormat, just like output does. But
>> even then, I don't see how it could be a problem that we support the
>> very simple default format 1 2 3 4 ?
>
> I just can't see right now how we can use Eigen::IOFormat while
> keeping the suggested API. We need something like a class providing
> several static operator>> functions taking different parameters or
> such. I don't doubt that this is doable, I am just wondering whether
> we might be quickly introduce API breaks.
Why not do just like we do for output?
Output works like this:
cout << matrix.format(myIOFormat);
format returns a WithFormat proxy object. So the operator<< is taking
a const WithFormat&.
Why not define a operator>> taking a WithFormat& ? So the API would be:
cin >> matrix.format(myIOFormat);
>
>>> For me, the inclusion of such an operator must at least be optional,
>>> i.e. not automatically through Dense, Core or Eigen. If it were in the
>>> Eigen namespace, how would I provide my own version?
>>
>> Aaah, good point !!
>>
>> Indeed if we accept Helmut's operator, you can't provide your own anymore.
>>
>> At least not unless we do something about it. We could certainly
>> provide Helmut's operator as a simple default while letting you
>> override it; there are various ways we could achieve that in c++. (Let
>> it call a function from a template helper struct that you can
>> specialize, etc, etc).
>
> Maybe, once the Eigen::IOFormat is specified this is then easily doable.
Yes, actually, writing the above I realized that if you agree with an
API like the above, then there is no clash at all, because Helmut's
default operator>> takes a DenseBase& while the IOFormat-enabled
variants take a WithFormat&.
Benoit
>
> I just want to emphasize that I am not all against incorporating
> extended IO functionality, I am just against quick shots which might
> back fire...
>
> - Hauke
>
>
>