I
Ioannis Vranos
Dr. Adrian Wrigley said:
In the standard library containers and algorithms case you do not pass
any function to the container. operator< is implicitly used.
Teaching new tricks to an old dog (C++ -->Ada)
In the standard library containers and algorithms case you do not pass
any function to the container. operator< is implicitly used.
D
Dr. Adrian Wrigley
The comparison operator here seems to be a generic formal function
parameter with a default value. This must be available at instantiation.
The operator becomes part of the interface (implicitly or explicitly) for
any code instantiating the std::map. Where does the code for the
comparison operator go? It *has* to go at the point the class
is defined. This could be at the other end of a hierarchy of
generic instantiations. The result is that the implementation
requirement (needs a comparison operator) has propagated up the
generic hierarchy to some otherwise completely independent code as an
interface requirement. I'm sorry I can't explain this any better!
(should I give a code example?)
K
kevin cline
But not all lines of source code are created equally. Written in a
more expressive language the application might be only half that size,
or most likely even less.
D
Dmitry A. Kazakov
It can be formulated in two words: "contract model" is what C++ templates
lack.
K
kevin cline
included.Martin said:
No surprise there. The C++ standard covers the C++ standard library.
Personally I prefer slimmer languages and fatter libraries whenever
possible.
I
Ioannis Vranos
Dr. Adrian Wrigley said:
Yes. However if you later convert to a hash container, it can remain
around unused in the particular container.
Yes, also operator< is used to all containers and algorithms where a
comparison takes place, like sorting algorithms (std::sort,
std::stable_sort, etc).
I can not understand how this could be avoided for such operations and
containers, since a comparison is required.
G
Georg Bauhaus
Dr. Adrian Wrigley said:
I think this description is o.K. for Ada, but perhaps not
for C++. E.g. you can place the following in three different
files (modules), somewhat like in Ada, and you don't have
to write the < into the module containing the compared type.
// 1
#include "comp.h"
#include <map>
bool operator< (V a, V b) { return a.val() < b.val(); }
int main()
{
std::map<V, float> m;
V key1, key2 = V(3);
m[key1] = 1.0;
m[key2] = 1.0;
return 0;
}
// 2
class V {
int v;
public:
V() : v(0) {}
V(int val) : v(val) {}
int val() const;
};
// 3
#include "comp.h"
int V::val() const {
return v;
}
Georg
I
Ioannis Vranos
kevin said:
However C++ has also the ideal to be able to write these libraries with
the language itself.
R
Robert A Duff
CTips said:
I beg to differ. Uplevel references can be implemented as efficiently
as parameter passing (which is what you normally do in C-family
languages as a substitute). And it can cost nothing when not used.
It can also cost nothing when the procedures involved can be inlined
(which is a very common case -- the reason I'm writing a nested procedure
is usually so I can pass it to an iterator, and both the iterator and
the nested procedure are usually small enough to deserve inlining).
(I'm not a big fan of displays, by the way.)
This seems like a nonsequitor -- thread-private storage and uplevel
references are different things, with different (though somewhat
related) purposes. C and C++ have neither, which can make using thread
packages painful, though gcc supports uplevel references (for both C and
Ada, and I think C++ also).
And having implemented both, I'd say thread-private storage is
generally more expensive than uplevel references. What's your
much cheaper solution?
- Bob
G
Greg Comeau
How many current compiler pass current ACATS test,
at least those that are required.
Obviously, indeed
One's leaping right to mind are Perennial, PlumHall and Dinkumware's,
as commercial products. There's other too, and other open source
regressions, etc too.
Yes, I'm hearing that loud and clear.
G
Georg Bauhaus
Dmitry said:
I think "explicit contract model" is slightly better, and perhaps
you can say something about the closure that the compiler needs
to find out whether a contract is fulfilled (Can_Copy etc.)?
Georg
R
Robert A Duff
^not
Of course I meant "not" above. Sorry again.
Hmm. I had forgotten that about Bliss. I did a fair amount of Bliss
programming a long time ago...
So it's sort of like a "static" variable declared inside a C function --
it's nested with respect to visibility, but its lifetime is not,
so its run-time semantics are just as if declared at top level.
Well thanks for answering. ;-)
- Bob
Of course I meant "not" above. Sorry again.
Hmm. I had forgotten that about Bliss. I did a fair amount of Bliss
programming a long time ago...
So it's sort of like a "static" variable declared inside a C function --
it's nested with respect to visibility, but its lifetime is not,
so its run-time semantics are just as if declared at top level.
there is some benefit provided by just the reduced visibility of the
nested function. I know for sure that I can call my nested function
RETRIEVE_STATUS without worrying about a conflict with something else
of the first name.
This is _certainly_ not a Bliss vs. Ada argument, but for me it is
a Bliss vs. C argument.
Please remember, however, that I only mentioned it because you asked
Well thanks for answering. ;-)
- Bob
D
Dr. Adrian Wrigley
OK. How about a trivial but reasonable example:
#include <time.h>
#include <map>
struct interval {
tm start, finish;
};
int main()
{
std::map<interval, float> hash;
interval fred;
// set fred here!
hash[fred] = 0.123;
}
No suitable place to put the compare operator!
K
kevin cline
Martin said:
No, people are hooked on getting work done with what they perceive to
be the least possible effort and minimal risk. So they pick what they
know, what their colleagues know, what has been known to work in the
past in their application domain. Ada rarely enters the picture. They
don't know Ada, no one they know uses Ada, no one they read advocates
Ada.
For a lot of commerical applications Perl or Python or Ruby or another
higher level language would be considerably better than Java, or C++,
or C#, but mostly they aren't used either. Even though they are
considerably more popular than Ada, they still aren't popular enough
for risk-averse project managers.
G
Greg Comeau
Other posts seems to disagree. Please clarify for us.
Also include how and why your company is the _official_ lab.
(I'm not challenging you, but seems to me a mixed message
is coming through this thread.)
K
kevin cline
Dr. Adrian Wrigley said:
Actually, it doesn't. If not defined as a member function in the
class, it can be defined as a free function wherever convenient. Or a
custom comparison function can be defined and specified in the
instantiation.
Either this:
class Stuff {
public:
bool operator<(const Stuff& rhs);
};
or this:
bool operator<(const Stuff& lhs, const Stuff& rhs);
will work with this:
std::set<Stuff> allStuff;
Or you can define a special comparator to be used for a particular
instantiation, like this:
struct compareStuff()
{
bool operator()(const Stuff& lhs, const Stuff& rhs) { ... }
}
std::set<Stuff, compareStuff> zeds;
R
Robert A Duff
The fact that "<" can be implicitly passed to the template/generic (in
C++/Ada) is not relevant; Dr. Wrigley's point is that it has to be
there.
Because the "<" (or Hash) needs to know the internals of the thing.
In other words, at the point where you declare a type, you have to think
ahead: this type might want to live inside one of those containers, so
I'd better define the necessary operations.
I agree -- that's a pain.
The only way around it, it seems to me, is to have the compiler
automatically create a hash function (or something) for every type --
after all, you can't expect to create these kinds of containers without
a hash function (or something, like "<"), whether the user is required
to write it or not. Lots of languages do something like that, but I
don't know of any such that emphasize efficiency like C++ and Ada.
Also, in the "<" case, the "<" might mean something important
(so you can iterate through the container in a sensible order),
and I don't see how the compiler can be expected to guess what order
that is.
I think I understand what you mean.
Which is both a benefit and a drawback. C++ templates are somewhat more
powerful that Ada generics, because of the lack of contract model, and
implicit instantiation.
But I don't think that addresses Dr. Wrigley's complaint (which applies
to both Ada and C++).
- Bob
C++/Ada) is not relevant; Dr. Wrigley's point is that it has to be
there.
Because the "<" (or Hash) needs to know the internals of the thing.
In other words, at the point where you declare a type, you have to think
ahead: this type might want to live inside one of those containers, so
I'd better define the necessary operations.
I agree -- that's a pain.
The only way around it, it seems to me, is to have the compiler
automatically create a hash function (or something) for every type --
after all, you can't expect to create these kinds of containers without
a hash function (or something, like "<"), whether the user is required
to write it or not. Lots of languages do something like that, but I
don't know of any such that emphasize efficiency like C++ and Ada.
Also, in the "<" case, the "<" might mean something important
(so you can iterate through the container in a sensible order),
and I don't see how the compiler can be expected to guess what order
that is.
I think I understand what you mean.
Which is both a benefit and a drawback. C++ templates are somewhat more
powerful that Ada generics, because of the lack of contract model, and
implicit instantiation.
But I don't think that addresses Dr. Wrigley's complaint (which applies
to both Ada and C++).
- Bob
C
CTips
Dr. Adrian Wrigley said:
My knowledge of this is a little dated and hazy, so I could be wrong.
If we're doing something like:
foo()
{
int x, y;
bar()
{
int y;
gah()
{
use(x), use(y);
}
}
}
then, at run-time, in use(x), x comes from the stack-frame of the
nearest invocation of foo() on the stack, and in use(y), y comes from
the stack-frame of the nearest invocation of bar().
There has to be a mechanism to identify the nearest invocation of
foo()/bar(). There are, if I remember correctly, 4 mechanisms to find
the invocation:
- dynamic chaining: you just follow the back-chain pointers, stepping
through all stack frames, till you come to the right stack frame.
- static chianing: you maintain a separate chain (the static chain) that
directly link to the stack frame of the enclosing functions. Thus the
static chain for gah() would have the last invocation of bar() followed
by the last invocation of foo().
- display: somewhat like the static chain, except its an array instead
of a list
- currying (?): this one I'm really hazy about, but, roughly, you passed
pointers to the correct uplevel variables as extra arguments to the
functions. Thus bar would be passed the pointer to x and gah would be
passed pointers to x and y, as well as their other arguments, or
something like that.
There were some additional nastinesses dealing with what happens when a
nested function is passed as an argument
Depending on the techinques, you either pay whenever you access
variables of enclosing functions, or you pay to maintain the
data-structures [static-chain,display] which make this access cheaper,
or both.
On some implementations (on RISC architectures) a register is reserved
for the static-chain. This means one less register for *every* function
(or maybe only for enclosed functions?) when used with a language that
support this kind of nested functions.
C++ probably left it out because of its C heritage, while Ada probably
dropped it in because of its Pascal heritage. IMHO, its probably not
worth the cost.
D
Dr. Adrian Wrigley
OK. Maybe there are circumstances where it could, in practice, go
somewhere else. If some of the sorted values are in the private
part, I guess you could use a friend class(?). But in the particular
case of generic hierarchies, there is probably nowhere convenient
Even in simple cases, the encapsulation has to be broken (see the
time interval example).
R
Robert A Duff
Well, let's see. Off the top of my head, Ada compilers are available
from Sofcheck (that's my company), AdaCore (that's the free software
version; they make their money by providing support), Greenhills
(which uses the SofCheck Ada front end, and supports many embedded
targets), Aonix (also uses the SofCheck front end), RR Software,
DDC-I, ICSC (sp?), IBM... (Did I forget some?)
I don't know which ones pass (the required portion of) the ACATS.
My guess is: all of them.
(The reason there are ACATS tests that are not required is that some
portions of the language standard are optional. The standard has
optional annexes for various specialized purposes: real-time,
information systems, safety critical, etc.)
By the way, SofCheck's current focus is not Ada compilers: we're
concentrating on static analysis tools for Java and Ada and eventually
other languages such as C++. But we still make most of our revenue
from the compiler side of the business.
....but of course there's a lot of market pressure to produce
standard-conforming compilers, for those languages that have official
standards (Ada, C, C++, Fortran, Cobol, etc).
- Bob