Quote: You can turn them into errors with appropriate flag. I don't see how this type-safety is different from that type-safety.
Because your relying on external non-language features of the implementation that can be circumvented, perhaps unwittingly, since you're using a globalized 'shotgun' technique (turn on warnings-as-errors for everything and pray).
In my opinion printf style is more readable, and I like cdoty code, also if I use:
Log & operator << (Log & log, int i){ ... }
What happens if I want something like Write_log("The user %s with id=%d haas made an invalid operation: code=%d\n", user, id, code); ?
I think it is not possible using last method.
By the way, I'm using c++.
Any suggestions before I use cdoty code? ;)
Edit: And I use gcc, I want my program cross-platform.
[Edited by - riruilo on May 8, 2008 12:53:44 PM]
I've seen things you people wouldn't believe. Attack ships on fire off the shoulder of Orion. I watched C-beams glitter in the dark near the Tannhauser gate. All those moments will be lost in time, like tears in rain. Time to die.
Quote: You can turn them into errors with appropriate flag. I don't see how this type-safety is different from that type-safety.
Because your relying on external non-language features of the implementation that can be circumvented, perhaps unwittingly, since you're using a globalized 'shotgun' technique (turn on warnings-as-errors for everything and pray).
Besides, this doesn't fix the non-POD type issue.
Obviously, you didn't use GCC much. (: You can specify which warnings you can treat as errors, ie. in this case "-Werror=format".
True, it doesn't fix non-POD type issue. It still gives a warning, (or error if you tell him to) but, IMO, the contributed readability of printf-like style outweighs a simple call to .c_str( ) (if it's a std::string) or any other to-char function for printing the object.
Quote: Obviously, you didn't use GCC much. (: You can specify which warnings you can treat as errors, ie. in this case "-Werror=format".
I use GCC plenty. Enough to have developed a healthy aversion to any solution that is tool-specific, such as yours, when there is a tool-agnostic solution. Especially when that solution has other objective advantages and the only subjective disadvantages are that 'it takes more effort to implement.'
Quote: True, it doesn't fix non-POD type issue. It still gives a warning, (or error if you tell him to) but, IMO, the contributed readability of printf-like style outweighs a simple call to .c_str( ) (if it's a std::string) or any other to-char function for printing the object.
Until the object doesn't have c_str, of course. But fine, if you'd like to continue writing like you're using C, I'm not going to waste my time.
Quote:Original post by riruilo Any suggestions before I use cdoty code? ;)
(I assume you are using GCC under the hood.)
Yes. Apply the format attribute to the logging function so you get varargs to be type-checked. Also, be sure to wrap the attribute in a #define, so you can switch it off for other compilers. You can also add "-Werror=format" to the compiler's command line to treat type mismatches as errors.
Quote:Original post by jpetrie Until the object doesn't have c_str, of course. But fine, if you'd like to continue writing like you're using C, I'm not going to waste my time.
To me, it is not writing like I'm using C, it's keeping things simple, readable and easily maintainable. I use other useful C++ features, hell, I love them. The thing is that I won't write code using the X way just because everyone else does; if a feature doesn't make sense, and I can do it in a more simple way, then I'll do it that way. From my experience I find that overcomplicating is generally not good. But then, that's only my personal opinion and you have right to disagree.
Quote:Original post by jpetrie Until the object doesn't have c_str, of course. But fine, if you'd like to continue writing like you're using C, I'm not going to waste my time.
To me, it is not writing like I'm using C, it's keeping things simple, readable and easily maintainable. I use other useful C++ features, hell, I love them. The thing is that I won't write code using the X way just because everyone else does; if a feature doesn't make sense, and I can do it in a more simple way, then I'll do it that way. From my experience I find that overcomplicating is generally not good. But then, that's only my personal opinion and you have right to disagree.
[edit]Great. Thanks for rating me down for my opinion. Next time I won't help anyone here, since I get only rated down for that.[/edit]
Hey All your opinions are useful for me, moreover this is a forum, where you write them...
I've seen things you people wouldn't believe. Attack ships on fire off the shoulder of Orion. I watched C-beams glitter in the dark near the Tannhauser gate. All those moments will be lost in time, like tears in rain. Time to die.
Quote:Original post by desudesu You can turn them into errors with appropriate flag. I don't see how this type-safety is different from that type-safety.
"That" type safety is also in effect at runtime. "That" type safety affords you an opportunity to gracefully resolve a value-based mismatch.
Quote:Original post by desudesu [edit]Great. Thanks for rating me down for my opinion. Next time I won't help anyone here, since I get only rated down for that.[/edit]
Assumption is the mother of all fuck-ups. You're likely not being rated down for your opinion but for your manner of presenting it. Trust me, it happens to me all the time! [smile]
It's not a big deal. Don't call attention to it; just continue contributing positively and your net rating will climb until it plateaus.
