Should we be using fprintf or iostreams?

[mithro]

There seems to be inconsistent usage of fprintf and iostreams in Verilog to Routing. I'm assuming this just comes about by having a bunch of different developers and no style guide telling you which one to use (and I think you did mention that the packer was originally a separate project from vtr?).

It looks like fprintf is slightly more popular, but I assume that is because it was used first.

What is your preference going forward? Should new code be using fprintf or iostreams?

Is it worth the effort doing a translation of the fprintf code into iostreams? (Going in that direction is pretty easy automatically, going in the other direction is much harder.)

Just a couple of quick greps;

fprintf usage

$ ack --type=cpp -l fprintf vpr/ | sort
vpr/src/base/atom_netlist_utils.cpp
vpr/src/base/read_place.cpp
vpr/src/pack/cluster.cpp
vpr/src/pack/cluster_router.cpp
vpr/src/pack/lb_type_rr_graph.cpp
vpr/src/pack/output_blif.cpp
vpr/src/pack/output_clustering.cpp
vpr/src/pack/pb_type_graph.cpp
vpr/src/pack/prepack.cpp
vpr/src/place/place.cpp
vpr/src/place/place_macro.cpp
vpr/src/place/timing_place_lookup.cpp
vpr/src/power/power_callibrate.cpp
vpr/src/power/power.cpp
vpr/src/power/PowerSpicedComponent.cpp
vpr/src/power/power_util.cpp
vpr/src/route/route_common.cpp
vpr/src/route/rr_graph2.cpp
vpr/src/route/rr_graph.cpp
vpr/src/route/rr_graph_sbox.cpp
vpr/src/timing/endpoint_timing.cpp
vpr/src/timing/path_delay2.cpp
vpr/src/timing/path_delay.cpp
vpr/src/util/vpr_utils.cpp
$ ack --type=cpp -l fprintf vpr/ | wc -l
25

iostream usage

$ ack --type=cpp -l "stream>" vpr/ | sort
vpr/src/base/netlist_writer.cpp
vpr/src/base/read_blif.cpp
vpr/src/base/read_place.cpp
vpr/src/base/read_route.cpp
vpr/src/draw/draw.cpp
vpr/src/pack/cluster.cpp
vpr/src/pack/hmetis_graph_writer.cpp
vpr/src/pack/pack.cpp
vpr/src/place/place.cpp
vpr/src/place/place_macro.cpp
vpr/src/power/power_callibrate.cpp
vpr/src/route/build_switchblocks.cpp
vpr/src/route/cb_metrics.cpp
vpr/src/route/route_budgets.cpp
vpr/src/route/route_budgets.h
vpr/src/route/route_common.cpp
vpr/src/route/rr_graph_reader.cpp
vpr/src/route/rr_graph_writer.cpp
vpr/src/timing/timing_util.cpp
vpr/src/util/histogram.cpp
$ ack --type=cpp -l "stream>" vpr/ | wc -l
22
$ ack --type=cpp -l "std::stringstream" vpr/
vpr/src/place/place_macro.cpp
vpr/src/util/fasm.cpp
vpr/src/draw/draw.cpp
vpr/src/base/netlist_writer.cpp
vpr/src/base/read_options.cpp
vpr/src/base/read_blif.cpp
$ ack --type=cpp -l "std::stringstream" vpr/ | wc -l
6
$ ack --type=cpp -l "ostream" vpr/
vpr/src/power/power_callibrate.cpp
vpr/src/pack/hmetis_graph_writer.cpp
vpr/src/route/cb_metrics.cpp
vpr/src/route/rr_graph_writer.cpp
vpr/src/route/route_common.cpp
vpr/src/route/build_switchblocks.cpp
vpr/src/route/route_budgets.h
vpr/src/base/netlist_writer.cpp
vpr/src/base/read_route.cpp
$ ack --type=cpp -l "ostream" vpr/ | wc -l
11

[jhol]

IMHO in C++, the iostreams is the correct approach.

[kmurray]

I agree the type safety of iostreams is good, but they are somewhat painful to use in practise. I also find them much less readable than printf and friends.

VPR started out in C which is why large parts of the code base still use printf and friends.

I've contemplated switching to something like fmtlib which gives the best of both worlds (type-safe + readable). However there is a cost to using a non-standard library (any new developers would need to learn it). It would also be a fair amount of work to convert the code base to it.