This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: reduce compilation times?


Hi J.C.,

> How to take you of care in "dangling pointers" and "memory leaks" from C++ sources?

Don't dangle pointers.

Don't leak memory.

Both of which are weaknesses in C++, since it is very easy to dangle pointers and leak memory in C++.

The solution to both those problems is to be meticulous about pointers and memory management.  Boost has some nice facilities to aid in both of those, by wrapping memory management in smart pointers.

And be willing to use tools (valgrind, gdb, whatever) to help track down those problems when they (non-trivial C/C++: inevitably?) occur.

> For large-scale projects, besides C++, there are another high-level languages as Java (hated people because of Sun), Eiffel, Erlang, Mercury, Oz, Common Lisp, Ruby, Python, etc.

For the record, I don't "hate Java" because of Sun.  Quite the opposite, I have a lot of respect for Sun, and I actually "love Java" because of IBM's Eclipse.  (Without Eclipse, I'd be lukewarm on Java.)  And for enterprise applications, J2EE is the cat's meow!

Eiffel - have not programmed in it, but I have adopted some of the program-by-contract paradigms into my C++ programs.

Erlang, Mercury, Oz - have not used, and unfamiliar with.

Common Lisp - I've programmed some small applications in Scheme and in Squeak, but not Common Lisp or CLOS.  Is it suitable for large scale?

Ruby - is Ruby suitable for large scale?

Python - is Python suitable for large scale?

Of course, when talking about large scale applications, often more than one language is involved in the mix.  My project has C, C++, and JavaScript (both as a user scripting language, and used internally for parts).  The scripting language could just as well have been Ruby or Python, or Lua or Perl.

> They aren't good idea splitting files of large-scale projects from these languages.

Ummm... okay.  But that's not the context of the discussion - reduction of compilation times.

And the tangent of breaking up C/C++ code into finer granularity source files to aid in maintenance and management, with the concern over possible runtime impact (the refrain being:  profile).  There's probably concerns on both the "premature optimization" side (i.e., you cannot optimize without profiling), and the other side being "premature pessimization" (such as discussed by Sutter in the exceptional C++ series).

By the way:  I highly recommend Herb Sutter's books on C++.

> The "maintainance" is an important issue in large-scale projects.

You, me and Tom are in 100% agreement on that!

Sincerely,
--Eljay


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]