Can Java Programmer Learn C++ Quickly?

J

jeffc

Ian T said:
Fourth: Learn the containers in STL as soon as practically possible,
especially <map> and <list>.

Good luck with that ;). Probably *the* best book (IMNSHO) for starting
out with C++ is Dietel & Deitel C++ How to Program. It's as dense as a
chocolate pudding, but it has all the bits.

In keeping with your fourth point, and learning to write practical programs
using the standard library immediately, I think Accelerated C++ would be a
better choice for him.
 
J

jeffc

James Kanze said:
When it comes down to it, of course, neither C++ nor Java can be taken
as models with regards to their collections and iterators. C++ uses
really stupid names, like ++ and *, rather than a simple, understandable
next() and element() (or something along those lines), but that's just a
naming convention.

That is part of the problem with C++ - too much overloading. (The only one I've
seen after just starting in Java is + for Strings.) Not just operators like
those, but more general problems like "static" (ugh!), '&' (3 meanings), etc.
Java has a similar problem with "final", (C++ has const, but no unoverridable
methods), but then there is crazy stuff in C++ like the lack of an abstract
keyword, and that inane syntax "=0" for pure virtual. Yes indeedy, an overly
syntaxy language (due mostly to too much backward compatibility with C.)
 
S

Stephen Kellett

Chris Smith said:
close to the amount of C code out there. C++ is almost non-existent in
open-source, in my experience, probably because once you're that close
to C, people start asking why you don't use C.

I disagree - there are some pretty large and useful C++ open source
projects out there. I've had users of Xerces and omniORB point me at
them for debugging purposes (I can't think of any others right now) -
although I see (in another post) that someone has had the bright idea of
scanning the open source projects by language category.

As to your second point - why anyone would go back to C after the
usefulness and much improved type safety and expressiveness of C++ is
beyond me.

I think many open source projects that have some momentum go back a long
way, time-wise, such as Linux, Python and Ruby (I was surprised to find
that Ruby is as old as it is, some of the copyrights go back to 1993,
with one at 1988). As a result they were started in C because a useful
C++ compiler wasn't available (I remember in 1990 working on a cross
platform (7 Unix + VMS) app - we wanted C++, but couldn't get anything
stable on all the platforms so went with GCC on all the platforms. By
the time G++ was useful, stable and available, we had 1 million or more
lines of C... no one is going to rework that code that is already
working).

Stephen
 
C

Chris Smith

Stephen Kellett said:
As to your second point - why anyone would go back to C after the
usefulness and much improved type safety and expressiveness of C++ is
beyond me.

Oh, I don't think that C is unequivocally better than C++ (though there
are advantages for the simpler language); but at least the last time I
did much open-source stuff, which was about four or five years ago,
there were great numbers of open-source developers who knew C and simply
refused to bother with C++. It's still a matter of compatibility with
the older language, even for new projects.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
D

Dimitri Maziuk

Stephen Kellett sez:
....
As to your second point - why anyone would go back to C after the
usefulness and much improved type safety and expressiveness of C++ is
beyond me.

C standard library is guaranteed to be present on any unix machine,
C++ is not.

C has ABI, so the above library will probably work with your code.
No such luck with C++.

Whenever new C/C++ standard comes out, C++ one tends to break
existing code bad. C is an older and more stable language so
it doesn't break quite as easily.

If you're good at C improved type safety and expressiveness of
C++ are of questionable value to you.

etc.

Dima
 
C

Chris Smith

Ryan Stewart said:
Well... what about finalize?

It's a serious mistake to equate finalize() with a destructor.
Destructors are primarily used to release resources; it's a design flaw
to rely on a finalize() method to release resources. Classes that would
have destructors in C++ should have close() or dispose() methods in
Java, and should be used with try/finally blocks.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
R

Ryan Stewart

Chris Smith said:
It's a serious mistake to equate finalize() with a destructor.
Destructors are primarily used to release resources; it's a design flaw
to rely on a finalize() method to release resources. Classes that would
have destructors in C++ should have close() or dispose() methods in
Java, and should be used with try/finally blocks.
I wasn't suggesting that finalize should be used to release resources. That
obviously wouldn't do much good as it may never be called. I meant that just
as a destructor is invoked when an object is destroyed, so is finalize. The
difference is that you explicitly destroy objects in C++, but not in Java.
 
J

James Kanze

Ian said:
James Kanze wrote:
[...]
Just a fancy way of saying that in practice, I've seen more problems
with dangling pointers in C++ than with memory leaks.
Which often cause segfaults at some later stage.

Typically, you'll have no problem during any of your tests, but it will
segfault consistently at the demo in front of the important customer.
Often you still need to know the problems with ntca's when using some of
those interfaces. Some of the more, shall we say 'baroque', win32 APIs
can get you into a lot of trouble without an understanding of char
buffers.

I've never written for win32 APIs -- the only application I ever wrote
for Windows was in Java. I've not found it to be a problem with most of
the Posix API, although there are a few exceptions.

Typically, you wrap the API in a class wrapper -- the author of the
class wrapper has to deal with the problem, but no one else should.
Regretfully, this idea hasn't been followed through in the C++ standard
library.
How do you define 'All of Linux'. Is it every application written for
Linux, or just the kernel and gnu tools?

Good question. Obviously not every application, since some of my C++
code runs on Linux, and I've used Together on it. (Together is in
Java.) But Linus doesn't like C++ one little bit (and obviously, Java's
not an option for the kernel):).
Did you implement the "+" operator with 'malloc' or 'new'?

