|
Hello - we are programming C++, NOT C. I get heartily sick of people using char arrays and sprintf instead of their C++ equivelants.
Christian
I am completely intolerant of stupidity. Stupidity is, of course, anything that doesn't conform to my way of thinking. - Jamie Hale - 29/05/2002
|
|
|
|
|
Christian Graus wrote:
sprintf instead of their C++ equivelants.
Ok, I admit it. I still have a tendancy to use sprintf when I haven't got MFC CString::Format. So what is the nice C++ equivelant? I do need to learn to code better.
Michael
"Eureka" is Greek for "This bath is too hot"
|
|
|
|
|
Check out my article on ostringstream...
Christian
I am completely intolerant of stupidity. Stupidity is, of course, anything that doesn't conform to my way of thinking. - Jamie Hale - 29/05/2002
|
|
|
|
|
Ugh...
ostringstream is an over kill.
*PRINTF* can be used safely!!!!
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
|
Tim Smith wrote:
*PRINTF* can be used safely!!!!
Sure. You just need to create ugly, C style strings, handle your own types manually, and create huge buffers to decrease the possibility of overflows.
Christian
I am completely intolerant of stupidity. Stupidity is, of course, anything that doesn't conform to my way of thinking. - Jamie Hale - 29/05/2002
|
|
|
|
|
Or, you can (1) use stack allocated TCHAR buffers, to avoid the unnecessary overhead of dynamic memory allocation that most string classes require, and (2) use _sntprintf(...) to prevent buffer overruns, at the expense of length checking (which you get using C++ string classes, anyway...). This also gives me the benefit of easy (IMHO, compared to the stream modifiers) manipulation of the display/format of a value: I believe that
"0x%08X"
-is easier to type than using stream manipulators.
Although I must admit that using ostrstream is usually faster (at runtime) than sprintf(...) .
Peace!
-=- James.
"Some People Know How To Drive, Others Just Know How To Operate A Car."
(Try Check Favorites Sometime!)
|
|
|
|
|
Not when people using endl.
I see that ALL THE TIME. Using ENDL will bring any application to its knees.
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
|
You should clarify - endl sends a flush as well as a newline, so using it for every newline will bring an application to it's knees. Using it to do a new line and flush will perform exactly as you would expect.
Christian
I am completely intolerant of stupidity. Stupidity is, of course, anything that doesn't conform to my way of thinking. - Jamie Hale - 29/05/2002
|
|
|
|
|
Yes, but that is due people misunderstanding "how things work" (meaning endl ). Granted, stuff like that happens far too often these days in the Software Development world... Entropy Abounds.
Peace!
-=- James.
"Some People Know How To Drive, Others Just Know How To Operate A Car."
(Try Check Favorites Sometime!)
|
|
|
|
|
Half the reason people switch away from VB is to find out what actually goes on.. and then like me they find out that they weren't quite as good as they thought - they've been nannied.
Alice thought that running very fast for a long time would get you to somewhere else. " A very slow kind of country!" said the queen. "Now, here , you see, it takes all the running you can do, to keep in the same place".
|
|
|
|
|
Wow - the email I got was so full of  's that it was illegible.
You're right that typing in the format is usually more intuitive than using iostream modifiers. That's because we are all used to it, because we were taught C instead of C++. However, given that you agree it's faster, AND there is no way that any printf variant will accept user defined types, isn't it worthwhile learning to do things in C++ ? I find I can format things with iostream modifiers as easily as with printf nowadays. It's just a case of learning how.
Christian
I am completely intolerant of stupidity. Stupidity is, of course, anything that doesn't conform to my way of thinking. - Jamie Hale - 29/05/2002
|
|
|
|
|
James R. Twine wrote:
is usually faster (at runtime)
I once had a app log component changed from streams to snprintf - since the streams were freaking slow. Dunno how thsi fits with your experience, but it has cured from from using streams unequivocally.
Peter
Back in the days before yer Gighertz and Teraflops there was something we old timers called paranoia. Andrew Torrance, The Lounge [sighist]
|
|
|
|
|
I specifically mentioned ostrstream , not streams in general. And it would be interesting to see how the streams in your case were being used, just to be sure that they were not being abused.
Peace!
-=- James.
"Some People Know How To Drive, Others Just Know How To Operate A Car."
(Try Check Favorites Sometime!)
|
|
|
|
|
After using them for a while, I basically came to the conclusion that these streams need to be redesigned fromt he ground up again. Nice start, but they have a lot of limitations (not to mention adding 50k to your program just so you can format a number).
Right tool for the right job. Printf works just fine.
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
|
Ok, my real point to all this really isn't about if streams are better than *printf. They both work just find but only a fool wouldn't see that streams are safer.
HOWEVER, my real point was that buffer overrun problems extend far outside the formatting of output and strings. Streams will go a long way to fixing these problems, but they won't even come close to correcting all buffer overrun problems.
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
|
I think you mean sprintf(...) , because the discussion is about buffer overruns...
And snprintf(...) is a simple way to prevent them.
Peace!
-=- James.
"Some People Know How To Drive, Others Just Know How To Operate A Car."
(Try Check Favorites Sometime!)
|
|
|
|
|
Tim Smith wrote:
ostringstream
As a MFC, ATL and WTL programmer I never use any streams at all. Although, I do use stl containers like map, list, set, and vector a lot.
John
|
|
|
|
|
at least use snprintf - to limit the number of chars to be put in the buffer.
-c
shh! the audience (and the NSA) is listening
|
|
|
|
|
We should definitely use appropriate C++ classes for dealing with memory when raw performance is not needed.
When raw performance is needed, though, there is no substitute for stack allocated C style arrays. And heap allocated C style arrays will still outperform any object oriented solution available today.
I have experimented in one of my libraries with CString, std::string and TCHAR arrays and there is no doubt that TCHAR arrays delivered the best performance by far and in this particular system, performance was/is far more important than OOP. It definitely requires more work to make sure that it is done right and does not overwrite memory or access deleted memory but when needed it's the only way to go.
|
|
|
|
|
I haven't worried at all about security yet since I haven't gotten even close to a release version.
- Matt Newman / Windows XP Activist
-Sonork ID: 100.11179
Could you Would you with a goat? - Dr Suess
|
|
|
|
|
|
Somewhat. I am trying to get the core of the program done first. However, say my program uses password autheticiation the CheckPassword() function doesn't do anything it just assumes it is okay and passes it on. When I get a functioning build (ie the starts doing it's function) I will make CheckPassword() actually check the password etc etc. For example the server I am working on accepts connections and nothing more so there isn't any need for security so far.
- Matt Newman / Windows XP Activist
-Sonork ID: 100.11179
Could you Would you with a goat? - Dr Suess
|
|
|
|
|
I really suggest that you read some book on security (e.g. Writing Secure Code, MS Press).
There is more to security programming than a CheckPassword() function. And since you mentioned a server, things like DoS and similar attacks come into mind.
Think about
Andreas
Vote against software patents in europe
|
|
|
|
|
Andreas Saurwein wrote:
There is more to security programming than a CheckPassword() function
I was just using that as an example.
I do have to worry about DoS etc but my server doesn't really do anything that could be exploited yet. I was mearly saying that my project is in it's infancy and is even close to exposing criticaly information.
Andreas Saurwein wrote:
Writing Secure Code, MS Press
Thanks for the book suggestion I will have to check that out.
- Matt Newman / Windows XP Activist
-Sonork ID: 100.11179
Could you Would you with a goat? - Dr Suess
|
|
|
|
|
When you work in a bank... security is always an issue... I´m really paranoid with security... just as my bosses
Mauricio Ritter - Brazil
Sonorking now: 100.13560 Trank
The alcohol is one of the greatest enemys of man, but a man who flee from his enemys is a coward. ![Beer | [beer]](https://codeproject.freetls.fastly.net/script/Forums/Images/beer.gif)
|
|
|
|