I have a question about Variable size argument functions. When using printf() a variable argument size function you do not need to give the number of arguments in the function call but when creating your own you must pass the number of arguments in the list. Is it possible to not pass the number of arguments like printf()? Thanks
printf() is used in C; this is the C++ forum. You might have better results in the correct forum.
7. It is easier to write an incorrect program than understand a correct one.
40. There are two ways to write error-free programs; only the third one works.*
I was just using printf() as an example. This is still a C++ question. Please move back to the C++ forum.
Whilst it is possible, you need to be aware that variable arguments are not type safe in any way.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
While I agree that this question might suit better the C forum. I want to point out that it is possible and not bad at all to use printf() in C++. Sometimes, it's simply much easier without having any drawbacks.Originally Posted by Sentral
I think the C++ solution would be to use operator chaining with some suitable class type. In the case of the equivalent to printf(), we see it used in an overloaded operator<< returning a reference to the output stream that was passed to it.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
Why do so much work ? It is possible to reproduce the exact same behaviour without that much crap. This is what you are looking for, my friend.
That is why I was trying to use. I'm really confused now. Could you please explain this part. Why is fmt a pointer and how does the while loop know when to end? Thanks
Code:while (*fmt) switch(*fmt++) { case 's': /* string */ s = va_arg(ap, char *); printf("string %s\n", s); break; case 'd': /* int */ d = va_arg(ap, int); printf("int %d\n", d); break; case 'c': /* char */ /* need a cast here since va_arg only takes fully promoted types */ c = (char) va_arg(ap, int); printf("char %c\n", c); break; }
There's an interesting tutorial here .
I came by this one actually today, after an interesting conversation on another forum about macros.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
Well, since this was already suggested, I will quote the exact reason you should do so much work. This quote, you can find right in this post.I personally agree with Laserlight. The proper C++ way would be overloaded operators to chain. Unfortnately, you may have to encapsulate Plain Old Datatypes in order to use it.Whilst it is possible, you need to be aware that variable arguments are not type safe in any way.
Sent from my iPadŽ
Thanks will read tonight.
BTW how often are VA function used and how useful are they? In all my C++ classes in college this has never been mentioned. I'm trying to learn some things on my own.
VA functions can be very powerful, and you will know when you need one. Reasons exist why they aren't seen to often; most things that would be VA functions can work efficiently a different way. For instance, you could implement a sort function that takes a lot of arguments for items to sort, but then why not put those items in a container? Containers usually save a programmer inumerable headaches.
Unspecified (is a better term, i reckon - Stroutstrup 3rd edition - Variable argument functions are dealt with by function overloading and default arguments) argument functions are only needed when both the number of the arguments and the type of the arguments vary, and they vary in an unspecified way only known at run-time.
This is a rare situation. So rare in fact that entire programming languages there are that don't offer this possibility. And on those few cases in which one can think of some use, if the possible variations are somewhat limited to a manageable number, it's preferable to simply overload the function and create a "sidekick" function that deals with the common bits to make code more easy to maintain. Or use containers, as Citizen suggested.
The major reason why you should always consider overload over the elipsis has already been given by Laserlight. However, truth be told, dangerous options are usually the most publicized. So I'm tempted to think the reason why you don't hear much about these functions is because they are very rare.
Last edited by Mario F.; 06-01-2006 at 06:05 PM.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