My original String class used the functions ::eek:perator new and
::eek:perator delete for memory allocation and deallocation. And reference
counting as a sort of poor mans garbage collection. (This was before
the days of multithreading, so reference counting wasn't too difficult
for low level stuff, where cycles weren't possible.)
And the Length() function, did you use strlen, or did you have some
other mechanism that kept track of the character length?

Every String class I've ever seen (including java.lang.String) used a
control block with at least:

SomeIntegerType length ;
char* text ;

Mine added a reference count (and used a fancy, low level trick to put
the text buffer immediately behind the control block, so there was only
one allocation, rather than two). Most add a capacity, so that just
adding a single character doesn't always require reallocation -- since
my String was basically immutable, and I had a separate class optimized
for building strings from characters one by one.

Note that if you want to allow your String class to contain '\0',
there's not really any alternative.
 
J

Joona I Palaste

Ryan Stewart said:
I wasn't suggesting that finalize should be used to release resources. That
obviously wouldn't do much good as it may never be called. I meant that just
as a destructor is invoked when an object is destroyed, so is finalize. The
difference is that you explicitly destroy objects in C++, but not in Java.

I honestly don't remember how it correctly is, but I seem to remember
hearing that there is no guarantee that finalize() will be called when
the GC sweeps up an object, or ever, for that matter.
 
J

Joona I Palaste

I honestly don't remember how it correctly is, but I seem to remember
hearing that there is no guarantee that finalize() will be called when
the GC sweeps up an object, or ever, for that matter.

Apologies for the confusing post... but you yourself say both
"finalize() [...] may never be called" and "finalize() [...] is invoked
when an object is destroyed". Aren't these conflicting statements?
 
R

Ryan Stewart

Joona I Palaste said:
I honestly don't remember how it correctly is, but I seem to remember
hearing that there is no guarantee that finalize() will be called when
the GC sweeps up an object, or ever, for that matter.

Apologies for the confusing post... but you yourself say both
"finalize() [...] may never be called" and "finalize() [...] is invoked
when an object is destroyed". Aren't these conflicting statements?
From the JLS 2.0, §12.6: "Before the storage for an object is reclaimed by
the garbage collector, the Java virtual machine will invoke the finalizer of
that object." By "when an object is destroyed" above, I meant the explicit
destruction in C++/garbage collection in Java. When you destroy an object in
C++, the destructor is called. When (before, actually) an object is GC'd in
Java, its finalizer is called. If, however, an object is not GC'd before the
program terminates, the object's finalizer will not be executed. Therefore,
it's not a suitable place for releasing certain resources, such as closing
network connections, as Chris was pointing out.
 
R

Ryan Stewart

James Kanze said:
No. In Java, you are likely to end up calling a function in a class
whose constructor has not even started yet.
Of course it works. And class methods and instance methods/constructors are
two different animals, if that's what you're referring to.
 
J

Joona I Palaste

Ryan Stewart said:
Joona I Palaste said:
Joona I Palaste said:
Ryan Stewart <[email protected]> scribbled the following:
I wasn't suggesting that finalize should be used to release resources.
That
obviously wouldn't do much good as it may never be called. I meant that
just
as a destructor is invoked when an object is destroyed, so is finalize.
The
difference is that you explicitly destroy objects in C++, but not in
Java.
I honestly don't remember how it correctly is, but I seem to remember
hearing that there is no guarantee that finalize() will be called when
the GC sweeps up an object, or ever, for that matter.

Apologies for the confusing post... but you yourself say both
"finalize() [...] may never be called" and "finalize() [...] is invoked
when an object is destroyed". Aren't these conflicting statements?
From the JLS 2.0, §12.6: "Before the storage for an object is reclaimed by
the garbage collector, the Java virtual machine will invoke the finalizer of
that object." By "when an object is destroyed" above, I meant the explicit
destruction in C++/garbage collection in Java. When you destroy an object in
C++, the destructor is called. When (before, actually) an object is GC'd in
Java, its finalizer is called. If, however, an object is not GC'd before the
program terminates, the object's finalizer will not be executed. Therefore,
it's not a suitable place for releasing certain resources, such as closing
network connections, as Chris was pointing out.

So finalize() will be called when the object is GC'd, but an object
might never be GC'd?
 
R

Ryan Stewart

Joona I Palaste said:
So finalize() will be called when the object is GC'd, but an object
might never be GC'd?
Correct.

public class GCTest {
public void finalize() {
System.out.println("Finalized");
}
}

Create an instance of GCTest and then end the program. "Finalized" is never
printed.
 
C

Chris Smith

Right. I was just clarifying that in terms of real-life usage,
destructors are more similar to a finally block than a finalize()
method. Clearly finalize() has more surface similarities. Then again,
virtual methods can be called from either.
If, however, an object is not GC'd before the
program terminates, the object's finalizer will not be executed. Therefore,
it's not a suitable place for releasing certain resources, such as closing
network connections, as Chris was pointing out.

The race condition with the end of the process mostly shows up in test
code that tries to demonstrate finalize() working. I've seen it become
a problem once with some logging code that someone wrote, but that's
quite rare. It's the arbitrary timing that's the bigger problem. Once
the process has ended, who cares if you cleaned up your network
connections, anyway? They're gone now!

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
R

Ryan Stewart

Chris Smith said:
The race condition with the end of the process mostly shows up in test
code that tries to demonstrate finalize() working. I've seen it become
a problem once with some logging code that someone wrote, but that's
quite rare. It's the arbitrary timing that's the bigger problem. Once
the process has ended, who cares if you cleaned up your network
connections, anyway? They're gone now!
Database connections in particular don't like being left open whether the
calling code is still running or not.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top