hi

suppose that i hav to call a function which has default parameters. if i hav to assign a value for any one of the parameters myself, what can i do? is ther any way without calling the function with all parameters??

eg.

if i hav to call this function, with only the double value and if i want to have the rest of the parameters set to default, what can i do? should i hav to call the function with all the parameters? or is there any other way?

thnx

When calling a function with default parameters you can omit an argument only if (and only if) you omit all of the ones to the right of that one.

Regards,

Dave

You could move the double value to the beginning in your function definition if you wanted to vary it.

okie

but wen i create an application using MFC
create a window or frame

it has ten arguments.
but i need only the second and sixth args
its really frustatin in such situations to type all the default args till the sixth one which are too long.

wat can i do??

Create a 'wrapper function', so to speak, around the create call that takes two arguments, and pass those to the create call inside the wrapper. This way, all the other arguments can be specified in one location, and the values at 2 & 6 can use your supplied arguments.

__________________
Use the force...read the source!!
WYCIWYG -- what you code is what you get!

Write a "wrapper" function with the arguments that you need to change and have that function supply the other arguments to whatever target function your program calls.

For the example in your first post:


Output

Regards,

Dave

ya.. thnx.. wrapper function will do but no other way na??

I hate to repeat myself, but:
I was talking about standard C++.

As far as "no other way," well of course there are "other ways."

Here's a possibility:

1. Decide exactly how you would like to extend the language to a case where you can define a function with default values for its ten parameters and call it by supplying only the second and fifth ones. (I can think of a couple of ways, but I would like to see your take on it.)

2. Implement that in a program that you can use to "preprocess" a source code file with this feature and make the output be a standard C++ program that can be compiled with your (or my) C++ compiler. See Footnote.

3. Generalize that to a case where you can define a function with any number of default parameters and call it with any number of arguments and have the preprocessor "fill in" the others.

4. Show us the code. Some of us would really like to see it. If your ideas have merit, maybe someone on the committee to create the next version of C++ will put that into the next language standard. (Maybe they have already thought of it, or maybe not.)

Or...
You could take suggestions about how to do it with existing language features and move on in your quest to learn how to use the language as it presently exists to implement your task.


Regards,

Dave

Footnote:
The first C++ compilers were implemented (using C) as preprocessor programs that took in C++ source code and generated C code that could be compiled by C compilers. In fact, before it was called "C++," it was called "C with Classes," and the stuff to support the "classes" part was an extension handled by the new preprocessor. This suggestion does the same with C++. See Footnote++.

Since there is no built-in mechanism that would allow the action that you are requesting, you can create a new language that is "almost like" C++ but handles your feature so that after you preprocess your source code it can be compiled with a standard C++ compiler.


Footnote++:
Whenever someone points out a "nice" thing in C++ and bemoans the fact that "you can't do that in C," I like to point out that anything that you can do in C++ can be done in C; it just may not be easy. (That's why C++ was created: to make certain things "easy.")

Footnote++:
When changing rules of a language like C++ you have to decide whether the potentially de-stabilizing effects of the change are worth the convenience. For example:

1. Would using "named" association of arguments rather than "positional" association decrease the robustness of error checking in the currently-rigorous definition of the language?

2. Would function calling with your newly-defined protocol really be more convenient than writing a "wrapper"?

3. Would your preprocessor allow various bugs not connected to your function-calling protocol to slip through?

Right now as suggested wrapper function is the correct one.


But if the combination increases then it will be combursome.
In my view
func(,,30.5,,);
If compiler is made to accept this type of function call. Then the above issue can be resolved.

while compiling the func(,,30.5,,); will be expanded to
class-name::func(10,34.5f,30.5,12,15);
then the assignment of values respective to the logic will be done.

This is the first opinion that striked me after looking at Dave's comments for standardization.

Because similar to this happens in for loop
we occasionally code for loop construct like
int x = 0;
for(;
{
x++;
}
compiler accepts this as a correct construct and creates correct instructions too.

People who are interested in possible changes in the Standards definitions of the language and its libraries might want to follow postings from the International Standards Committee on C++.

I think that those looking for up-to-date information might start here: http://www.open-std.org/jtc1/sc22/wg21/

Many discussions of "issues" may lead to some insight. Sometimes we (yes, I include myself) say things like, "Well that's just silly (or stupid, or ...). Why didn't they ..." The committee sometimes includes some rationale in the discussions about decisions.

Might make interesting reading in your spare time.

Keep in mind that even if/when a new Standard is published, it will be some time before any or all of the major compiler vendors decide whether to implement changes to comply with the new stuff.

For example the current C language standard was published in 1999. Unlike GNU, Microsoft and Borland compilers to which I have access haven't made very many changes from their previous efforts. And that's OK by me. I don't find very many serious shortcomings with the 1989/1990 C language Standard, and in general, I don't consider it a hardship to stick pretty much with the "old ways" of doing things, especially if portability is likely to be an issue.


Regards,

Dave