> Legacy compatibility says that you can not break something that works,
not just 'nobody uses it' or 'you don't like it'. BTW streaming is actually heavily used.


Except that has happened to literally every single iteration of C++. There's always something that works that gets removed.
It's just a matter of finding a better replacement and people will stop using it.
It may feel irreplaceable now, but trust me, it isn't, and we will eventually get there.

I'm a very strong proponent of the philosophy that the code you delete is as important if not more important than the code you add.
Cleaning house helps make things more understandable and maintainable. A blind effort to support things that are obsolete causes and disproportionate amount of burden to maintain it, and even forces you to lose on opportunities to make things better as it forces you to navigate around its limitations.
Bad legacy if not pruned will eventually crush you. And I have seen it kill more projects than I hoped.



________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Chris Ryan via Std-Proposals <std-proposals_at_[hidden]>
Sent: Wednesday, February 12, 2025 12:59:45 AM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Chris Ryan <chrisr98008_at_[hidden]>
Subject: Re: [std-proposals] std::bin manipulator for integer binary input/output

> I'm not so sure about the "will be there for a long time".
AND
> It may not be by C++26, but hopefully eventually, things seem to be going in that direction.

Legacy compatibility says that you can not break something that works,
not just 'nobody uses it' or 'you don't like it'. BTW streaming is actually heavily used.

It has been there long before you existed and it will still be there until the language ends.


On Tue, Feb 11, 2025 at 10:59 AM Tiago Freire via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:

> I/O streams will be there for a long, long time, and I think retrofitting useful features is for the benefit of the language and its users.

I'm not so sure about the "will be there for a long time".
As it has been mentioned in this thread, new features such a format and print, are increasingly introducing better ways to do things in this space.
Add some extra I/O (for file and terminal) that are capable of interfacing with them, and eventually iostream become obsolete enough to become deprecated. The burden of maintaining it at that point will become greater than any benefit it provides.


It may not be by C++26, but hopefully eventually, things seem to be going in that direction.

I have personally already banned them from my code base, once you figure out that are better ways to do things, believe me, you don't really need it.

That's not to say that if I had voting power on this that I would vote against it, my vote would have been neutral. 10 years ago this would have been a great proposal, just don't think it's worth the time of the committee today given the progress that has been made since then.

New formatting facilities can already do this, it's time to move on.


________________________________
From: Javier Estrada <iphone.javier.estrada_at_[hidden]<mailto:iphone.javier.estrada_at_[hidden]>>
Sent: Tuesday, February 11, 2025 6:13:25 PM
To: Tiago Freire <tmiguelf_at_[hidden]<mailto:tmiguelf_at_[hidden]>>
Cc: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]> <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>>
Subject: Re: [std-proposals] std::bin manipulator for integer binary input/output

Thx for the reply, Tiago.

I/O streams will be there for a long, long time, and I think retrofitting useful features is for the benefit of the language and its users.

Seems to me that the cost of adding a manipulator is very small compared to the feature proposed by Victor in the paper listed by Jonathan (https://wg21.link/p1729).
---
On an unrelated note, since this is the first time that I post a proposal, how does the process work? Who calls the shots—e.g., if I decided to write a proposal and submit it, whose approval would it have to go through? The maintainers of this list?

I would understand that this is a filter to gather input and usefulness of the proposal, but does this list have "veto" power over proposals?

Thx!






On Mon, Feb 10, 2025 at 10:12 AM Tiago Freire <tmiguelf_at_[hidden]<mailto:tmiguelf_at_[hidden]>> wrote:
I’m going to be upfront.
I may a bit biased when it comes to iostream.
I think it is irredeemably bad, there’s nothing good about it, I hate it to the core, and I rather see it replaced.
And extending it, feels to very much like a wasted effort.

I think is far more productive in the long run to have separate things that deal only with formatting (and extend that) and create an independent file or i/o interface that just does reads and writes without formatting.


From: Std-Proposals <std-proposals-bounces_at_[hidden]<mailto:std-proposals-bounces_at_[hidden]>> On Behalf Of Javier Estrada via Std-Proposals
Sent: Monday, February 10, 2025 7:01 PM
To: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>
Cc: Javier Estrada <iphone.javier.estrada_at_[hidden]<mailto:iphone.javier.estrada_at_[hidden]>>
Subject: [std-proposals] std::bin manipulator for integer binary input/output

There is a manipulator gap to read/write integer numbers in binary. As you well know, the standard manipulators are std::oct, std::dec, std::hex, which is essentially a format flag onto ios_base::basefield.

Having a dedicated manipulator would close that gap and would eliminate the current "trick" of using std::bitset. The (abbreviated) example in cppreference .com reads:


#include <bitset>

#include <iostream>



int main()

{

    std::cout<http://en.cppreference.com/w/cpp/io/cout> << "The number 42 in octal: " << std::oct << 42 << '\n'

              << "The number 42 in decimal: " << std::dec << 42 << '\n'

              << "The number 42 in hex: " << std::hex << 42 << '\n';



    // Note: there is no I/O manipulator that sets up a stream to print out

    // numbers in binary format (e.g. bin). If binary output is necessary

    // the std::bitset trick can be used:

    std::cout<http://en.cppreference.com/w/cpp/io/cout> << "The number 42 in binary: " << std::bitset<http://en.cppreference.com/w/cpp/utility/bitset><8>{42} << '\n';
}

With a std::bin manipulator:


#include <iostream>

#include <sstream>



int main()

{

    // This yields 101010
    std::cout<http://en.cppreference.com/w/cpp/io/cout> << "The number 42 in binary: " << std::<http://en.cppreference.com/w/cpp/utility/bitset>bin << 42 << '\n';

}



It would also take advantage of other manipulators, like std::setw and std::setfill:



#include <iostream>

#include <sstream>



int main()

{

    // This yields 00101010

    std::cout<http://en.cppreference.com/w/cpp/io/cout> << std::setw<http://en.cppreference.com/w/cpp/io/manip/setw>(8) << std::setfill('0');

    std::cout<http://en.cppreference.com/w/cpp/io/cout> << "The number 42 in binary: " << std::<http://en.cppreference.com/w/cpp/utility/bitset>bin << 42 << '\n';

}



Reading binary numbers would also be addressed by the input streams.



IF this proposal is considered, I see changes in:

- A new bin flag in ios_base::basefield.

- Support for the flag in ios_base::setf, ios_base::unsetf and ios_base::flags member functions.

- Creation of the manipulator (similar to other manipulators) for the different char_traits

- Support for binary parsing for input streams

- Support for binary output for ostreams.



std::ios_base in cppreference.com<http://cppreference.com>:

https://en.cppreference.com/w/cpp/io/ios_base


Integer I/O manipulators

https://en.cppreference.com/w/cpp/io/manip/hex



Regards,

—Javier





--
Std-Proposals mailing list
Std-Proposals_at_lists.isocpp.org<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals