lol i just figured out that I wasn't clearing that area (I figured it out cuz I changed the size of the window)

Actually I think you can put a variable onto the screen with standard functions. cin reads a variable and cout prints the variable =) Or you can use stringstream method but use cout to print out the text to screen without win32 api.

500kb is a big deal to me I mean 500 kb just to put the x and y position of the mouse on the screen is bloated, and I hate bloat-ware. I know 500kb isn't a lot but the fact is it went from under 100 kb to over 500 just by adding x/y position of mouse. 200kb would be nice.

I'll try to implement a sprintf method without showing all the padded characters >.>

Are you compiling with any optimization whatsoever?

If you're in Visual Studio try the release build - the executable size will almost certainly be much smaller.

Please don't use sprintf over stringstreams just because it makes the executable size smaller. There's no reason to consider this bloatware and certainly no reason to give up the safety of c++ streams.

hmm safety... Please point me to a site that explains the safety of stringstreams over sprintf (I'm new at this).

I know I have a strip optimization flag which'll cut the exe size *in half*. Well if the size increase is due to safety then that's not that bad.

Why the binary must be small? Is there a reason?

Things that work for me:

- I am writing a winning 4K or 64K intro entry to competition like Assembly 2007
- I am writing for embedded device or similiar circumastances
- The binary must fit into limited storage media (floppy? <- why!? ;)
- Transfer time over network could be an issue (again, why!? :)

If the target is a desktop computer, reducing the size is not much interest. If switching from stringstream (?) to printf cuts the size of the binary into half, it looks like it is tiny to begin with which brings to another point: Code Is Small Anyway.

Yup: code is relatively tiny most of the time compared to the data associated with the code. Easiest way to blow up the size of the code is to generate inpractical use of permutations of code using templates, macros or similiar construct (speaking of C/C++ here different strokes with different languages). In this kind of situation the code isn't small anyway any longer.

Advice is being asked but the reason is not mentioned -- the reason and to be more precise, knowing it would be much more useful in evaluating the situation. So far I collected:

1. Number must be converted into readable form (I assume output for human to read, could also be written into a serialized form for storage, fileformat, whatnot!?)

2. This must be as small as possible: libraries implementing this are too large

I wonder WHY that is. The only reasonable answer to this set of limitations is: "write your own", "google for something that someone else wrote and use it", or, "rip the code from library implementation -- example: g++ comes with sourcecode, and you can also look inside runtime libs in other vendor's products with debugger and rip"

And so on.. but this is like bending backwards thrice for no benefit that I can see. Strange stuff. Please explain, my curiosity is at 11!!!

Ooops.. forgot the point I had in mind when hit reply. :)

If the c++ library is too big, what makes the c version small enough? If the c version is small enough, why the c++ version then isn't small enough as it offers additional benefit of being typesafe!? I'm asking this because they aren't THAT much different size.. (compiler and standard library vendor withstanding..)

Quote:Original post by biscuitz
hmm safety... Please point me to a site that explains the safety of stringstreams over sprintf (I'm new at this).

Part of the reason is that function like itoa and sprintf are old C style functions, they take a char array instead of a string object. See a std::string can manage it's size from within its class functions, whereas an array is just a block of memory and it's up to the programmer to manage it.

Like this:

char NumberBuffer[2];
NumberBuffer = itoa( 21445 );

21445 needs five characters plus the null terminator(so 6 elements), but NumberBuffer is only 2 elements in size. There are no errors or anything reported for something like this, you get a nice memory leak and bunch of bugs.

Now when using the stringstream you simply inform the stringstream class that you want to add an integer and it will manage all the memory for you, which I think is a lot better. Plus you can use stringstream to convert between an basic variable type, not just integers.

Edit:

About the size increase. The reason is probably that the compiler needs to add in the whole stream library. So it's not 500k "just for one variable", I bet if you added a crapload more print statements there would be virtually no size increase.

Quote:Original post by biscuitz
hmm safety... Please point me to a site that explains the safety of stringstreams over sprintf...

->

I'm using the sprintf method, for now. I'm not sure, but I don't think buffer overflow will be a problem. ATM I have the buffer at size of 32, I don't expect the mouse x/y position(s) will go over 32 digits ( if that happens then you've either got very high DPI or a very big screen, or both :D ) hmm maybe scanf method would be better.