Skip to content

Conversation

rafa-be
Copy link
Collaborator

@rafa-be rafa-be commented Oct 6, 2025

I had issues with the use of std::printwith LLVM libc++ or with GCC 13:

/host/scaler/scaler/io/ymq/pymod_ymq/utils.h:15:10: fatal error: print: No such file or directory
15 | #include
| ^~~~~~~
compilation terminated.

This standardizes the use of iostreams instead over the whole library.

@rafa-be rafa-be requested a review from gxuu October 6, 2025 16:33
gxuu
gxuu previously approved these changes Oct 6, 2025
Copy link
Contributor

@gxuu gxuu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer the printf/fprintf family. Some rationale:

  • it's mostly shorter compare to std::cout.
  • format string is understandable by most programmer, even those who writes Java.
  • easier to substitute when we are ready for std::print.

But, no matter what, this really is minor. Given that you made changes already, I am fine with either way.

@rafa-be
Copy link
Collaborator Author

rafa-be commented Oct 6, 2025

I would prefer the printf/fprintf family. Some rationale:

* it's mostly shorter compare to `std::cout`.

* format string is understandable by most programmer, even those who writes Java.

* easier to substitute when we are ready for `std::print`.

But, no matter what, this really is minor. Given that you made changes already, I am fine with either way.

Yeah, printf is fine too. It's a little bit more annoying when dealing with C++ objects though (e.g. std::string).

Ideally I'd have prefer std::print but it's not well supported yet :-(.

@gxuu
Copy link
Contributor

gxuu commented Oct 6, 2025

I would prefer the printf/fprintf family. Some rationale:

* it's mostly shorter compare to `std::cout`.

* format string is understandable by most programmer, even those who writes Java.

* easier to substitute when we are ready for `std::print`.

But, no matter what, this really is minor. Given that you made changes already, I am fine with either way.

Yeah, printf is fine too. It's a little bit more annoying when dealing with C++ objects though (e.g. std::string).

Ideally I'd have prefer std::print but it's not well supported yet :-(.

The thing is, complicated object prints are supported via std::formatter template specialization. I am not sure if that will be compatible with operator<<. So if we in the future try to support complicate object prints, then it would be easier to to change from printf to std::print compare to changing from std::cout to std::print.

Anyway, let's get this merged. ;)

@sharpener6
Copy link
Collaborator

Don't worry about convert to cout/cerr to formatter print style format, you can use codex/claude to do it.

to unify them, use universal logging module, ask codex/claude to change all printing and std::out std::err to universal logging module

@rafa-be
Copy link
Collaborator Author

rafa-be commented Oct 7, 2025

Don't worry about convert to cout/cerr to formatter print style format, you can use codex/claude to do it.

to unify them, use universal logging module, ask codex/claude to change all printing and std::out std::err to universal logging module

All the codebase uses the logger. These print are either in the examples or in the tests. Do we want to use the logger in these too?

@rafa-be
Copy link
Collaborator Author

rafa-be commented Oct 9, 2025

Related issue #311

Signed-off-by: rafa-be <raphael@noisycamp.com>
Signed-off-by: rafa-be <raphael@noisycamp.com>
@rafa-be rafa-be force-pushed the standardize-c++-printing branch from 8cb6ae9 to a9847c9 Compare October 10, 2025 15:58
@rafa-be rafa-be marked this pull request as ready for review October 10, 2025 16:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants