OOP Language for OS Development

[Calum]

Do you at least ever heard of Eiffel? I would say that C++ is far from
matching Eiffel power.

In terms of "raw power", both languages are Turing powerful (if we
ignore the "can a finite computer be Turing complete" pedentry). So
power in what sense? What's really nice and neat to do in Eiffel that
is difficult in C++? Give some source code, or at the very least a link
to an article.

Can for example Eiffel implement its own allocators, or is its type
system itself Turing complete (C++ templates)?

 

[John English]

In terms of "raw power", both languages are Turing powerful (if we
ignore the "can a finite computer be Turing complete" pedentry). So
power in what sense? What's really nice and neat to do in Eiffel that
is difficult in C++? Give some source code, or at the very least a link
to an article.

http://burks.bton.ac.uk/burks/language/eiffel/index.htm

---------------------------------------------------------------------
John English | mailto:[email protected]
Senior Lecturer | http://www.it.bton.ac.uk/staff/je
School of Computing Maths & IS | ** NON-PROFIT CD FOR CS STUDENTS **
University of Brighton | -- see http://burks.bton.ac.uk
---------------------------------------------------------------------

 

[Philippe Ribet]

In terms of "raw power", both languages are Turing powerful (if we
ignore the "can a finite computer be Turing complete" pedentry). So
power in what sense? What's really nice and neat to do in Eiffel that
is difficult in C++? Give some source code, or at the very least a link
to an article.

It's obvious here that language power means expressivity.

Can for example Eiffel implement its own allocators, or is its type
system itself Turing complete (C++ templates)?

Could you please re-formulate questions about allocators and type
system? I do not understand what you mean, sorry.


--
Philippe Ribet



The README file said
"Requires Windows 95, NT 4.0, or better."
So... I installed it on Linux!

 

[Calum]

It's obvious here that language power means expressivity.

I am in no doubt that Eiffel is cleaner safer language, however that's
not quite the same as power.

So what can you express in Eiffel that cannot be expressed in C++?
[Actually, resolving name-clashes in multiple inheritance is one,
contracts is another.] But are these fundamentally difficult in C++, or
just a little uglier?

Could you please re-formulate questions about allocators and type
system? I do not understand what you mean, sorry.

C++ allows you to specify where in memory an object resides. This is a
low-level feature that most people would not use, but gives C-like
performance since you can cache-localize data, and implement more
efficient memory managers where you know the allocation patterns.

Are parameterized types in Eiffel as flexible as those in C++?

 

[Steven Wurster]

I am in no doubt that Eiffel is cleaner safer language, however that's
not quite the same as power.

So what can you express in Eiffel that cannot be expressed in C++?
[Actually, resolving name-clashes in multiple inheritance is one,
contracts is another.] But are these fundamentally difficult in C++, or
just a little uglier?

Contracting is fundamentally difficult in C++, because adhering to the
inheritance rules of contracting is not easily accomplished. Doing so
requires a lot of preprocessor directives/macros, and makes the code
extremely ugly.

Resolving name clashes in C++ *can* be difficult if there are a lot of
them, and you need to make sweeping changes. Automated search and
replace can help, of course, but may not do everything you need.
Otherwise, it's just flat out ugly in C++.

Eiffel supports selective exporting, covariant argument redefinition,
constrained genericity, and has polymorphism by default without any
added performance penalty. C++ supports none of these. Eiffel also
fully supports the Open Closed Principle, while C++ does not (due to
requirement of virtual keyword and private access limitations). None
of these issues really affect the choice about whether one can develop
an OS with them or not.

Are parameterized types in Eiffel as flexible as those in C++?

Not really. Eiffel supports constrained genericity, but it does not
support expression templates like C++ does. Of course, expression
templates are really a side-effect in C++, as they were not part of
the original intention. They are great for performance and expressive
power, but they are damn ugly.

Steve

 

[Hyman Rosen]

Eiffel supports covariant argument redefinition

Which is a huge mistake, since it menas that one can
no longer supply a derived class to something which
expects a base class.

 

