Are c++ features a subset of java features?

[Jon Harrop]

I don't see how closures and GC are related?

1. A closure can capture values from its environment.

2. A closure can be returned from a function.

=> a closure can extend the lifetime of a value arbitrarily, so you need GC.

FWIW, closures exist in C++. Granted, not as part of the language, but
as libraries. So even without GC you can have closures...

Closures in C++ are so limited that most people wouldn't even call them
closures. Try translating some of the examples into languages with native
support for first class lexical closures and you'll see what I mean. With
an expressive type system, errors are much easier to understand.

 

[Alf P. Steinbach]

* Jon Harrop:

Then you are reimplementing the garbage collector.

Not really. E.g. your example concerned a self-referential expression.
When the self-referential nature becomes a problem, e.g. not easily
modelled via weak or raw pointers, then that indicates that the
structure used to represent the problem domain is not well chosen, i.e.
will likely lead to problems also in other processing (not just garbage
collection). It's like an infinitely recursive function. Some
languages (e.g. data flow languages) can handle infinite recursion
easily, but that doesn't mean it's a good idea: it's usually an
indication of some thinko, a much less than perfect implementation.

But still you have a point.

C++ RAII is a trade-off, involving some (design) work being delegated to
the programmer. I think that's generally a Good Thing(TM), because when
the language is capable of dealing with any messy structure, messy
structures are likely to abound. However, I grant that in some problem
domains such structures /may/ be practically necessary, and the question
is still whether some example can be found where that is so.

 

[Jon Harrop]

If at any point an exception is thrown, the transaction is rolled back
when the destructor is called.

Can this be written in a purely functional style? Perhaps that is easier...

 

[Jon Harrop]

* Jon Harrop:

Not really. E.g. your example concerned a self-referential expression.
When the self-referential nature becomes a problem, e.g. not easily
modelled via weak or raw pointers, then that indicates that the
structure used to represent the problem domain is not well chosen, i.e.
will likely lead to problems also in other processing (not just garbage
collection).

Graph theory is a very elegant branch of pure mathematics. Garbage collected
languages can represent graphs and graph-theoretic algorithms with
simplicity, clarity and robustness.

The fact that C++ cannot do this in no way diminishes graph theory as a
useful tool. Graph theory remains of fundamental importance in computer
science.

It's like an infinitely recursive function.

Not "infinitely" recursive. A recursive function is an ideal example of
something that would be most elegantly represented by a cyclic graph. I did
exactly this in my example interpreter here:

http://www.ffconsultancy.com/free/ocaml/interpreter.html

The pattern match in the "eval" function creates a cyclic graph in the host
language to represent a recursive function in the target language:

| ELetRec(var, arg, body, rest) ->
let rec vars = (var, VClosure(arg, vars, body)) :: vars in
eval vars rest

Some
languages (e.g. data flow languages) can handle infinite recursion
easily,

Almost all languages (including C++) can handle recursion.

but that doesn't mean it's a good idea: it's usually an
indication of some thinko, a much less than perfect implementation.

If you believe it is imperfect then how do you think it can be improved?

C++ RAII is a trade-off, involving some (design) work being delegated to
the programmer. I think that's generally a Good Thing(TM), because when
the language is capable of dealing with any messy structure, messy
structures are likely to abound.

You are implying that C++ can deal with structures that other languages
cannot. Can you elaborate?

The examples I've given don't look messy to me.

However, I grant that in some problem
domains such structures /may/ be practically necessary, and the question
is still whether some example can be found where that is so.

Here are some examples from various disciplines:

You already mentioned the example of representing recursive functions in
compilers and interpreters, e.g. for register allocation:

http://citeseer.ist.psu.edu/492550.html

In graphics, meshes are most elegantly represented as co-cyclic graphs of
vertex, edge and triangle connectivity. Functions that act upon meshes are
ubiquitous in graphics programming:

http://www.actapress.com/PDFViewer.aspx?paperId=29408

Scene graphs are the most common high-level representation of 3D worlds and
these can be cyclic:

http://www.techfak.uni-bielefeld.de.../4a.RT3DCGVR-Graphics-pipeline-and-graphs.pdf

Higher-dimensional multiresolution representations and adaptive subdivisions
can also benefit from cyclicity.

In symbolic computing, computer algebra packages have very similar structure
to compilers and interpreters and must be able to rewrite cyclic graphs
representing symbolic expressions:

http://journals.cambridge.org/production/action/cjoGetFulltext?fulltextid=455532

In biological scientific computing, any relationship network (e.g. metabolic
pathways, gene expression relationships) can be cyclic and algorithms for
storing and manipulating these must be able to handle cyclic graphs:

