Java or C++?

[hdante]

 Summarizing the discussion (and giving my opinions), here's an
"algorithm" to find out what language you'll leard next:

 1. If you just want to learn another language, with no other
essential concern, learn Ruby.
 2. If you want to learn another language to design medium to large
size applications, considering market, jobs, etc., and the speed gains
of static byte-compiled languages, learn Java or C#.
 3. If you want to learn another language to design applications with
speed gains, but you want that the transition be as smooth as possible
and don't have market concerns (and with the possibility of taking
another easy step later to reach step 2), learn Groovy (for the JMV)
or Boo (for .NET).
 4. If you want to develop applications but, for some special reason,
you require native compilation (like speed requirements, embedded
systems, etc.), learn C++
 5. If you want to develop system software, or just learn better how
machines work, or understand better low level implementation aspects
of software, learn C.
 6. If you just want to speed-up your python programs or offer some
special, system-specific or optimized behavior to your python
applications, or you just want to complement your python knowledge,
learn C.


On Apr 21, 7:26 pm, Jorgen Grahn <grahn+n... at snipabacken.se> wrote:
> On Mon, 21 Apr 2008 06:14:08 -0700 (PDT), NickC <ncogh... at gmail.com> wrote:
> > On Apr 15, 1:46 pm, Brian Vanderburg II <BrianVanderbu... at aim.com>
> > wrote:
> >> This will automatically call the constructors of any contained objects
> >> to initialize the string.  The implicit assignment operator
> >> automatically performs the assignment of any contained objects.
> >> Destruction is also automatic.  When 'p1' goes out of scope, during the
> >> destructor the destructor for all contained objects is called.
>
> > Yeah, C++ does try to be helpful, and all of those automatic copy
> > constructor, assignment operator and destructor implementations screw
> > up royally when confronted with pointers
>
> I think that those are newbie problems. The rules for those three
> "default implementations" are simple and match what C does for
> structs. Use the standard containers, make a habit of forbidding
> copying of objects which make no sense copying, and remember the
> "explicit" keyword, and you will rarely have problems with this.
>
> > (and being able to use
> > pointers is basically the whole reason for bothering to write anything
> > in C or C++ in the first place).
>
> Is it?  I rarely use pointers in C++ as anything but a kind of
> object reference, and mostly because I am forced to.
>
> I use C++ because it is an expressive language with static typing,
> which has access to all the hundreds of libraries with a C API on my
> (Unix) machine. And because it is fun to use.
>
> I use Python because it is an expressive language with dynamic typing,
> which has access to the most important libraries with a C API on my
> (Unix) machine. And because it is fun to use.
>
> > Code which relies on these default
> > method implementations is almost certain to be rife with memory leaks
> > and double-free bugs. So instead of being a convenience, they become a
> > painfully easy way of writing code that silently does some very, very
> > wrong things.
>
> I have worked with old code with those kinds of bugs.
>
> It's simple to check and fix.  If a class has pointer members of the
> Has-A type, the constructors, operator= and destructor have to handle
> them (or be suppressed). If they don't, the code is broken.
>
> If you grasp the concept of invariants, it's hard to get wrong. An
> object of type Foo has a number of valid states. You have to make sure
> there are no ways to create a Foo which is in an invalid state, or
> destroying one without cleaning up its state. The best way is usually
> to construct it from members which make similar guarantees, e.g. the
> standard containers.
>
> > Other things like methods (including destructors!) being non-virtual
> > by default also make C++ code annoyingly easy to get wrong (without it
> > obviously looking wrong).
>
> The other side of the coin is that you can write tiny classes in C++
> with *no overhead*. If my class Foo can be implemented as an integer,
> it doesn't need to be slower or take more space than an integer. It
> can have value semantics, live on the stack etc, like an integer.
>
> I assume Java programmers avoid such types, and I assume it decreases
> type safety in their programs.
>
> Ok, it could have been the other way around so that there was a
> "nonvirtual" keyword ... but on the other hand I use inheritance in
> C++ about as often as in Python, i.e. almost never.
>
> > The whole design of C++ is riddled with premature optimisation of
> > speed and memory usage in the default settings, instead of choosing
> > safe defaults and providing concise ways of allowing the programmer to
> > say "I know optimisation X is safe here, please use it".
>
> "Premature optimization" is a phrase which is always useful as a
> weapon, isn't it?
>
> But yeah, I think we can agree about this, at least: when you program
> in both Python and C++, it is painfully obvious that C++ never
> sacrifices speed or correctness, and it is painfully obvious that the
> programmer pays a price for this. Compare ... maybe, for example, the
> C++ standard library's very detailed and general iterator and
> algorithm concepts with things like Python's str.split and str.join. A
> function which takes a list of strings plus a delimiter and returns a
> string would be unthinkable in the C++ standard library.
>
> > That said, C++ code has one *huge* benefit over ordinary C code, which
> > is scope-controlled deletion of objects, and the associated Resource-
> > Acquisition-Is-Initialisation model.
>
> Yes, RAII is one big advantage over any other language I know of.
> Compared to good old C, I can come up with many others.
>
> I was going to say something about C++ versus Java here, but the fact
> is I haven't written more than a few pages of Java since it came out.
> The language (or the culture around it) seems to want to isolate itself
> from the rest of the world -- unlike C++ and Python.
>
> /Jorgen
>
> --
>   // Jorgen Grahn <grahn@        Ph'nglui mglw'nafh Cthulhu
> \X/     snipabacken.se>          R'lyeh wgah'nagl fhtagn!