Quote:Original post by DrPizza
I suggested making no difference between direct and indirect function calls _at_call_time_.
You say you don't like it, because it leaves you know way of knowing if a call is direct or indirect.
At no point did I say that. I said that
for efficiencies sake, it is useful to assume that a name that refers directly to a function is immutable.Quote:
I say that's already the case, because in C++ you can't tell _at_call_time_ if a call is direct or indirect.
But that's not relevant, because in C++, a name that refers directly to a function
is immutable. The compiler can always categorise calls into direct, virtual or pointer.
That was the point I was making: if all functions are mutable, there could never be direct calls.Quote:
Quote:What's your point?
That a function object is more than just the result of dereferencing a function pointer.
How does that relate to the topic under discussion?
Quote:
Quote:Publish everything that isn't private or static-at-the-top-level. Duh.
That abuse of "static" must end.
Why? Is class-level encapsulation the
only kind of encapsulation you think should be acceptable?
Quote:
Quote:Irrevelant.
Do _any_ platforms solve it in a way you find acceptable?
C# 2.0 allows seperation of interface and implementation in a way I find acceptable.
Quote:
Quote:Untrue. Java implementations may freely allocate non-primitives on the stack when they are able to determine it is safe to do so.
Fuck what the "implementation" can do. In Java _I_ cannot stack allocate a non-primitives. In .NET and C++ I can.
So what?
Quote:
Quote:Irrelevant. The problem is not caused by polymorphism.
What's it caused by then?
Separation of interface from implementation is
obviously not related to polymorphism. The difficulty C++ has with this is caused by not being able to declare the public and private components of a class separately.
Quote:
Quote:You are wrong. It is harder to separate interface from implementation in C++ than it is in C#. C# 2.0, provides partial types, where members of the type may be defined in any file. This may be used to define stack-allocated structures as well as classes.
But C# 2.0 stack allocated types are non-polymorphic.
So what?
It doesn't matter. The
point is that C# 2.0 allows you to separate interface and implementation of
both polymorphic and non-polymorphic types without sacrificing efficiency, whilst C++ does not.
Quote:
Quote:Ideally, definitions which are obviously not the same definitions would cause rejections. But, that would be sadly unworkable. When optimising, GCC is nondeterministic: it purposely uses random numbers to choose between undecidable paths. Therefore, two functions which are actually the same may compile to different code on different runs of the compiler and be rejected.
Which is why I'd suggest that the distinction be made at the AST level. Parsing the (exact) same function multiple times will give the exact same syntax tree. The analysis needs to be recursive (to check that called functions are identical too, for instance), but it avoids issues of what the optimized code looks like.
To work reliably that requires either (1) every function used by the program be compiled at the same time, including library functions or (2) the AST be stored for all compiled functions, including library functions.
Quote:
Quote:Which is worse, conflicting identical definitions rejected or conflicting non-identical definitions not rejected? I believe the latter is much worse.
I believe the latter is unavoidable anyway.
On what basis?
Quote:
Quote:Not acceptable, unless you adhere to worse is better. The correct solution is to apply name mangling to symbols so that they identify their translation unit of origin. That way, you know that two symbols with the same name must refer to the same object.
Is that good enough?
Why should:
a.cpp:#include <list>std::list<int> alist;b.cpp:#include <list>std::list<int> blist;
result in two separate sets of code? They're identical, in spite of the different translation units. Current compilers will notice this and strip out the duplicates.
That would be wrong. C++ will know where a particular class is declared: in this case it knows that std::list<int> is declared in <list>.
Therefore, the definitions of std::list<int>'s functions can be exported as such. The linker will know they are the same function and compile them together.
Another advantage of this approach is that the compiler can safely maintain precompiled templates. Just as incremental compilation allows a compiler to avoid recompiling a function that hasn't changed, it could also allow a compiler to avoid recompiling a template that hasn't changed.
Quote:
Quote:Then, you can attach some kind of export declaration to a function to cause the linker to make its undecorated name available. It would correctly be an error for two functions to be exported with the same undecorated name.
Having to care about the "exported" name and the linker and decoration strikes me as "worse".
You don't
have to. You'd do that if you needed to export a function to a language that didn't know about the name mangling convention, such as C.
Quote:
Quote:That's just stupid. You may as well say that you don't need a standard library because you can just write your own. The point of providing a useful common base type is to make things easier.
The standard library makes lots of things easier; a common base class does not.
The standard library is irrelevant to the topic: it's not as if you can't have both. Templates, as wonderful as they are, have two fatal flaws: (1) you can't distribute them in libraries. If there's a bug in a template, then all programs compiled against the buggy definition must be recompiled against the fixed definition; and (2) you cannot distribute templates in binary form. That leaves programmers with
no way to write generic functions that can be distributed in a library. A common base type, on the other hand,
does allow such generic libraries to be written.
Quote:
Quote:There's no such thing as a 'false consistency'.
Yes there is; enforcing two things to be consistent when in fact they're different.
No. Consistent is not the antonym of different. Two things can be different but consistent. For example, my door handle turns anticlockwise to release the holding mechanism, as do the screws that connect the handle to the door. Obviously, door handles are different from screws, but their behaviour with regards to 'releasing the holding mechanism' is consistent.
Quote:
Quote:You have no point. I did not hold up Smalltalk, Java or .NET as examples of the right way of doing things, and I never even claimed that Java and .NET had a common base type.
Then what is "the right way of doing it"?
I gave an example of a possible model that I consider superior to Java or .NET's model at end of my reply to you. However, I don't think there is a "right way of doing it". For any chosen model, there will always be a program that is not well suited to that model. That's why it is important to have an elective model, so you aren't
forced to use it if it isn't suitable, but also important to be able to use the model if it is. It is somewhat ironic, I feel, that you wish to restrict the freedom of expression of C++ programmers by prohibiting them from using a common base type if it suits them, whilst at the same time criticising Java and .NET for being overly restrictive in other areas.