http://216.239.59.104/search?q=cach...lic+graph"++leroy&hl=en&ct=clnk&cd=8&ie=UTF-8

In physical scientific computing, graph theory is used in many subjects,
e.g. to study the topology of amorphous materials at the atomic scale, e.g.
Franzblau's shortest path ring statistics applied to the structure of
silica glass in my own PhD thesis:

http://www.ffconsultancy.com/free/thesis.html

Finally, I should probably mention that implementing a garbage collector is
another application of graph theory. Although this is a funny example to
bring up, it underlines my point that writing code to collect graphs in C++
is literally writing your own garbage collector.

As you can see, cyclic-graph theory and computer programming have many
overlaps. Consequently, it is beneficial to use a language that allows such
things to be represented succinctly and efficiently.

 

[Alf P. Steinbach]

* Jon Harrop:

Graph theory is a very elegant branch of pure mathematics. Garbage collected
languages can represent graphs and graph-theoretic algorithms with
simplicity, clarity and robustness.

Doesn't mean anything to me, sorry. Not that I disagree. It just
doesn't connect with anything.

The fact that C++ cannot do this in no way diminishes graph theory as a
useful tool.

Whatever it is you think is a fact, it hasn't been established as fact.
There are two issues: clarifying what "this" is, and establishing the
statement about "this" and C++ as fact. I'll leave you to it.

Graph theory remains of fundamental importance in computer
science.

Yep, but that's off-topic in this group, sorry.

Not "infinitely" recursive.

I wrote it, so I'm the one deciding what it should be.

A recursive function is an ideal example of
something that would be most elegantly represented by a cyclic graph.

In C++, most elegantly as a recursive function.

I did
exactly this in my example interpreter here:

http://www.ffconsultancy.com/free/ocaml/interpreter.html

The pattern match in the "eval" function creates a cyclic graph in the host
language to represent a recursive function in the target language:

| ELetRec(var, arg, body, rest) ->
let rec vars = (var, VClosure(arg, vars, body)) :: vars in
eval vars rest


Almost all languages (including C++) can handle recursion.

Yes, green plants are green.

However, most languages, including C++, can't handle infinite recursion.

If you believe it is imperfect then how do you think it can be improved?

When you end up with infinite recursion, think first about completely
different ways of solving the problem. If it then still seems that
recursion is needed, introduce one or more base cases. It's a simple
principle, but applied to a complex situation, may still be complex.

You are implying that C++ can deal with structures that other languages
cannot.
No.


Can you elaborate?

Yes, see above.

The examples I've given don't look messy to me.

Beauty is in the eye of the beholder... ;-)

Here are some examples from various disciplines:

You already mentioned the example of representing recursive functions in
compilers and interpreters, e.g. for register allocation:

http://citeseer.ist.psu.edu/492550.html

In graphics, meshes are most elegantly represented as co-cyclic graphs of
vertex, edge and triangle connectivity. Functions that act upon meshes are
ubiquitous in graphics programming:

http://www.actapress.com/PDFViewer.aspx?paperId=29408

Scene graphs are the most common high-level representation of 3D worlds and
these can be cyclic:

http://www.techfak.uni-bielefeld.de.../4a.RT3DCGVR-Graphics-pipeline-and-graphs.pdf

Higher-dimensional multiresolution representations and adaptive subdivisions
can also benefit from cyclicity.

Interestingly, all these problems that are allegedly incompatible with
lack of a language-supported garbage collector have corresponding C++
programs: the basic libraries for handling such things are typically
implemented in C and/or C++.

In symbolic computing, computer algebra packages have very similar structure
to compilers and interpreters and must be able to rewrite cyclic graphs
representing symbolic expressions:

http://journals.cambridge.org/production/action/cjoGetFulltext?fulltextid=455532

Ah, computer algebra packages, don't know anything about them, but the
term reminds me of Mathematica.

In biological scientific computing, any relationship network (e.g. metabolic
pathways, gene expression relationships) can be cyclic and algorithms for
storing and manipulating these must be able to handle cyclic graphs:

http://216.239.59.104/search?q=cach...lic+graph"++leroy&hl=en&ct=clnk&cd=8&ie=UTF-8

In physical scientific computing, graph theory is used in many subjects,
e.g. to study the topology of amorphous materials at the atomic scale, e.g.
Franzblau's shortest path ring statistics applied to the structure of
silica glass in my own PhD thesis:

http://www.ffconsultancy.com/free/thesis.html

Interestingly, all these problems that are allegedly incompatible with
lack of a language-supported garbage collector have corresponding C++
programs: the basic libraries for handling such things are typically
implemented in C and/or C++.

