"Reader Q&A: “Will C++ remain indispensable…?”" by Herb Sutter

[Öö Tiib]

I disagree. It's true that no language is a silver bullet, and it's
true that you can do very decent work in C. But it's also true that
you can do that work a whole lot better in C++. Policies and tools
are not replacements (unless the tool is a C++ compiler).

Indeed /I/ can do some work lot better and faster in C++ than in C and
some work lot better in Python than in C++. The tools are different.
I merely said that none of the tools sucks on its own. It is always
the specialist who sucks in using those. She has naive imagination about
tool and lacks skills, instructions, procedures, supporting tools and
she has piles of examples (even tutorials) that demonstrate bad habits
of its usage. Nothing warns her and so she misuses the tool and later
whines how it sucks. That is typical story how "C++ sucks" btw.

 

[Melzzzzz]

I hope that Rust will eventually fill that hole. It's not mature yet,
but evolving quickly.

Heh, my first impression of Rust is that language is a bit paranoid
in enforcing safety ... it is about same relation to c++ as is c++ to
c
Fortunately, there are raw pointers, but unfortunately not pointer
arithmetic.
Therefore, only way to index into buffer, is to convert raw
pointer to int, perform addition and then convert result
back to pointer
Of course you convert vector to raw pointer first
This is only way to index array without bounds checking ...
One thing that must be done, also, is parsing of C header files,
as parsing them by hand is not exactly convenient..
Besides that, there are many nice things, enums are pretty
powerful, there are native tuples, also unique_ptr, shared_ptr
and move semantics are part of language..
Many things from functional languages are there too.
There are no headers.
compiler is pretty helpful ...
for example if you pass unique_ptr type to function
and use it later compiler gives error.

 

[Bienlein]

I took my own advice a few months ago and

converted a Python test program to a C++ program. Hasn't
paid off yet, but long term it may.

You might consider Go as an alternative to Python. It's a lot faster than Python and much more productive than C++.

Never mind speed -- what other mainstream languages are C-compatible
but suck less than C? What other mainstream languages are high-level,
yet provide static typing?

There is D (dlang.org), which is high-level, statically typed and geared towards systems programming. But suffering has to be a lot higher for industry to move away from C++ to another language or some larger company betting on D or whatever.

And btw, I wrote a Smalltalk to C++ converter several
years because of Win16 issues and performance.

Really? How did you convert Smalltalk closures to C++ and becomes, performs? Did you also convert the extensive Smalltalk standard class library to C++? Smalltalk has a garbage collector, so there is no new and delete in the code. Your converter just inserted them automatically ...

-- Bienlein

 

[Lynn McGuire]

Really? How did you convert Smalltalk closures to C++
and becomes, performs? Did you also convert the extensive
Smalltalk standard class library to C++? Smalltalk has a
garbage collector, so there is no new and delete in the code.
Your converter just inserted them automatically ...

-- Bienlein

My converter did about 80-90% of the code conversion
and the rest we did by hand. Took three people
working full time for 1.5 years. Our smalltalk
variant was the old Whitewater Actor language which
used a pascal like syntax and made things much, much
easier. We went from 400K lines of Actor to 500K
lines of C++ and are now at 850K lines.

Basically, I typed all variables as "ObjPtr *" and
we retyped all those variables as we figured out
what they really were. In a C++ program, the vast
majority of variables are automatic and do not
require new / delete. And yes, all the new /
delete sequences had to be coded by hand. We do
not have garbage collection anymore, but, it turns
out that we do not need it.

All of the library code was easily translated to
use the C++ standard library. I just cannot say
enough good about the C++ standard library.

The bigger problem was the user interface library
which we did port to C++ and still use.

Lynn

 

[Melzzzzz]

Rust vtable implementation is currently broken and does not work.
It works without inheritance, but with inheritance, it must
impose run time cost as dynamically finding proper table
for particular method enforces dynamic cast whenever method
is called. This is because they carry single pointer
to vtable paired with pointer to object and currently there
is no way to dispatch to vtable of base type...
Also there is problem with up casting, since pointer does
not knows it's type it is impossible to perform up casting
to base too.
So either up cast or calling base method must involve
dynamic cast, since vtable pointer is not part of
the object.
And currently there is no way to perform dynamic cast.

 

[Melzzzzz]

Rust vtable implementation is currently broken and does not work.
It works without inheritance, but with inheritance, it must
impose run time cost as dynamically finding proper table
for particular method enforces dynamic cast whenever method
is called.

Actually language does not need trait(interface) inheritance
at all. It can be simulated in following way and perfectly
works:


bmaxa@maxa:~/examples/rust$ cat trait.rs
// trait.rs
#[link(name = "testtrait")];

fn create<T:'static+TestTrait>()->@TestTrait
{
let a:T = TestTrait::new();
@a as @TestTrait
}

trait TestTrait{
fn doo(&self);
fn doo1(&self);
fn new()->Self;
}

impl Derived for @TestTrait{
fn doo(&self)
{
println("TestTrait D doo");
self.doo();
}
fn doo1(&self)
{
println("TestTrait D doo1");
self.doo1();
}
}

impl Base for @TestTrait{
fn doo(&self)
{
println("TestTrait B doo");
self.doo();
}
}

trait Derived{
fn doo(&self);
fn doo1(&self);
}

impl Base for @Derived{
fn doo(&self)
{
println("Derived B doo");
self.doo();
}
}
trait Base{
fn doo(&self);
}
bmaxa@maxa:~/examples/rust$ cat maintrait.rs
extern mod testtrait;
use testtrait::*;
fn main()
{
let s = create::<S>();
let d = @s as @Derived;
let c = @s as @Base;
let b = @d as @Base;

s.doo();
s.doo1();

d.doo();
d.doo1();

c.doo();

b.doo();
}

impl TestTrait for S{
fn new()->S{
return S;
}
fn doo(&self)
{
println("doo S");
}
fn doo1(&self)
{
println("doo1 S");
}
}

struct S;
bmaxa@maxa:~/examples/rust$ rustc --lib trait.rs -Z debug-info
warning: missing crate link meta `vers`, using `0.0` as default
bmaxa@maxa:~/examples/rust$ rustc maintrait.rs -L . -Z debug-info
bmaxa@maxa:~/examples/rust$ ./maintrait
doo S
doo1 S
TestTrait D doo
doo S
TestTrait D doo1
doo1 S
TestTrait B doo
doo S
Derived B doo
TestTrait D doo
doo S


All in all language is really promising and interresting

 

[Bienlein]

Our smalltalk

variant was the old Whitewater Actor language which
used a pascal like syntax and made things much, much
easier.

Yeah, Whitewater Actor tried to be a Smalltalk clone. It was some Smalltak look-alike. Porting that app to Smalltalk itself or Java would have been sufficient I guess.

 

[Melzzzzz]

Rust vtable implementation is currently broken and does not work.

Heh, I have commited fix for this bug, it was actually minor change
in code as vtable layout is ok
I was wrong in thinking that was vtable problem...
It was just vtable indexing bug...