What are the arguments against this

[parag_paul]

hi All,
I am working on a different language called System Verilog which is
trying to support classes as a construct,

Now our compiler allows something like the following

class C
{
void print();
}



main(){
C c1;

print(c1);

}


Now in the example above we are allowing the method to be called
independently. Is it too much to ask for to get the method depending
on the argument.
-Parag

 

[Jim Langston]

hi All,
I am working on a different language called System Verilog which is
trying to support classes as a construct,

Now our compiler allows something like the following

class C
{
void print();
}

main(){
C c1;

print(c1);

}

Now in the example above we are allowing the method to be called
independently. Is it too much to ask for to get the method depending
on the argument.

As I understand it, you are working on designing a language called System
Verilog and have a question about how something should be done. I could be
wrong, but that's how I read your question. I think a better place to ask
this question would be in comp.programming as it has nothing to do with C++
but programming in general.

 

[Guest]

hi All,
I am working on a different language called System Verilog which is
trying to support classes as a construct,

Now our compiler allows something like the following

class C
{
void print();
}



main(){
C c1;

print(c1);

}


Now in the example above we are allowing the method to be called
independently. Is it too much to ask for to get the method depending
on the argument.

Questions regarding System Verilog is better answered in a group
discussing that language, perhaps comp.lang.verilog might do?

 

[parag_paul]

Actually
I wanted to know why C++ is not alowing some thing like this so that
I can use your arguments to strengthen my view.

I dont want this to be adopted in this new language. Let me see what
the C++ experts think about the scope of doing this,

 

[Sherman Pendley]

hi All,
I am working on a different language called System Verilog which is
trying to support classes as a construct,

Now our compiler allows something like the following

class C
{
void print();
}



main(){
C c1;

print(c1);

}


Now in the example above we are allowing the method to be called
independently. Is it too much to ask for to get the method depending
on the argument.

Are you asking if the above *is* OK in C++, or if it *should* be OK in
your new language?

If you're asking the first, no, it's not OK in C++.

If you're asking the second, you should ask in a language design group,
or maybe a general programming group.

sherm--

 

[tragomaskhalos]

hi All,
I am working on a different language called System Verilog which is
trying to support classes as a construct,

Now our compiler allows something like the following

class C
{
void print();
}

main(){
C c1;

print(c1);

}

Now in the example above we are allowing the method to be called
independently. Is it too much to ask for to get the method depending
on the argument.
-Parag

Well you can do this - perhaps this is what
you meant ?

class C {/*...*/};
class D {/*...*/};
void print(C& c) { std::cout << "print a C"; }
void print(D& d) { std::cout << "print a D"; }
int main(){
C c1;
D d1;
print(c1);
print(d1);
}

 

[parag_paul]

I am asking the forum to show me the reasons and arguments that might
have been around when C++ did not implement it. My language has
implemented classes to a great extent and now this does not look like
a good feature,

I want to use the C++ arguments against this to vindicate me.
-Parag

 

[James Kanze]

I am working on a different language called System Verilog which is
trying to support classes as a construct,

Now our compiler allows something like the following

class C
{
void print();
}

main(){
C c1;

Now in the example above we are allowing the method to be called
independently.

No you don't. You still require an argument of type C. All
you've changed is the syntax.

Is it too much to ask for to get the method depending
on the argument.

Adding it to C++ today would cause some additional confusion,
for very little benefit (although perhaps in templates...).
Originally, of course, it's an arbitrary choice between two
syntaxes; presumably, Stroustrup wanted to highlight the
privileged role of the first argument. In the case of virtual
functions, too, it's a lot clearer on which argument the dynamic
resolution depends. (In a language which supports multiple
dispatch, of course, the argument swings in the other sense: if
dispatch can depend on any or all of the arguments, it's
deceptive to privilege one in the syntax.)

 

[Jim Langston]

I am asking the forum to show me the reasons and arguments that might
have been around when C++ did not implement it. My language has
implemented classes to a great extent and now this does not look like
a good feature,

I want to use the C++ arguments against this to vindicate me.

Your original code:

class C
{
void print();
}

main(){
C c1;

print(c1);

}

I think I finally understand. Instead of c1.print() you are doing
print(c1); Consider though.

class C
{
virtual void print();
virtual void print(int x);
};

class D
{
void print();
void print(int x);
operator int() { return 1; }
};

class E: public C
{
void print();
void print(int x);
};

void print( C c )
{
}

void print( int x )
{
}

int main()
{
C c1;
D d1;
E e1;

print(c1); // Which one does this call and why?
print(d1); // Which one does this call and why?
print(e1); // Which one does this call and why?
}

There are a lot of other scenarios I could come up with where it would be
arbitrary which print was called. So you'd have to come up with complicated
rules as to which one is called and why and it would just become a nightmare
as code wouldn't work as expected. Also, there may be print() declared in
other places. c1.print() states explicitly which print is to be called.
There is already some confusion with polymorphism, why add another layer
into the pot? I don't know the original reason this wasn't allowed, but I'm
glad it wasn't.

 

[James Kanze]

[...]

I think I finally understand. Instead of c1.print() you are doing
print(c1); Consider though.

[...]

There are a lot of other scenarios I could come up with where
it would be arbitrary which print was called. So you'd have
to come up with complicated rules as to which one is called
and why and it would just become a nightmare as code wouldn't
work as expected.

Not really. The difference is purely syntactic. Formally, one
could define the language so that f(a) and a.f() were synonyms;
one could even go further, and allow things like f(a, b) to be
written (a, b).f().

C++ doesn't do this, because it wants to stress the difference
between member functions and other functions. Ada 95 only
supports the f(a) notation---and f(a) in Ada 95 works exactly
like a.f() in C++.

Also, there may be print() declared in other places.
c1.print() states explicitly which print is to be called.

No more so that print(c1). In both cases, it depends on the
type of c1. And there's nothing fundamental which would prevent
it from depending on the dynamic type, although C++ doesn't
support it.

The real difference in C++ is that when I write c1.print(), the
print function can be resolved on the dynamic type of c1, and
can access private data. Other mechanisms can be conceived of
for both; Ada 95 doesn't have the c1.print() syntax, but
supports both virtual functions and private data.

There is already some confusion with polymorphism, why add
another layer into the pot? I don't know the original reason
this wasn't allowed, but I'm glad it wasn't.

There are arguments both ways. Is it normal that I have to use
a.f(), but g(a), when both f and g manipulate a, just because
f() is a member (and has access to private data), but g() isn't.
Or for a more complete example: is it normal that I have to
write someString.append( "abcd" ), but toUpper( someString )?
And what implications does this have for templates?

Having said that, I, too, find it more explicit to set the
"owning" argument off by putting it in front of the function, a
la C++.