Finally, I should probably mention that implementing a garbage collector is
another application of graph theory.

Ah, yes, and garbage collectors are typically implemented in... what
language(s), do you think?

Although this is a funny example to
bring up, it underlines my point that writing code to collect graphs in C++
is literally writing your own garbage collector.

Can't be contested: at some level there is always a similarity between a
thing and another thing, if nothing else, both are things.

As you can see, cyclic-graph theory and computer programming have many
overlaps. Consequently, it is beneficial to use a language that allows such
things to be represented succinctly and efficiently.

The premise seems good. The conclusion, disconnected from the premise.
This group's FAQ does discuss the choice of programming language, I
suggest reading that FAQ item.

Cheers,

- Alf

 

[Alan Johnson]

public class Whatever
{
public static void main(String args[])
{
Resource1 r1 = new AutoReleasingResource1(new Resource1()
);
Resource2 r2 = new AutoReleasingResource2(new Resource2()
);
r1.doSomething() ;
r2.doSomething() ;
}

}class AutoReleasingResource1 extends Resource1 {
private Resource1 delegate

public AutoReleasingResource1(Resource1 delegate) {
this.delegate = delegate;
}

public void doSomething()
{
try {
delegate.doSomething();
} finally {
delegate.release();
}
}

}class AutoReleasingResource2 extends Resource2 {

private Resource2 delegate

public AutoReleasingResource1(Resource2 delegate) {
this.delegate = delegate;
}

public void doSomething()
{
try {
delegate.doSomething();
} finally {
delegate.release();
}
}

}Do note, I've explicitly chosen to pass the delegate object into the
decorator to show its using a delegate(not to mention that it makes
unit testing so much easier), but there is nothing stopping us from
creating this object within each decorator itself instead of passing it
in.

Andrew

This solution is not exception safe. Specifically, r2 is never
released if r1.doSomething() throws an exception. Also, what do I do
if I want use more than one method of the resource object? That is ...

r1.doSomething() ;
r2.doSomething() ;
r1.doSomethingElse() ;
r2.doSomethingElse() ;

 

[Alan Johnson]

public class Whatever
{
public static void main(String args[])
{
Resource1 r1 = new AutoReleasingResource1(new Resource1()
);
Resource2 r2 = new AutoReleasingResource2(new Resource2()
);
r1.doSomething() ;
r2.doSomething() ;
}

}class AutoReleasingResource1 extends Resource1 {
private Resource1 delegate

public AutoReleasingResource1(Resource1 delegate) {
this.delegate = delegate;
}

public void doSomething()
{
try {
delegate.doSomething();
} finally {
delegate.release();
}
}

}class AutoReleasingResource2 extends Resource2 {

private Resource2 delegate

public AutoReleasingResource1(Resource2 delegate) {
this.delegate = delegate;
}

public void doSomething()
{
try {
delegate.doSomething();
} finally {
delegate.release();
}
}

}Do note, I've explicitly chosen to pass the delegate object into the
decorator to show its using a delegate(not to mention that it makes
unit testing so much easier), but there is nothing stopping us from
creating this object within each decorator itself instead of passing it
in.

Andrew

This solution is not exception safe. Specifically, r2 is never
released if r1.doSomething() throws an exception. Also, what do I do
if I want use more than one method of the resource object? That is ...

r1.doSomething() ;
r2.doSomething() ;
r1.doSomethingElse() ;
r2.doSomethingElse() ;

 

[Jon Harrop]

Interestingly, all these problems that are allegedly incompatible with
lack of a language-supported garbage collector have corresponding C++
programs: the basic libraries for handling such things are typically
implemented in C and/or C++.

Greenspun: Each of these programs contains an ad-hoc, informally-specified,
bug-ridden, slow implementation of a garbage collector.

Why bother reimplementing the garbage collector when you could just use a
language that has one built-in, e.g. any high-level language?

 

[Sascha Bohnenkamp]

can you name one java application whihc behaves better than its c++
counterparts?

Most java apps I saw just through such null-pointer exceptions or refuse
to work well on the installed vm
For this reason I normaly avoid using java-applications.
(and they are often slow)

 

[Mirek Fidler]

languages can represent graphs and graph-theoretic algorithms with
simplicity, clarity and robustness.

The fact that C++ cannot do this in no way diminishes graph theory as a
useful tool. Graph theory remains of fundamental importance in computer
science.

I think that you are making the basic mistake in assumption that the
only possible representation of graphs has to use pointers.

 

[Jon Harrop]