[Georg Bauhaus]

: I am in no doubt that Eiffel is cleaner safer language, however that's
: not quite the same as power.
:
: So what can you express in Eiffel that cannot be expressed in C++?
: [Actually, resolving name-clashes in multiple inheritance is one,
: contracts is another.] But are these fundamentally difficult in C++, or
: just a little uglier?

How would you write "once" routines in C++?
How about the fine grained visibility control (where each feature
can be made visible to only a specified set of types)?

:
:>> Can for example Eiffel implement its own allocators, or is its type
:>> system itself Turing complete (C++ templates)?
:>
:>
:> Could you please re-formulate questions about allocators and type
:> system? I do not understand what you mean, sorry.
:
: C++ allows you to specify where in memory an object resides. This is a
: low-level feature that most people would not use, but gives C-like
: performance since you can cache-localize data, and implement more
: efficient memory managers where you know the allocation patterns.
:
: Are parameterized types in Eiffel as flexible as those in C++?

They are different I think. Can you express

deferred class C [P -> T]
feature foo(x: P): P is deferred end
end -- C

in C++?

Then there is currently a (justified) limitation in C++ with
float parameters. This is not the case in Ada generics.

georg

 

[Hyman Rosen]

How would you write "once" routines in C++?

With a static method containing a static value, of course.

class UponATime
{
static double Once(/* args */)
{
static double value = /* some calculation */;
return value;
}
};

It appears from my looking up what once functions do,
that arguments to the call are irrelevant for determining
whether it should be re-executed. If so, that's another
example of a hideous language design choice made by Eiffel.

How about the fine grained visibility control (where each feature
can be made visible to only a specified set of types)?

Speaking of hideous design decisions. This whole concept
of classes having fine-grained dictatorial control over
whom they allow access to their innards is more than a
little silly.

They are different I think. Can you express
deferred class C [P -> T]
feature foo(x: P): P is deferred end
end -- C
in C++?

Sure. You just don't define the method, and if it gets used,
the linker will complain. Or if it's virtual, then you can
make it abstract.

template <typename T>
struct C
{
T foo(T x);
virtual T bar(T x) = 0;
};

 

[Georg Bauhaus]

: Georg Bauhaus wrote:
:> How would you write "once" routines in C++?
:
: With a static method containing a static value, of course.

So in the general case where the method will have (side)
effects on object variables I use an if (once) {...} with a
static bool once, I guess? Whatever suggests the necessity
of ONCE in a language, if it is necessary then being able
to write ONCE might have an advantage in my view.

:> They are different I think. Can you express
:> deferred class C [P -> T]
:> feature foo(x: P): P is deferred end
:> end -- C
:> in C++?
:
: Sure. You just don't define the method, and if it gets used,
: the linker will complain.

So the compiler, compiling seperately, will not know which types
can be passed to some_C.foo before the linker is run.

 

[Hyman Rosen]

So in the general case where the method will have (side)
effects on object variables I use an if (once) {...} with a
static bool once, I guess?

What do you mean? A static variable in a function is initialized
the first time control passes through the declarartion, and never
again. So my code is equivalent to your ONCE method - the first
time the function is called, the variable will be initialized, so
you can plant all of the code you want to execute once as part of
that initialization. After that, no matter how many times you call
the function, the initialization code won't be executed.

Whatever suggests the necessity of ONCE in a language, if it is
necessary then being able to write ONCE might have an advantage
in my view.

*Shrug* I'm not thrilled with a language feature which allows the
compiler to replace a call to f(2) with an earlier call to f(1),
but maybe that's just me. Ada allows you to decorate a function
with Pragma Pure, and then it can elide multiple calls to a function
if it is called with the same parameters (regardless of whether the
function has side effects).

So the compiler, compiling seperately, will not know which types
can be passed to some_C.foo before the linker is run.

In C++, there is no some_C.foo. There is a some_C<T>.foo for each
type T that some_C is instantiated with. Each one is a logically
separate function, and they have nothing to do with each other.

 

[Brian_Heilig]

Hyman Rosen:

Steven Wurster:

Which is a huge mistake, since it menas that one can
no longer supply a derived class to something which
expects a base class.

Either I don't understand your post or you are mistaken. If the
derived class conforms to (inherits from) the parameter's type then
there is no problem.

Brian

 

[Hyman Rosen]

Either I don't understand your post or you are mistaken. If the
derived class conforms to (inherits from) the parameter's type then
there is no problem.

In Eiffel, Derived::Foo(Derived) overrides Base::Foo(Base).
That means that if you have a Base object, and you call
some_base_reference.Foo(some_other_base_reference), the call
looks correct, but if some_base_reference is really a Derived
and some_other_base_reference is not a Derived, you have an
error.

It's a horrible misfeature, but its proponents cling to it
tenaciously, and they have spent years trying to figure out
workarounds so that the errors can be caught.

 

[Brian_Heilig]

With a static method containing a static value, of course.

class UponATime
{
static double Once(/* args */)
{
static double value = /* some calculation */;
return value;
}
};

You are nowhere near the expressivity of once routines:
1. The body of `Once' will be executed with each call except for the
stuff after the static declaration. In other words, you must put all
of your calculation behind the equal sign!
2. You still need once per thread, once per object, and manual once
functions.

It appears from my looking up what once functions do,
that arguments to the call are irrelevant for determining
whether it should be re-executed. If so, that's another
example of a hideous language design choice made by Eiffel.

This is of course a consequence of your misunderstanding of once
functions.

Speaking of hideous design decisions. This whole concept
of classes having fine-grained dictatorial control over
whom they allow access to their innards is more than a
little silly.

You're funny.

template <typename T>
struct C
{
T foo(T x);
virtual T bar(T x) = 0;
};

You missed the constrained generic parameter. G -> T means that G is
the generic type and it must conform to T. I don't think C++ templates
can emulate constrained generics yet, but I could be wrong.

C++ will never reach the expressive power of Eiffel, but then again,
you can't make an Eiffel compiler solve factorials, so maybe you win?

Brian

 

[Steven Wurster]

Which is a huge mistake, since it menas that one can
no longer supply a derived class to something which
expects a base class.

That's not true. I've done it plenty of times in Eiffel, even with
covariant redefinition. Redefinition isn't necessary, but is
supported. In fact, in many cases, it's the best solution.

Let's get off this language holy war argument.

 

[Steven Wurster]

It appears from my looking up what once functions do,
that arguments to the call are irrelevant for determining
whether it should be re-executed. If so, that's another
example of a hideous language design choice made by Eiffel.

Explain why. Don't just say it's 'hideous' without giving rationale.

Speaking of hideous design decisions. This whole concept
of classes having fine-grained dictatorial control over
whom they allow access to their innards is more than a
little silly.

Why? You need to provide your reason for your opinion. Selective
exporting is way ahead of the public/protected/private of C++ and
Java. A good example is the visitor design pattern, in which the
visit routines should only be available to the accepting classes.
This is easily done using selective exports in Eiffel. But in C++ one
must either make the routines public, which violates encapsulation, or
make *every* accepting class a friend, which violates information
hiding and requires a lot of programmer bookkeeping.

Steve

 

[Brian_Heilig]

Hi All,
I am developing an object oriented OS code-named "ikbocs".
1) What are the pros and cons of the following languages interms of
Effectiveness on System Programming, Object Orientedness etc ?
(Simula, Smalltalk, Modula-3, Eiffel, Sather, C++)
I suppose Java is not suitable for Sys. Programming.

2) Which OOP language would be better for OS development?

TIA
KingIshu

Eiffel Pros:
Design by Contract - a process and a language, Design by Contract
defines things like software correctness, software errors, and
exceptions like no other method. Integration into the language
dramatically helps with documentation and debugging. Many other
reasons why DbC alone puts Eiffel near the top of the list. No problem
with buffer overruns in Eiffel (the number one security risk in
operating systems), thanks to DbC.
Tight language design - all language features can be traced back to
about 10 basic principles. Eiffel has been systematically designed as
a language making it concise, easy to learn and easy to use.
Strict type system - operating systems require secure and correct
code. With Eiffel you'll catch more bugs at compile time. This strict
system makes it more difficult to design your code, but the benefit
greatly outweighs the increased effort.

Eiffel Cons (related to OSes):
There is no turnkey Eiffel compiler for you to use for operating
systems. All the current compilers are system-oriented, that is, they
generate systems, which for example have command-line arguments and
garbage collectors. Unless I'm mistaken this is probably the show
stopper.
I'm pretty sure it is impossible to write an entire OS completely in
Eiffel. Number one reason, Eiffel has no method for declaring
interrupt handlers. The good news is that Eiffel integrates with other
languages easily (C for example which has an interrupt keyword).
If efficiency is your number one priority Eiffel may not be for you.
SmartEiffel and ISE Eiffel generate very efficient code, but I don't
think it meets the demands of a CPU scheduler, for example.

Brian

 

[Georg Bauhaus]

: What do you mean? A static variable in a function is initialized
: the first time control passes through the declarartion, and never
: again. So my code is equivalent to your ONCE method -

O.K., though that will require another non-local private function?

 

[Robert C. Martin]

In Eiffel, Derived::Foo(Derived) overrides Base::Foo(Base).
That means that if you have a Base object, and you call
some_base_reference.Foo(some_other_base_reference), the call
looks correct, but if some_base_reference is really a Derived
and some_other_base_reference is not a Derived, you have an
error.

It's a horrible misfeature, but its proponents cling to it
tenaciously, and they have spent years trying to figure out
workarounds so that the errors can be caught.

It's an LSP violation. Code written to deal with base classes can be
broken by new derivatives that can't accept the arguments that the
base can. This makes it hard to follow the Open Closed Principle
which says that you should try to make modules extensible without
having to change them.



-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716

"Distinguishing between the author
and the writing is the essence of civilized debate."
-- Daniel Parker

 

[JKop]

Steven Wurster posted:

I am in no doubt that Eiffel is cleaner safer language, however that's
not quite the same as power.

So what can you express in Eiffel that cannot be expressed in C++?
[Actually, resolving name-clashes in multiple inheritance is one,
contracts is another.] But are these fundamentally difficult in C++,
or just a little uglier?

Contracting is fundamentally difficult in C++, because adhering to the
inheritance rules of contracting is not easily accomplished. Doing so
requires a lot of preprocessor directives/macros, and makes the code
extremely ugly.

Resolving name clashes in C++ *can* be difficult if there are a lot of
them, and you need to make sweeping changes. Automated search and
replace can help, of course, but may not do everything you need.
Otherwise, it's just flat out ugly in C++.

Eiffel supports selective exporting, covariant argument redefinition,
constrained genericity, and has polymorphism by default without any
added performance penalty. C++ supports none of these. Eiffel also
fully supports the Open Closed Principle, while C++ does not (due to
requirement of virtual keyword and private access limitations). None
of these issues really affect the choice about whether one can develop
an OS with them or not.

Are parameterized types in Eiffel as flexible as those in C++?

Not really. Eiffel supports constrained genericity, but it does not
support expression templates like C++ does. Of course, expression
templates are really a side-effect in C++, as they were not part of
the original intention. They are great for performance and expressive
power, but they are damn ugly.

Steve

Why the hell would you want automatic polymorphism? There's times
when I want functions NOT to be polymorphic!

-JKop

 

[Greg C]

Why the hell would you want automatic polymorphism? There's times
when I want functions NOT to be polymorphic!

-JKop

If the polymorphism is determined automatically, you don't need to
plug "virtual" keywords everywhere, and you don't need to spend any
time guessing as to which function should be allowed to be
polymorphic. Also, by determining this automatically, the Eiffel
compiler can optimize calls to eliminate polymorphism where it's not
needed. This is something that would be very difficult or impossible
for a C++ compiler to accomplish. If you know you don't want a
function to be polymorphic, then in Eiffel you declare it frozen.

Greg C