printf++

from printf.

Hi @DBJDBJ,
thanks a lot for your feedback.

Actually I wouldn't create a header only version of printf cause I don't see any big advantages.
Don't get me wrong here, I'm a huge fan of c++ header only libs (just see my other projects like 'vic' here).
I'm using printf in my heavily header only c++ turnkey-board project (not public yet).
IMHO header only files only makes sense if c++ code can be inlined very well, is kind of templated and is class based - which is printf not.
You can use printf in c++ projects without any problems. Linking and compiling printf.c shouldn't be a problem.

However, I see you created a header only c++ version. So far so good, but I don't like the idea of wrapping all routines as extern "C" inline inside a mpaland_dbjdbj namespace at all. 😞 You should do better!
Problem is that compiler puts all functions in every single module which bloats your code.

My idea would have been to create a printfpp class instead of a namespace and create static functions inside. Using printfpp::printf() directly then.
That way a compiler/linker can use the static class functions for optimization very well. Try it if you like.

from printf.

Thanks, Marco, I shall give it a due diligence as soon as I have time ...

Just a quick clarification, if I may: you do not like them inline functions being extern "C"? or you do not like them being inline?

std:: namespace is header only lib with a lot of inline functions?

ps: printf.c does not link in my MSVC projects because linker thinks we are duplicating printf, etc ... just by making it cpp and using a namespace arround it, all is fine, of course.

Kind regards ...

from printf.

Hi Dusan,
I don't like inlining a whole lib, but when using a namespace the way you did, it's the only option.

Anyway, to create a header only lib you just have two options (as far as I know): inline everything or create a class which is suitable for static use.
First option may be used in C or C++ while the second is C++ only. So, if you want to create a C++ header only lib, I would always prefer option 2, like:

class printfpp
{
private:
  // 'inline' here, to give the compiler a hint that inlining would be cool
  static inline bool _is_digit(char ch)
  {
    return (ch >= '0') && (ch <= '9');
  }

  // internal itoa for 'long' type
  static size_t _ntoa_long(out_fct_type out, char* buffer, size_t idx, size_t maxlen, unsigned long value, bool negative, unsigned long base, unsigned int prec, unsigned int width, unsigned int flags)
  {
    :
  }

public:
  static int printf(const char* format, ...)
  {
    va_list va;
    va_start(va, format);
    char buffer[1];
    const int ret = _vsnprintf(_out_char, buffer, (size_t)-1, format, va);
    va_end(va);
    return ret;
  }
};

This is way cleaner than using a namespace with inlined functions.
You don't need extern "C" for linkage in a c++ project.

You are right, there are conflict problems when linking this lib with the standard lib. I can't link it native in VC projects either.
I have a tested solution for this, but it's not commited yet, issue #16 is still open for this fix.
Trying to do this this week.
Best regards!

from printf.

Ok then, my printf++.h is a TINY change of your printf.c, it is C++17 and it works rather brilliantly thanks to you. (it fixes issue #16 by going around it)

I will take the risk of using it. It is perfectly usable in any kind of VS2017 C++ project right now. (I shall remove extern "C" of course.)

Please let me know if you agree with the choice of the namespace name, MIT license etc. Marco, your comments are thought-provoking. Please read further only if you have time.

The conceptual debate :)

I am unable to go against std:: design patterns & concepts, where 'inline' is deliberately sprinkled around, in concert with 'free' functions, operators and C++17 inlined globals.

Also, I know more than one member of the good MSVC team who will strongly oppose the claim that CL.exe "seeing" inline function is bloating the code :) I dare to write ...most likely, you're worrying over nothing, for several reasons:

1. The modern C++ compiler treats inline as a hint. The decision rests with the compiler itself, and it tries to make the application fast. CL compiler will try to optimize more towards a smaller file size.
2. In case of CL you are looking at a couple of kilobytes (16kb increments). In an age of terabyte hard drives.
3. if exe size does become a problem, all modern c++ compilers typically have an "optimize for size" flag.
4. large executables typically gain their size because of a lot of data and resources. The code itself is very rarely the problem. Even due to template metaprogramming.

Thank you for persevering through my comment ...

from printf.

I think, anything is said, so I close this issue.

from printf.