"The Handbook of Algorithms and Data Structures" (in Pascal and C) Second Edition, by G.H. Gonnet and R. Baeza-Yates, ISBN 0-201-41607. It's a compact reference and analysis of a pretty broad range of algorithms. I also strongly second some of the other suggestions above such as Sedgewick, and Aho, Hopcroft, and Ullman. "The Stanford GraphBase" by Knuth, ISBN 0-201-54275-7 is great, though focused obviously. Beyond the basics, you'll end up looking in very specific books, such as "Text Compression" by Bell, Cleary, and Witten, ISBN 0-13-911991-4 or similar works applicable to the problem at hand. Some of the most interesting data structures I've seen I first encountered in journals. I can't seem to find it now, but it was in Journal of the ACM, if I recall correctly, I first learned a scheme to manage small sets that made membership-test, insertion, deletion, and finding the next member of the set all constant-time operations.
Where possible, of course, you don't want to implement these from scratch. You want to understand them so you know which apply to your problem, but then get code from, e.g. for C++, the Standard Library and Boost, both of which can also be a shopping list to spark further investigations.
In terms of their developers, they have a lot of very smart people in the business working for them.
Google may have unseated them in this department.
In terms of business, they are one of the most successful companies on the planet.
Yes. One can't argue with that. Microsoft is very successful, just like De Beers, or Big Oil. Yes, they won, and not entirely by abusing monopoly powers. But they didn't win nicely, and neither the consumer nor the field of software development has benefitted from their win to the extent they might have in a world where Microsoft actually had to compete with innovators (instead of swallowing them whole).
In response to several scattered posts that touched on the GPL and `internal software'...
Let's dissect the interesting scenario.
Your company is working on some software for internal use.
You have no initial intention to sell or distribute it.
It just solves some local problem you need solved.
It's based on GPL software, hence, it's subject itself to the GPL.
It embodies proprietary business logic that you would prefer not to share.
Therefor, you decide not to distribute it,
as once you did, the GPL would prevent you from further limiting
what distributees could do with your proprietary business logic.
Theoretically, this might apply to your own employees:
does `distributing' the software to them force the GPL to kick in?
The Free Software Foundation's GPL FAQ
has something to say on this topic:
Is making and using multiple copies within one organization or company "distribution"?
The short answer is 'no', that should be OK.
In this situation, the FSF at least feels the GPL doesn't stop you
from telling your employees not to give away your source code.
On the other hand, that same FAQ item points out
"In particular, providing copies to contractors for use off-site is distribution."
So when consultants from a professional consulting company come to help out
and you have to give them a copy of the software so they can do their job,
that does count as `distribution'.
If a big company sends analysts to do due diligence,
and you have to give them a copy of the software so they can complete
their analysis,
is that `distribution'?
If the big company ends up buying your little company to keep as a research division,
and they decide your software could be useful to their
accounting team in Iceland,
will that be `distribution'?
Does the GPL give your Icelandic accountants permission to give away (or even sell)
your proprietary business logic?
These questions haven't yet been answered in the courts,
but my gut feeling is at least two of them would absolutely be considered
distribution, if not all three.
We could continue examining case-by-case to decide if we might be forced
to obey the GPL in any particular situation.
Those who ask `will the GPL apply to me' in this way
plainly are asking because they don't want to be encumbered by the GPL.
Those people shouldn't build atop GPL software;
and they can have Qt unencumbered: just buy a commercial license.
Again, it goes back to the underlying theme in dual licenses of quid pro quo.
Why in this situation would someone use GPL software in the first place?
Do they truly intend to abide by letter and spirit of the GPL?
If they do, then more power to them.
They're getting something of value
and they're electing to pay it forward by sharing their work with the community
(in lieu of backward to the originator, funding continued development).
On the other hand,
if they are taking software under the GPL
all the while trying slip past its terms,
then they are stepping on `free as in speech' and `free as in beer'
to get to `free as in lunch'.
The concern is that developers with no intention of ever releasing under GPL would use the free libraries, possibly for a huge team, and then---at the last minute---buy one commercial license so their shipping product wouldn't actually have to be bound by the GPL. That really would be cheating... something not at all in the spirit of Open Source, Free Software, or the GPL. If you really did release your product under the GPL, and then also wanted to move to dual-licensing model... then we would have something to talk about. Otherwise, you're just trying get something that's `free as in lunch': neither contributing to the community, nor helping us develop the software from which you are directly benefiting.
That's the underlying theme in dual-licenses. Quid pro quo. You're getting something that benefits you; now you either pay it forward by sharing your work with the community, or else backward to the originator, to help them continue development.
...is that a single viewing (further experiments needed to assess the effect of multiple viewings) will not induce lasting deep tissue damage in the viewer.
Actually, this document is getting a little long in the tooth. In fact, we are beginning to make significantly greater use of templates. See, e.g., nsCOMPtr. It turns out templates largely work on a great many platforms. The initial versions of the portability guidelines were written by people with a decided anti-C++ bias, and some of the items were more influenced by anecdote than by test. I am the new owner of this document. I hope to bring it up to date, though that requires writing a lot of sample code and running it through the grinder of 18 or so compilers. Not necessarily something bug-count sensitive management will want me working on.
Slashdot Mirror
well put
We have an Idle section now?
"The Handbook of Algorithms and Data Structures" (in Pascal and C) Second Edition, by G.H. Gonnet and R. Baeza-Yates, ISBN 0-201-41607. It's a compact reference and analysis of a pretty broad range of algorithms. I also strongly second some of the other suggestions above such as Sedgewick, and Aho, Hopcroft, and Ullman. "The Stanford GraphBase" by Knuth, ISBN 0-201-54275-7 is great, though focused obviously. Beyond the basics, you'll end up looking in very specific books, such as "Text Compression" by Bell, Cleary, and Witten, ISBN 0-13-911991-4 or similar works applicable to the problem at hand. Some of the most interesting data structures I've seen I first encountered in journals. I can't seem to find it now, but it was in Journal of the ACM, if I recall correctly, I first learned a scheme to manage small sets that made membership-test, insertion, deletion, and finding the next member of the set all constant-time operations.
Where possible, of course, you don't want to implement these from scratch. You want to understand them so you know which apply to your problem, but then get code from, e.g. for C++, the Standard Library and Boost, both of which can also be a shopping list to spark further investigations.
Yes. One can't argue with that. Microsoft is very successful, just like De Beers, or Big Oil. Yes, they won, and not entirely by abusing monopoly powers. But they didn't win nicely, and neither the consumer nor the field of software development has benefitted from their win to the extent they might have in a world where Microsoft actually had to compete with innovators (instead of swallowing them whole).
In response to several scattered posts that touched on the GPL and `internal software'...
Let's dissect the interesting scenario. Your company is working on some software for internal use. You have no initial intention to sell or distribute it. It just solves some local problem you need solved. It's based on GPL software, hence, it's subject itself to the GPL. It embodies proprietary business logic that you would prefer not to share. Therefor, you decide not to distribute it, as once you did, the GPL would prevent you from further limiting what distributees could do with your proprietary business logic.
Theoretically, this might apply to your own employees: does `distributing' the software to them force the GPL to kick in? The Free Software Foundation's GPL FAQ has something to say on this topic: Is making and using multiple copies within one organization or company "distribution"? The short answer is 'no', that should be OK. In this situation, the FSF at least feels the GPL doesn't stop you from telling your employees not to give away your source code. On the other hand, that same FAQ item points out "In particular, providing copies to contractors for use off-site is distribution."
So when consultants from a professional consulting company come to help out and you have to give them a copy of the software so they can do their job, that does count as `distribution'. If a big company sends analysts to do due diligence, and you have to give them a copy of the software so they can complete their analysis, is that `distribution'? If the big company ends up buying your little company to keep as a research division, and they decide your software could be useful to their accounting team in Iceland, will that be `distribution'? Does the GPL give your Icelandic accountants permission to give away (or even sell) your proprietary business logic? These questions haven't yet been answered in the courts, but my gut feeling is at least two of them would absolutely be considered distribution, if not all three.
We could continue examining case-by-case to decide if we might be forced to obey the GPL in any particular situation. Those who ask `will the GPL apply to me' in this way plainly are asking because they don't want to be encumbered by the GPL. Those people shouldn't build atop GPL software; and they can have Qt unencumbered: just buy a commercial license.
Again, it goes back to the underlying theme in dual licenses of quid pro quo. Why in this situation would someone use GPL software in the first place? Do they truly intend to abide by letter and spirit of the GPL? If they do, then more power to them. They're getting something of value and they're electing to pay it forward by sharing their work with the community (in lieu of backward to the originator, funding continued development). On the other hand, if they are taking software under the GPL all the while trying slip past its terms, then they are stepping on `free as in speech' and `free as in beer' to get to `free as in lunch'.
The concern is that developers with no intention of ever releasing under GPL would use the free libraries, possibly for a huge team, and then---at the last minute---buy one commercial license so their shipping product wouldn't actually have to be bound by the GPL. That really would be cheating ... something not at all in the spirit of Open Source, Free Software, or the GPL. If you really did release your product under the GPL, and then also wanted to move to dual-licensing model... then we would have something to talk about. Otherwise, you're just trying get something that's `free as in lunch': neither contributing to the community, nor helping us develop the software from which you are directly benefiting.
That's the underlying theme in dual-licenses. Quid pro quo. You're getting something that benefits you; now you either pay it forward by sharing your work with the community, or else backward to the originator, to help them continue development.
...is that a single viewing (further experiments needed to assess the effect of multiple viewings) will not induce lasting deep tissue damage in the viewer.
Actually, this document is getting a little long in the tooth. In fact, we are beginning to make significantly greater use of templates. See, e.g., nsCOMPtr. It turns out templates largely work on a great many platforms. The initial versions of the portability guidelines were written by people with a decided anti-C++ bias, and some of the items were more influenced by anecdote than by test. I am the new owner of this document. I hope to bring it up to date, though that requires writing a lot of sample code and running it through the grinder of 18 or so compilers. Not necessarily something bug-count sensitive management will want me working on.
Essential C++ by Stanley B. Lippman ...only 276 pages long. This book is an excellent place to start, and covers templates in chapter 6.