GNOME Bugzilla – Bug 517787
Add operator<< and operator>> to Gio streams
Last modified: 2018-05-22 12:08:24 UTC
It'd be nice to add some basic support for the insertion and extraction operators in giomm.
Created attachment 105677 [details] [review] Here's a start at implementing operator<< for Gio::OutputStream A starting point for discussion, not necessarily a finalized proposal. One thing to note is that I added another 'test' to the tests/giomm_simple/ directory instead of adding a new test subdir. That meant that i needed to rename the existing main.cc file to something more descriptive, which is why it looks like there's so much change in the tests directory
These new functions (operator<<, endl) should probably be virtual. What about an overload that takes a sigc::slot? g*mm indentation should be 2 spaces... Also I have just seen that we do not have an InputStream::read() overload for strings.
(In reply to comment #2) > These new functions (operator<<, endl) should probably be virtual. Well, these are currently not even member functions, are you suggesting that they should be member functions? > What about an overload that takes a sigc::slot? Do you mean that the manipulator should be a sigc::slot instead of a function pointer typedef? > g*mm indentation should be 2 spaces... true > Also I have just seen that we do not have an InputStream::read() overload for > strings. Is that different than this mailing list post? http://mail.gnome.org/archives/gtkmm-list/2008-February/msg00119.html
Well. Now I realize. I apogolize for these... inconsistencies. I am clearly of no help when replying from uni without the necessary concetration, so you can sort of scratch my whole reply above. > (In reply to comment #2) > > These new functions (operator<<, endl) should probably be virtual. > > Well, these are currently not even member functions, are you suggesting that > they should be member functions? (I do think that it's better to keep them as non-members, to keep the interface clean.) > > What about an overload that takes a sigc::slot? > > Do you mean that the manipulator should be a sigc::slot instead of a function > pointer typedef? Yes, it occurred to me since you provided the one with function pointer. > > Also I have just seen that we do not have an InputStream::read() overload for > > strings. > > Is that different than this mailing list post? > http://mail.gnome.org/archives/gtkmm-list/2008-February/msg00119.html Nope, apologies as above. Still I do stand by my reply in the mailing list thread. It is not so easy to see what would be an optimal tradeoff between providing C++-specific helpers and keeping the binding "clean". Regarding read(), I'm not really worried about convenience vs hidden performance cost. It's up to the API user to decide which call would be more appropriate. It's just about how far we want to go with these helpers. operator>>(string&) would need to read until EOL, which would then depend on this read() overload, or maybe another one for the purpose of reading until EOL. I think that for, both operators, it would be nice to have overloads for different datatypes. But then you've actually begun implementing a text stream interface.
I don't think this bug needs to be high priority or severity critical, but please tell me if I'm missing something.
no, you're not missing anything. I'm not sure how they got set to those values.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glibmm/issues/6.