Steven T. Hatton wrote:
I think for now, I just need to find out who to go from start to `make install'.
Here goes: you've got a file hello.cc that you want to compile: Create Makefile.am: == ## Process this file with automake to produce Makefile.in ## bin means install in binaries directory ## PROGRAMS means identify this as a program (as opposed HEADER, DATA, library) bin_PROGRAMS = hello ## hello is the prefix you created on the last line ## SOURCES is the list of files required to compile it hello_SOURCES = hello.cc == That's easy enough and almost clear. You'll also need a configure.ac. The quick way is to run autoscan and then mv configure.scan to configure.ac. You'll also need to add automake support with the AM_INIT_AUTOMAKE macro. You end up with: == # -*- Autoconf -*- # Process this file with autoconf to produce a configure script. AC_PREREQ(2.57) AC_INIT(hello,0.1,email@address) AC_CONFIG_SRCDIR([hello.cc]) AC_CONFIG_HEADER([config.h]) AM_INIT_AUTOMAKE # Checks for programs. AC_PROG_CXX # Checks for libraries. # Checks for header files. # Checks for typedefs, structures, and compiler characteristics. # Checks for library functions. AC_CONFIG_FILES([Makefile]) AC_OUTPUT == Now a few extras # touch NEWS README AUTHORS ChangeLog creates some files the GNU build expects for automake to work. You'll also need some standard incantations: # aclocal # autoheader # automake -a # autoconf Just so you don't keep repeating these, write a script 'bootstrap': == #! /bin/sh aclocal \ && autoheader \ && automake --gnu --add-missing \ && autoconf == Then if things don't do what you want, just do # ./bootsrap and they will. Now look and you'll see you have a configure script. Run it: # ./configure A makefile appears 'as if by magic' # make and presto: your file is compiled and will run _in situ_. The real work of autotools is usually sorting out libraries, but find out first how it compiles a simple program, then move on. Libraries cause the real problem because they may have to go in specific locations. Hence the --prefix= option, which, by the way, you've already got. Also, shared libraries are harder than static ones, but necessary for some C++ development, but autools will handle all the complexity for you with a little help from libtoolize.
I'm still not sure if templates will add all that much to Java. I've found that in most cases where templates would be useful, I can usually isolate the type casting to very limited and regular points in the program. Type casting is about the only thing templates seem to eliminate as far as I can see. The negatives of templates seem to outway the positives as far as I can tell. Sure, it takes some getting used to in Java, but once you accept things are as they are, and are willing to work with them, it works quite well.
Simple template functions aren't _that_ useful, but STL stuff is. For example, the STL code to sum all the elements of a dynamically resizeable vector of doubles is reasonably simple: double total = 0; for( std::vector<double>::iterator i = my_vector.begin(); i != my_vector.end(); ++i ) total += *i; Java has some support for this kind of thing, but not yet quite as good. The thing I don't like is the clunkyness of the code. Python is nicer. APL could do it as my_data?+/my_vector (IIRC)
Java is not always that slow. I don't know what benchmarks have been recorded for Java 3D and OpenGL, but Java3D is pretty snappy. The slow part of Java typically involves the time it takes to load into memory.
Depending on the estimate C++ can run 5-15 times as fast, though for many GUI apps that's not an issue. The last java app I wrote deliberately slows itself down so you can see it work. What gcj may do is make java compete with C++ on speed also.
Non enim propter gloriam, diuicias aut honores pugnamus set propter libertatem solummodo quam Nemo bonus nisi simul cum vita amittit.
Try pasting the text into Gooogle. -- JDL Non enim propter gloriam, diuicias aut honores pugnamus set propter libertatem solummodo quam Nemo bonus nisi simul cum vita amittit.