defalut arguments

[marriboina]

why default arguments must be trialing arguments?
why can't be as leading or middle arguments in argument list?

[Mitsukai]

?? what are you trieing to say

[DragForce]

To avoid problems with ambiguity. Suppose you have function of 5 integer arguments and second and forth are optional. In the program this function is caleed with 4 parameters. How can compiler find out which parameter has to have the default value

[Mitsukai]

after the second all parameters must be have a default variable. on my compiler atleast

[MrViggy]

after the second all parameters must be have a default variable. on my compiler atleast

On all compilers. I believe it might even be a part of the standard.

As Dragforce said, this is to avoid ambiguity.

void someFunc(int a, int b, int c = 4, int d = 5, int e);
...
someFunc(10, 11, 13, 14);

In the call to 'someFunc' what paramaters get what values? Which one is the parameter that I wanted to have the default value?

VIggy

[Graham]

It is, indeed, part of the standard. Personally, I'd like the standard to allow something like

someFunc(10, 11, , 13, 14);

that is, args are matched strictly in order, with a blank argument meaning "accept the default". In this case, Viggy's example would be an error, because there's no match for "e".

[SuperKoko]

It is, indeed, part of the standard. Personally, I'd like the standard to allow something like

Yes, IMHO, it would not complicate much the language, and could be a real benefit.
An, alternative would be:

someFunc(10,11,default,13,14);

[Mitsukai]

C++ stndards shuld also allow static class operator and a parent class operator.

[SuperKoko]

C++ stndards shuld also allow static class operator and a parent class operator.

I don't see any practical application of static member operators.
The this parameter is an implicit parameter of the operator.
Would you want to have an operator whose one parameter (maybe the only parameter) is missing?
Except, in some very particular cases, for operator () in functors.
And, in that case, a non-static operator () does not harm!

parent class operator?
I don't see what you mean.
Perhaps the fact that operators are inherited?
But, actually operators are already inherited!

[Mitsukai]

in my OOP programming OpenGL i had a need for static operators! just that its not logical doesntmean its not needed, thats why C++ got big in first place, the flexibility and the usefullness, so why limit operators to non-statics.
and with parent i mean this:
class A{ int c; class B{ B(void){ parent->c = 123 } }; };

[RoboTact]

For this to make sense enclosed class must actually have parent object, which it doesn't. You can provide it directly simply enough.

[SuperKoko]

in my OOP programming OpenGL i had a need for static operators

Please share the code!

class A{ int c; class B{ B(void){ parent->c = 123 } }; };

You misunderstood the concept of nested class!
There is no one-to-one correspondance between instances of A and B!
A and B have independent instances.
Declaring B inside A, have effect only on the scope of B.

In order to have this one-to-one correspondance, you can simply pass the this pointer of A in a constructor of B:

class A
{
int c; // note that c must precede b in this class definition, otherwise, behaviour is undefined!
B b;
class B{ B(A* parent){ parent->c = 123 } };
A():b(this) {}
};

I already had something similar.
IMHO, it is perfectly clean, and does not require any language change!

I experienced similar problems that were perfectly resolved by private inheritance (knowing that C++ allows multiple inheritance).

It is useless to bloat the language with some seldomly used features that are perfectly emulated without language change.

[RoboTact]

It is useless to bloat the language with some seldomly used features that are perfectly emulated without language change.

It's OK for C++.

[Mitsukai]

Please share the code!


You misunderstood the concept of nested class!
There is no one-to-one correspondance between instances of A and B!
A and B have independent instances.
Declaring B inside A, have effect only on the scope of B.

In order to have this one-to-one correspondance, you can simply pass the this pointer of A in a constructor of B:

class A
{
int c; // note that c must precede b in this class definition, otherwise, behaviour is undefined!
B b;
class B{ B(A* parent){ parent->c = 123 } };
A():b(this) {}
};

I already had something similar.
IMHO, it is perfectly clean, and does not require any language change!

I experienced similar problems that were perfectly resolved by private inheritance (knowing that C++ allows multiple inheritance).

It is useless to bloat the language with some seldomly used features that are perfectly emulated without language change.

i know about that, i sayd C++ shuld have a parent operator without having the need of the constructor like you just did

[SuperKoko]

It's OK for C++.

C++ has a few useless features inherited from C, but otherwise, has a full set of general purpose features that allow anybody to write very high-level (i.e. very abstract) code.
From that, C++ is extended by librairies!
No need for builtin smart pointers : A library can emulated it!
No need for builtin dynamic array : there is std::vector!
etc...
With templates, you can really do many things that are builtin in other languages.

i know about that, i sayd C++ shuld have a parent operator without having the need of the constructor like you just did

The problem, is that this thing would be only used by very few programmers.
This feature does not increase the abstraction level, nor increas maintainability. That is, the workaround does loose nothing.
It is a bit more verbose, but that is not a problem. It will only increase a bit your program (except if your program is full of design flaws), at the cost of your fingers.

Hundreds other minor features avoiding manual writing in very specific cases, are proposed on comp.std.c++.
But there are far too many. That would increase the language specification by a factor ten!

C++ must be learnable and implementable and extensible!
Nowadays, C++ is already very extensible (the boost library is a proof).
The future C++ standard will focus more on librairies than the core language.

If you want to preserve your fingers from typing, you'll gain much more, using these horrible macos:

#define cl class
#define fr for
#define wl while
typedef char ch;
typedef int it;
typedef double dl;
// ...