can you name one java application whihc behaves better than its c++
counterparts?
Most java apps I saw just through such null-pointer exceptions or refuse
to work well on the installed vm
For this reason I normaly avoid using java-applications.
(and they are often slow)

I agree. The safe languages that I use don't have null pointer exceptions,
so that isn't a problem.

As for programs written in Java that work well. Tribal trouble might be a
good example. Its the only Java program that I've used significantly and it
is noticeable more stable than many other games (presumably written in
C++). However, Tribal Trouble doesn't exactly push the limits of my
graphics card.

 

[Jon Harrop]

What platforms does C++ not port well to? I'm curious as our company
has a huge codebase in C++ (16000 cpp and hpp files), and we have had
more problems porting our Java base (the size of which I don't know)
than our C++ base.

We had so many problems trying to port a relatively small (but template
heavy) program to IRIX that we gave up. We've had fewer but still
significant problems with Intel's compilers. Not always template related,
one irritating problem was a difference in the typing of -- in the presence
of const. I had used a particular pattern hundreds of times in my code and
would have had to change every occurrence by hand to get around this
discrepancy in the compilers' understanding of the C++ language.

A friend of mine put a lot of effort into a template-heavy partially
specialising image processing library in C++ only to find that Microsoft's
VCC would leak memory and die before it could compile even the simplest
program. Microsoft's support team advised him to "avoid templates", and
presumably other language features.

We have even had problems porting from GCC (v 2) to GCC (v 3). We had two
people in a team (I was one of them) working concurrently on two different
aspects of a program. I developed in the current Debian compiler of the
time, GCC 2. My colleague developed in GCC 3. I used some features (I
forget which) that worked perfectly in GCC 2 but not in 3 and he used some
features (string streams) that worked in GCC 3 but not 2. Reconciling the
problems before we could combine the code was a big waste of time.

Perhaps the most portable languages I've used lately are Mathematica and
OCaml. We commercialised a Mathematica notebook that works transparently
(with the exception of installation paths) between Linux, Mac OS and
Windows. All of the example programs from my book on OCaml compile with no
changes under Linux, Mac OS X and Windows. I'm waiting to see if F#
provides the same portability via Mono.

I've collaborated with Java GUI developers in the past. Them using Windows,
me using Linux at the time. I was very impressed with Java's portability. I
could always compile and run their code with no changes from the latest
repository.

To be fair, I have made little use of C++ over the past 3 years (having
moved on to much friendlier languages), so maybe the situation has changed.
Maybe templates don't produces pages of incomprehensible errors. Maybe C++
programs can no longer segfault. However, I doubt it and I'm not about to
risk my company by moving back.

What problems have you had porting Java?

 

[Sascha Bohnenkamp]

Tribal Trouble is nice, but needs a much more powerfull computer than
better / prettier rts games need.
Like Warcraft 3, Combat Mission and many more.
It might not crash as often as most Java app But its much slower than
non Java apps ...

Just compare those graphics with Black&White and try to run it on a
system where Black&White was playable without framerate issues.
(Hint: Nvidia GeForce 256 ddr, 600MHz Pentium 3, 512 MB RAM)
No way to play Tribal Trouble on such a system ... without stuttering

 

[Sascha Bohnenkamp]

Maybe you would have less problems porting C++ from one system to
another if you try to stick to the standard as close as possible?
Normaly you get problems if you violate the standard (or expect too
much) even if not knowing that.
We ported some large application from SGI to SUN to Windows .. no real
problems.
Today we use gcc to cross-test our windows sources.

This helps much!

 

[Ian Collins]

Maybe you would have less problems porting C++ from one system to
another if you try to stick to the standard as close as possible?
Normaly you get problems if you violate the standard (or expect too
much) even if not knowing that.
We ported some large application from SGI to SUN to Windows .. no real
problems.
Today we use gcc to cross-test our windows sources.

This helps much!

Please keep the context you are replying to.

 

[Sascha Bohnenkamp]

sorry next time I will

 

[Ian Collins]

sorry next time I will

And don't top-post!

 

[Jon Harrop]

Maybe you would have less problems porting C++ from one system to
another if you try to stick to the standard as close as possible?

Heh, standard.

 

[kwikius]

All of the example programs from my book on OCaml compile with no

changes under Linux, Mac OS X and Windows.

Just out of curiosity, how many OCaml compilers are there?

regards
Andy Little

 

[Jon Harrop]

Just out of curiosity, how many OCaml compilers are there?

Depends what counts as a different compiler. There are many open source
compilers for bytecode, native code and several related languages but they
all have some code in common. As for unrelated compilers, there's the F#
compiler fsc but that compiles a different (but related) language.