Slashdot Mirror

Most compilers can catch errors like this. For example in this C situation you would find it when compiling with gcc and looking for the warning:
warning: suggest parentheses around assignment used as truth value
http://www.network-theory.co.uk/docs/gccintro/gccintro_94.html

That way if you really wanted to assign i to 1 in the if you would need to use if ( (i=1) ) {.
Assignment like this is very common in C/C++ for pointers, esp when working with lists.
while ( (list = list->next) )

You can't put method bodies in a separate .cpp file if you use templates. When your library is mostly templates (like Boost), then all its code must necessarily be in the header files.

This does not mean that the code in the headers can "still be reduced to just the interface facts".

You are misinfromed. Yes you can, see this example. You can separate the template interface and implementation; However, in order to instantiate a template you must have access to the implementation. Libraries can provide just the template interface and a .so with commonly used instantiations to link against, and as long as you only use the explicit instantiated template forms you will not need the template implementations.

Lets say you have some LGPL function template that has its implementation in the .h file. I can reduce that to just the interface facts:

mylib.h
template <T> int someFunc( T * aVar );

Here is the .cpp implementation that has been split out (still LGPL) -- A derivative of the original combined template interface / impl.
mylib.cpp
#include mylib.h
template <T> bool someFunc( T * aVar) {
if ( aVar != NULL ) return true;
return false;
}

// Add Explicit template instantiations commonly needed -- prevents multiple instantiations of these:
template <int> bool someFunc ( int * aVar );
template <float> bool someFunc ( float * aVar );
// etc..

I can then compile a mylib.so that falls under the LGPL. I can then link NON LGPL programs to it via the sanitized .h file.

In order to use the template with types other than float or int I must have access to the mylib.h & mylib.cpp and include both. Or, I can use just the .H and recreate my own .CPP implementation to provide a compatible yet non-derivative, non-infringing library that I can license however I choose.

Once I have created (& possibly extended ) my own non-infringing lib, I am free to distribute the stripped down mylib.h file along with the mylib.so binary and other programs that only use the explicitly instantiated float, int and MyNewClass variants will not need to include the mylib.cpp code.

In the case of Boost, you'll end up re-creating much of the template implementation, but this does not mean that one can not separate the template implementations and interfaces, and subsequently create a compatible, non-infringing library that is compatible with Boost.

Or, you can separate the boost interface from its implementation, explicitly instantiate the template forms you will be using in a derivative .so binary (same license as Boost), then create your non-derivative application that simply uses the instantiated template forms and distribute it under a different license.

TL;DR: You are wrong. My point stands that I can reduce any .h files to their implementation facts then create non infringing .cpp file to link my own non-infringing / separately licensed code against.

What about something like this:

***Network Theory Ltd - publishing free software manuals **
http://www.network-theory.co.uk/

Before buying a hard copy of one of the book they published (GNU Octave Manual) I consulted free online version of the book many times. I understand that your book is not a software manual. But maybe there are other publishers who do it like Network Theory Ltd.

[1] - http://docs.python.org/modindex.html

Python does NOT lack expressive power either. Things like list comprehensions are beautiful:

>>> [str(round(355/113.0, i)) for i in range(1,6)]
['3.1', '3.14', '3.142', '3.1416', '3.14159']

http://www.network-theory.co.uk/docs/pytut/ListComprehensions.html
Both powerful and easy to remember without needing any extra documentation

Guido van Rossum himself as well as Fred Drake wrote an amazingly concise and complete introduction to Python. This book will get you up and running quickly. The book is called "An Introduction to Python" and it can be found here (free html, a $5 pdf, or isbn):
http://www.network-theory.co.uk/python/intro/

This book is only 100 pages long! It was written for Python 2.2.2, but it is perfectly useful for any Python 2.x. This book is amazingly concise, but it is also quite complete. You will get the most out of this book if you have a background in C/C++.

I am not affiliated with the book in any way, just a satisfied customer.

I still don't understand why they didn't bite the 64 bit bullet when they moved to Intel. It would have been easy to move the UI stuff to 64 bit mode. As far as I can tell, the kernel already is. Then you'd give people the option to run in long mode for applications. 32 bit applications could run in long mode too, actually - they would still have 32 bit pointers in memory and sign extend them into 64 bits when they load them into registers[1]. That way, all user applications could use the improved ABI, more registers, modern instructions and so on.

I don't see the reason to use 32 bit x86 code at all really, since they don't have any third party legacy Intel stuff to support. You could even run the 32 bit UI stuff in long mode, if you use the sign extended pointer trick.

[1] GCC for x86-64 already supports a small model where the code and data of an application must fit in 2GB. You'd need to have a "32 bit process" flag somewhere to tell malloc and so on to only return buffers in the first 4GB of virtual address space. That way, the application could safely store pointers in 32 bit memory locations. It could use MOVZX to load them into registers, and pass them to system calls. The idea is that you can still run ILP32 code on x86-64 code, in long mode.

  http://www.network-theory.co.uk/docs/gccintro/gcci ntro_65.html

I think you would find the cvs annotate function interesting.

Actually, if anyone is interested in learning Python and doesn't mind reading a book on their computer, there's a bunch of free ebooks available on the Python Documentation page (as well as a comprehensive list of books that are only printed). I've read a few of them, most of them are pretty good, in particular "How to think like a Computer Scientist" is a very good text for a less experienced programmer and Bruce Eckel's "Thinking in Python" is a nicely comprehensive coverage of Python (not unlike his "Thinking in Java" and "Thinking in C++" books).

Even if you do mind reading books on your computer screen, most of these books (actually I think all of them) are also available as physical printed books as well.

Thinking In Python by Bruce Eckel
An Introduction to Python by Guido van Rossum, and Fred L. Drake, Jr. (Editor)
How To Think Like a Computer Scientist: Learning with Python by Allen Downey, Jeff Elkner and Chris Meyers
Dive Into Python: Python for Experienced Programmers by Mark Pilgrim
Text Processing In Python by David Mertz
Python Language Reference Manual by Guido van Rossum

Actually, if anyone is interested in learning Python and doesn't mind reading a book on their computer, there's a bunch of free ebooks available on the Python Documentation page (as well as a comprehensive list of books that are only printed). I've read a few of them, most of them are pretty good, in particular "How to think like a Computer Scientist" is a very good text for a less experienced programmer and Bruce Eckel's "Thinking in Python" is a nicely comprehensive coverage of Python (not unlike his "Thinking in Java" and "Thinking in C++" books).

Even if you do mind reading books on your computer screen, most of these books (actually I think all of them) are also available as physical printed books as well.

Thinking In Python by Bruce Eckel
An Introduction to Python by Guido van Rossum, and Fred L. Drake, Jr. (Editor)
How To Think Like a Computer Scientist: Learning with Python by Allen Downey, Jeff Elkner and Chris Meyers
Dive Into Python: Python for Experienced Programmers by Mark Pilgrim
Text Processing In Python by David Mertz
Python Language Reference Manual by Guido van Rossum