<ios> and <iomanip> flags about dbg-macro HOT 8 CLOSED

I didn't know that we could use dbg as a namespace name in addition to the macro name. Neat!

I started an initial implementation here: #68
Glad for any feedback.

from dbg-macro.

Implementation idea:

dbg(dbg_hex(number))

dbg_hex is a simple templated struct which hold the value. std::ostream& operator<< would be specialized to print as hex like you shown in the README.

from dbg-macro.

Thank you for your feedback!

I see how this could be useful and I kind of like the idea. The issue I see is that this could lead to feature creep.

For now, this header has a very simple "API": the dbg(…) macro - nothing more. If we decide to add custom formatting options, I'm afraid it would lead to a whole bunch of things that could potentially be added.

Also, I would like to avoid adding more names to the global namespace. If at all, it should probably be dbg(dbg_macro::hex(…)). If this could somehow nicely integrate with the I/O manipulators from <ios> and <iomanip>, that would be an option. But I don't want dbg(…) to take a second optional argument (see #2).

from dbg-macro.

I agree to not polluting the global namespace. But to keep consistency, maybe we should also move the dbg(...) macro to that new namespace? Or name the namespace dbg!

There are lots of flag from <ios> header. Best case would be supporting all of them.
When debugging, we want to be fast. No time to write a complex line like std::cout << std::hex << value << std::endl. Especially if we have more than one value to print (dbg() already solve this problem).

One problem is that std::ostream (cout, cerr and more) save flags that were set.

std::cout << std::hex;
std::cout << 15 << std::endl;

This code effectively print f (https://godbolt.org/z/caMvrD). If we apply flags from <ios> we have to duplicate std::cerr to not break user-defined flags (std::ostream stream(std::cerr.rdbuf())). Example: https://godbolt.org/z/J0GnAr

I suppose that debugging is consistent enough on a project lifetime so we can do the following (it is not a naming proposition):

 dbg::set(std::hex);
 dbg::set(std::boolalpha);
 ...
 dbg(true);
 dbg(15);

We keep the fast use of dbg() for all values, with an added optional set(), which could be project-scoped (example: set at top of the main()).

from dbg-macro.

Congrats!

I'll take a deep look in a day or two. Promise I'll feedback!

from dbg-macro.

I didn't know that we could use dbg as a namespace name in addition to the macro name. Neat!

A macro is a preprocessor! That mean it gets translated in pre-processing which happen before compilation 😋

from dbg-macro.

A macro is a preprocessor! That mean it gets translated in pre-processing which happen before compilation yum

I was afraid that the preprocessor (because it does not know anything about the syntax) would maybe affect a string like namespace dbg { when a #define dbg(…) … was around.

from dbg-macro.

I left a review! Great work :)

from dbg-macro.