Why do such a big number of people on/. think that 'Joe Public' needs every issue super-watered down and spoon fed to
them? It's very important to a democracy to have an educated public.
Doesn't have to be "watered down". However, to appeal to the "Joe Public", you need to actually address issues that they care about. They aren't going to care a whole lot about complaints from some academics, or the arrest of a Russian "hacker". (Being a Russian hacker in itself makes him suspicious... )
Appealing to high-minded constitutional and abstract moral principles might hold up on slashdot, indeed a similar strategy might even work quite well in court. But as a political strategy, it's doomed to failure.
I'm not getting it for free, first of all - I have a subscription and was promised a service in return.
I suppose you also think that paying a cover charge entitles you to unlimited drinks. You're paying the carrier fee. This is not enough to keep the networks in business, though it partly takes care of this. I'm curious, would you accept a much higher price (eg double) for no ads ?
Of course, the networks could move to a subscriber based monthly charge model, or a pay per view model, but I don't think most customers would be very happy with this.
The bottom line is that it boils down to money, and the slashdot herd don't want to pay up.
My problem with his complaint is that he is doing the same thing
that the record companies were doing several years ago -- proclaiming the evils of a new technology just because they
can't keep doing the same thing and keep growing profits*
The problem is that this model is actually quite good in a number of ways, because it keeps the cost down. However, there is an implied social contract. What the slashdot herd typically wish to do is take advantage of the low prices, but ignore the social contract. Basically, they don't want to hold up their end of the deal-- when you rely on an honor system, you'd better not deal with slashdotters!!! The outcome of this is that the freeloaders will ruin this for everyone and we'll be stuck with higher prices for services.
I still stand behind the two solutions I proposed before: Either provide a better service or out-maneuver your competition.
If profits go down, try something new.
If their model doesn't work, they will have to change it. However, if you think the change will mean catering to the mindless slashdot herds chants... "free-free-free"... then think again. That's not a viable business model. What will happen is that there will be a move towards a per-channel subscription based model (pay per channel), more PPV, and a higher base service charge.
Capitalism is Darwinism with money, folks. If the government steps in and regulates our TV-viewing so that the
consumers better fit the business model of the companies with the most congress(wo)men hanging out of their pockets,
then the "fittest" company is not most likely to survive anymore.
I agree that the government shouldn't step in here. However, he's dead on when he says that you can't get something for nothing. If the social contracts aren't adhered to, advertising dollars will go South and your cable prices will go up, then the slashdot herd will whine about how Cable is "too expensive" and get illegal cable installations for themselves, because "cable wants to be free (as in beer)"
Make your programming so compelling that viewers would rather tune in and watch your shows "live," thereby
rendering the 30-second-skip feature useless.
I'm sure all the networks would like to obtain
compelling content. After all, they do need to compete for ratings. However, there are constraints. It costs money to obtain content, and
not everyone agrees on what is "compelling".
The second solution is to change the length of commercials. What would happen if Turner sent out a memo to all of
its advertisers on all of its stations that it is now accepting 40 second commercials?
They'd lose advertising revenue.
Then
stations could start charging more money for ads.
But would that compensate for the smaller amount of ads ? I have another take on this-- appealing to the whims of the slashdot mob who want everything for free is not a good business strategy.
I think that if every lawyer who put out a crap case like this received lots of email and snail-mail, maybe they wouldn't be so eager to advise their clients to pick on people.
It wouldn't be the first time a lawyer had been harassed by a horde of obnoxious thugs. I think they'd just see it as part of the job. In any case, it would be unethical of them not to give their clients the best legal advice.
Therefore, it would almost certainly be legal to write a program that takes copyrighted truetype "programs" as input, and produces equivalent programs (that is, they generate the same typeface) that are not copyrighted.
You'd need to reverse-engineer them from rendered fonts, otherwise you're basically producing a "derived work", since it's just an obfuscated version of the original code. You lose a substantial chunk of quality when you reverse engineer them like this (and some of the slimeballs that were doing this did indeed sell such fonts at one stage)
And sometimes the right tool for the job is both (e.g. a high-level language which uses modules or sub-systems that are written in a low-level language).
Multi language development has problems of its own. For example, implementing objects in C is difficult and error prone. APIs for interpreted languages tend to be dangerous and error prone, especially if you want to develop complete classes in the lower level framework. This is often the
case if you want to develop software like GUI toolkits, or anything else that requires objects.
The end result is that you're going to have to roll
your own ad-hoc object system in the low level
language (think GTK), or use a low level object
system in some API which forces you to do hideous
and unnatural things like manually manipulating
reference counts and/or directly manipulating the stack (think implementing objects
using the Python API and writing perl modules)
Again, this makes C++ a practical solution. C++ is concerned with real world solutions to real world problems, not the appeasement of language masturbators.
Heh. What do you think matrix libraries have been written in for the last 30 years? FORTRAN or C! Yes, there are now C++ alternatives, and some of them are well crafted, but let's not pretend that "back before C++ saved the world" there was no way to do these things cleanly;-)
Take a look at those C and fortran implementations.
The vast majority of the ones I have seen are
positively hideous. In particular, a number of the
fortran ones are GOTO-laden spaghetti. Take
a look at the NR code for a hideous mess in C.
Of course it could be done, but the result was an unmaintainable mess.
And the vast success of COBOL is testomony to... um... nope, I'm not sure.
Then perhaps you need to think more deeply. There
are always good reasons why a technology succeeds.
Beauty and purity are not as important as you
think they are. At least two good reasons I
can think of are standardisation (how many standard languages were there in 1968 ?) and vendor support, in the sense that good implementations are available (which had a lot to do with standardisation)
Adoption of a language proves that the language can be applied to a number of problems. Whether or not it should cannot be ascertained by its adoption.
That it can be applied to a lot of problems is not
sufficient in itself. There are numerous other factors. Suffice it to say that abstract notions concepts of "truth", "beauty" and "purity" are not great reasons for adopting a language.
I hope some of you just had your blood run cold when you just realized why this won't work.
Ouch!!! I did. What this makes clear is that it's necessary to make it clear why the students work doesn't measure up to "the gold standard". When I was a TA in math, I often had to articulately defend my marking scheme, and actually argue the case that the students work was not up to scratch. I suppose this result does a lot to explain why.
Some of the others, however, such as the belief in pseudoscience, I'm not sure are as alarming. Is this really a disbelief in science, or simply a turning away from something I call "scientific exclusivism"?
The problem with pseudo-science is that it is typically made up of theories that should be, but are invariably not, empirically verified. For example, ESP is something that can easily be tested in a lab. Far from being open questions (like philosophical debate as to whether god exists), questions that can easily be answered with a simple lab test are closed.
Science doesn't attempt to "explain" anything-- it goes further than this by requiring standards of verifiability. Pseudoscience on the other hand claims to produce results, but mysteriously "stops working" when subjected to a sceptical eye.
Something that is purely conjectural like the existence of alien life forms, god/gods, etc does not fall under the umbrella of science or psedoscience.
BTW, your remark about Godel is utter nonsense. Goodels theorem has nothing to do with belief systems, it merely addresses mathematical axioms
and their logical consequences.
While it might be a good idea to implement set/map/vector in certain ways, the reality is that the standard provides no guidance on implementation (which is good), leaving vendors to make bad choices.
An excellent example is the performance of vector, which varies by a factor of three between various Linux compilers.
Unfortunately, I don't see any way the standard itself can address this. I'm not clear from your post whether it's the compilers themselves or STL implementations that are at fault either. If I had to guess, I'd guess that some compilers are optimising more than others.
Note that you need to turn on optimisations to avoid copping big "abstraction penalties", especially with vectors that have non-trivial iterators (ie the iterator is not a typedef or pointer)
I agree that this notion of "portable performance"
is a real and serious issue, but I think this problem is not the fault of the standard-- it's largely a problem with implementations (with the exception of std::string, which might or might not be reference counted) I'm not sure what could be done to the standard to improve this.
The string class that is almost part of the STL should be avoided. It is extremely inefficient to use, does not
implement reference counting, and will generally cause many more problems than
it is worth.
Actually, it's worse than this. Whether or not string uses reference counting is unspecified. As Austern notes, the trend is that COW reference counted implementations are falling out of favor. The fact that this is ambiguous is in itself a reason not to use std::string if performance matters.
It's worth mentioining that COW reference counted classes are actually a performance liability, because of the overhead incurred by checking when references are handed out (and because you can't give references out without forcing a deep copy). A better reference counted model would be an immutable reference counted string.
compiler that supports the export keyword may help bring code size down
Too bad such a compiler doesn't exist. There are other approaches though--implicit instantiation. Or compilers that are smart enough to collapse multiple instances.
So, building all library variants - static/shared/repo/optimized becomes a major PITA.
The answer to this one is simple-- never
trust a vendor who forces you to instantiate templates a certain way. Especially one that forces you to use -frepo (oh, and never use -frepo... )
In my experience, C++ iterators, algorithms, and containers are inefficient and unnecessarily complex.
In my experience, they're quite efficient if you compile with optimisation. YMMV. I disagree with
"Unnecessarily complex", if the complexity was not necessary, they wouldn't be used.
We need to refine the current standard before we
begin adding new material;
The problem is that refinements that remove functionality or otherwise break compatibility are impractical. At best we can deprecate features, but this doesn't mean a whole lot in practice.
Some people argue that,
for the sake of completeness, we should add hash-based containers to the standard library.
I don't think "completeness" is a good reason in itself. The container needs to be useful to enough people to justify including it in a standard library. IMO, hash tables are borderline, given that we already have maps.
someone might want balanced binary tree containers,
We already do (set/multiset and map/multimap)
And then we get into the whole issue of graphical development
I don't see how this follows-- it's an enormous leap. Graphical development is inherently nonportable and platform dependent, generic containers are not. The closest we've come to providing platform functionality is in file I/O libraries (especially the C-based ones).
Should a list
be sorted via its member method or the sort algorithm?
This is not an "inconsistency". The answer is consistently the same-- the member function should always be preferred over the non-member function. The reason is that member functions are included if and only if they are more efficient than the generic iterator based version (btw, the real inconsistency here is in requiring random access iterators for sort, but not for binary search. There's another good reason to use the member function-- the generic one can't be used on a list!)
I use about
20% of the vector template 80% of the time; it seems to me that C++ needs a functional hierarchy that stems from a set
of concise "base" containers.
20% ? The class has 36 member functions, counting overloads and const/non-const pairs, so that gives you 7. operator[] (const/non-const), assignment, a default and copy constructor, a
destructor, begin(), end(), size(), and empty() already put you a long way over (that's already 12 of the member functions). I don't forsee you doing anything useful without using at least 6 member functions.
As for "concise functional heirarchy", there is one-- the vector,list and deque are sequence containers, and the maps and sets are associative containers. Think of these as "abstract base containers". These "abstract" container families have common requirements.
The auto_ptr<> type has numerous logical and practical problems,
The decision to include auto_ptr as the only smart pointer was a terrible mistake, especially since its semantics (transfer-copy) are
inconsistent with the way the rest of the library works-- the library is consistent with a value semantics approach-- that is, a deep-copy policy.
I agree that "one size fits all" doesn't work. The sensible thing to do would be to include several different smart pointer classes (like the collection offered by boost). If one must choose a single one, a deep copy pointer seems sensible.
I'm still not convinced that automatic garbage collection is a good idea
in most applications;
Smart pointers are NOT "garbage collection". But they are a very good idea. I agree with your notion that they are not a license to be ignorant about resource management, and that thinking about them this way leads to chaos.
However, they are useful in that they let you choose an appropriate ownership model for
a given resource. Reference counting (shared ownership of a resource) is one such model.
Deep copy/value semantics is another model.
BTW, auto_ptr wasn't intended to be a general cure-all. Several auto_ptr proposals were submitted, and the ugly duckling auto_ptr was the only one that made it through the process.
The C++ container types are heavy and detailed, when what we need is a simple set of light,
fast containers, with hooks for adding algorithms that fit individual application needs.
That's what we have. Take a look at the member functions in any of the STL classes. There are relatively few. I count 46 in std::vector.
On C++, the language is brilliant and I have nothing but respect for the idea. It's just that C++ presents a great deal of risk
to a large development team that can be mitigated by choosing a language better suited to the task (either higher or lower
level, depending on what is required).
The entire problem with your reasoning is that you're mentally hung up on a sort of false dichotomy between "high level" and "low level". What about software that needs to handle matrix operations ? Sure one can implement it in C, but do you want to maintain the end result of such a hairball ? What about software that needs to be able to scale in both directions ? Not only is this idea that all languages "should" be "purely" high level, or "purely" low level wrong, the vast success of C++ is a testimony to this.
The idea that
everything exists in a language for a well-defined, unique reason is hardly a defense of the language DESIGN
The fact that there exists a well reasoned explanation of why these things exist most certainly is a convincing defense.
In a truely high-level language you would
only need one, and it would rely on the nature of the data to "do the right thing. In a truely low-level language you would
need only one and it would do what you told it to, even if it was the wrong thing.
Yawn! See "false dichotomy". C++ is was not designed to be "truly high level", or "truly low level". It's designed to solve real world problems, often at the expense of abstract notions of truth and beauty.
C++ doesn't either, it just gives you a way, assuming you
understand the language completely to ask the compiler to make it harder. This adds many layers of complexity and
provides you with the situation where the vast majority of C++ programmers continue to use the C-style cast.
(Shrug)
C++ is designed to be compatible with C. There are good reasons for this choice, and IMO the vast popularity of C++ is largely because of C compatibility. The fact that a lot of compilers use C-style casts is a reflection of this too- they use it because they are familiar with C.
Shouldn't your language be simple enough that those books aren't necessary, just to explain a core feature? Shouldn't your
compiler either do the work of resolving your complex relationships or get the heck out of your way?
There are a lot of properties "your language" "should" have, and no language has all of them. So you have to choose. C++ was not designed for abstract beauty. It was not designed for language masturbators. It was designed for people who need to solve real world problems. Simplicity and abstract beauty are not terribly good predictors of the success a language will have at solving real problems.
In Perl, it's considered a strength because the language is so
forgiving that it resolves many of the problems created this way
Horseshit. Perl lacks static type checking, which means that it's very easy to put subtle bugs in code, because of type errors (esp with numeric vs string types) C++ catches this sort of thing at compile time, and in fact with template types, it arguably has a better static checking mechanism than any other popular programming language.
C also requires that you adopt some common usage, but the advantage there is that C is so painfully simple that it is hard
to adopt a dialect that is wildly out of step with other programmers
Not at all. Consider the GTK+ object model (which is basically C++ on top of C), compared with more dynamic object models that can also be implemented in C. Consider the millions of different ways one can emulate parametrised types in C. C is only simple if you don't try to do very much with it. The moment you start needing associative containers, functors, and polymorphism, it gets very complex very quickly. Consider this-- how many different ways are there to do object oriented programming in C, and how many in C++ ? C++ provides an object model using well-defined semantics, while to use objects in C, you need to use your choice of idiosyncratic hack.
The other problem with your reasoning is the implicit assumption that a line of code is the level at which a human comprehends code. In practice, one reads code one function at a time. So having a simpler language isn't much help if the resulting functions have deeper nesting (eg switch vs polymorphism), longer parameter lists, and
more lines of code.
C++ is a very good accedemic exploration of the value of C as a high-level language. It's ultimately a poor choice for
real-world programming,
Hahahahaha... Academic ??? You're talking about what is arguably the most succesful language for developing useful real world applications. Here's a free clue-- your abstract notions oof "truth", "beauty", and "purity" don't mean sh*t when it comes to "real-world programming".
t sounds like these guys have a severe short-term cashflow problem, rather than a longterm profitability problem...
I would have thought short term cachflow problems would imply a long term profitability problem. It implies that they can't get a bank loan, and can't even get any investors, having already spent all the money the other foolhardy investors dumped in
their venture. IMO this isn't going to get better, and it's a good time to bail out.
It seems to me that the company is in DS if they can't grab hold of two weeks operating expenses of cacsh at short notice. It probably means they can't get a bank loan, and they are relying on screwing their investors. A good time to bail out.
std::string, just like std::vector. Those seem homogenous to me.
That they're in the same namespace does not make them "the same". Take a look at the designs of the two. They have very little in common.
There's also documentation on std::string (okay std::basic_string) in "The C++ Standard Library" by Nicolai M. Josuttis. That all makes it seem like string is part of the STL. What's your argument that it's NOT part of the STL?
Simple. It's not part of STL. This obviously begs the question, "what is STL ?".
The Josuttis book is about the Standard library. This is NOT the same thing as the STL. The standard library includes strings, streams, and valarrays. STL doesn't.
STL is the name of a library developed by SGI and HP that was incorporated into the standard.
The string class was part of the library before STL, and was designed independently, which is why it isn't consistent.
string a("%03d %s %0.2f", 1, "hello", 2.75);
That's not even typesafe. You can do the same thing more safely using std::ostringstream.
I'm not necessarily saying that there aren't "valid" things one may want to do with a string. My point is that none of these other things require additional member functions. In your
above example, you could write a make_string()
function that uses sprintf() to create your string.
Wouldn't it be better to have a centralized place where those decisions could be controlled, audited, and tested as a cohesive whole?
No. Smaller classes are easier to test, and less
likely to break, because there are less entry
points to the private data of the class, which
makes it harder to violate class invariants.
And that people should invent their own rich, application-specific APIs. (And if the underlying code behind their class is written using the STL, that's great - it's a rich toolset that's appropriate in many, many situations.)
I agree with this. But I'd do this by adding non-member functions. STL containers are not designed for subclassing, and subclassing them will get you into a lot of trouble in short order (think about the assignment operator, exception safety, and depending on how you extend, the destructor)
Now, I don't want to get off on a rant here, but in my personal opinion, the worst thing about STL is their string support.
I agree, but it's not part of STL.
Yes, it's highly optimized, but the API isn't very rich. I like rich APIs!
In other words, build your own string class, and give it a Has-A relationship to the STL string.
This is terrible advice. std::string already has way too many member functions as it is-- and you want to tack on more ??? The main problems with string is that it includes functionality that really should exist in the generic algorithms, and
the ambiguity re: whether or not string is reference counted is problematic.
The best way to extend string is to write algorithms or non-member functions. The existing member functions provide more than enough functionality.
Also, I hate that Containers change paradigms on you, some places you can use integer indecies,
You can't treat something that isn't random access as though it is. It's quite simple. BTW, the simplest way to get consistency is to use iterators all the time.
Also, the methods are written along the lines of, "if it's not optimal, you have to write the code yourself." I'm sorry - that sucks. Sometimes I need to remove an element from a Vector.
No. You can remove elements from a vector. Use erase(). The point is that there are generic algorithms. There are only special member functions in cases where a specific implementation for that container is more efficient than a naive iterator based implementation. For example, the list class can remove elements more efficiently, so it provides a special method for it. OTOH, the best one can hope for in a vector is the performance offered by the generic version, so no special member function is provided.
As a general rule, adding member functions is bad, because member functions are more tightly coupled to a class than non-member functions. This is why STL includes a lot of non-member functions. When you find that a container lacks a member function you want, always check to see that there's a generic lowest common denominator non-member. There usually is. Cheers,
Disadvantages of STL:- Large executable file sizes
While this is true, it's also worth mentioning that compiling with agressive optimisations (-O2 on gcc) makes a huge difference as far as executable size is concerned. For example, the 200k figure could probably be reduced by using optimisation switches. The inlining can sometimes be a blessing in instances where the template code "melts" to almost nothing after optimisation.
So why'd you have to go and top it? Are you actually expecting people to be able to drop in 3rd-party STL implementations on an embedded system?
STL is a source-code library. There is no
STL runtime. In other words, you don't pay for what you don't use.
However, STL classes are probably too big and complex for a lot of embedded systems purposes. Conservative applications of templates can work in
embedded systems, but careful attention needs to be paid to code size, and STL is not optisimised for producing small code.
I don't know what the solution to programming's difficult problems with reliability, reusability and maintainability, but I think Java has done a lot more to improve the state of the art in programming models, especially WRT these problems, than the STL.
You've got to be kidding! Java does not even have typesafe collection classes, and there appears to be various pushes in the java community to get parameterised types working...
No, they don't. If they were "selling Linux", ftp.kernel.org would be a better deal.
They provide the source, but not the actual ISOs or other form of download. I consider myself pretty savvy when it comes
to dealing with OSS software, and I wouldn't want to take on compiling all of the elements of a distro!
Exactly. They're selling the packaging and more importantly, maintenance of that packaging. They are not selling the software itself. In particular, they may fund software development, but this doesn't directly provide them with revenue (because the end result of that development is given away)
How anyone actually associates Linux with Piracy is beyond me and reflective of a lack of understanding the spirit of
MSFT's gripes.
The problem is that you have software like Napster that represents the freeloader movement getting confused with the free software movement. Popular websites like slashdot do more to hurt than to help with this problem. A lot of people are under the false impression that Linux and open source are about "free beer", and if you believe that, then it's not an enormous stretch to conclude that Linux is about piracy.
Slashdot Mirror
Doesn't have to be "watered down". However, to appeal to the "Joe Public", you need to actually address issues that they care about. They aren't going to care a whole lot about complaints from some academics, or the arrest of a Russian "hacker". (Being a Russian hacker in itself makes him suspicious ... )
Appealing to high-minded constitutional and abstract moral principles might hold up on slashdot, indeed a similar strategy might even work quite well in court. But as a political strategy, it's doomed to failure.
The solution is to publically refute those statements, and make Microsoft look stupid in the process. The solution to speech is more speech, not less.
I suppose you also think that paying a cover charge entitles you to unlimited drinks. You're paying the carrier fee. This is not enough to keep the networks in business, though it partly takes care of this. I'm curious, would you accept a much higher price (eg double) for no ads ? Of course, the networks could move to a subscriber based monthly charge model, or a pay per view model, but I don't think most customers would be very happy with this.
The bottom line is that it boils down to money, and the slashdot herd don't want to pay up.
My problem with his complaint is that he is doing the same thing that the record companies were doing several years ago -- proclaiming the evils of a new technology just because they can't keep doing the same thing and keep growing profits*
The problem is that this model is actually quite good in a number of ways, because it keeps the cost down. However, there is an implied social contract. What the slashdot herd typically wish to do is take advantage of the low prices, but ignore the social contract. Basically, they don't want to hold up their end of the deal-- when you rely on an honor system, you'd better not deal with slashdotters!!! The outcome of this is that the freeloaders will ruin this for everyone and we'll be stuck with higher prices for services.
I still stand behind the two solutions I proposed before: Either provide a better service or out-maneuver your competition. If profits go down, try something new.
If their model doesn't work, they will have to change it. However, if you think the change will mean catering to the mindless slashdot herds chants ... "free-free-free" ... then think again. That's not a viable business model. What will happen is that there will be a move towards a per-channel subscription based model (pay per channel), more PPV, and a higher base service charge.
Capitalism is Darwinism with money, folks. If the government steps in and regulates our TV-viewing so that the consumers better fit the business model of the companies with the most congress(wo)men hanging out of their pockets, then the "fittest" company is not most likely to survive anymore.
I agree that the government shouldn't step in here. However, he's dead on when he says that you can't get something for nothing. If the social contracts aren't adhered to, advertising dollars will go South and your cable prices will go up, then the slashdot herd will whine about how Cable is "too expensive" and get illegal cable installations for themselves, because "cable wants to be free (as in beer)"
I'm sure all the networks would like to obtain compelling content. After all, they do need to compete for ratings. However, there are constraints. It costs money to obtain content, and not everyone agrees on what is "compelling".
The second solution is to change the length of commercials. What would happen if Turner sent out a memo to all of its advertisers on all of its stations that it is now accepting 40 second commercials?
They'd lose advertising revenue.
Then stations could start charging more money for ads.
But would that compensate for the smaller amount of ads ? I have another take on this-- appealing to the whims of the slashdot mob who want everything for free is not a good business strategy.
It wouldn't be the first time a lawyer had been harassed by a horde of obnoxious thugs. I think they'd just see it as part of the job. In any case, it would be unethical of them not to give their clients the best legal advice.
You'd need to reverse-engineer them from rendered fonts, otherwise you're basically producing a "derived work", since it's just an obfuscated version of the original code. You lose a substantial chunk of quality when you reverse engineer them like this (and some of the slimeballs that were doing this did indeed sell such fonts at one stage)
Multi language development has problems of its own. For example, implementing objects in C is difficult and error prone. APIs for interpreted languages tend to be dangerous and error prone, especially if you want to develop complete classes in the lower level framework. This is often the case if you want to develop software like GUI toolkits, or anything else that requires objects. The end result is that you're going to have to roll your own ad-hoc object system in the low level language (think GTK), or use a low level object system in some API which forces you to do hideous and unnatural things like manually manipulating reference counts and/or directly manipulating the stack (think implementing objects using the Python API and writing perl modules) Again, this makes C++ a practical solution. C++ is concerned with real world solutions to real world problems, not the appeasement of language masturbators.
Heh. What do you think matrix libraries have been written in for the last 30 years? FORTRAN or C! Yes, there are now C++ alternatives, and some of them are well crafted, but let's not pretend that "back before C++ saved the world" there was no way to do these things cleanly ;-)
Take a look at those C and fortran implementations. The vast majority of the ones I have seen are positively hideous. In particular, a number of the fortran ones are GOTO-laden spaghetti. Take a look at the NR code for a hideous mess in C. Of course it could be done, but the result was an unmaintainable mess.
And the vast success of COBOL is testomony to... um... nope, I'm not sure.
Then perhaps you need to think more deeply. There are always good reasons why a technology succeeds. Beauty and purity are not as important as you think they are. At least two good reasons I can think of are standardisation (how many standard languages were there in 1968 ?) and vendor support, in the sense that good implementations are available (which had a lot to do with standardisation)
Adoption of a language proves that the language can be applied to a number of problems. Whether or not it should cannot be ascertained by its adoption.
That it can be applied to a lot of problems is not sufficient in itself. There are numerous other factors. Suffice it to say that abstract notions concepts of "truth", "beauty" and "purity" are not great reasons for adopting a language.
Ouch!!! I did. What this makes clear is that it's necessary to make it clear why the students work doesn't measure up to "the gold standard". When I was a TA in math, I often had to articulately defend my marking scheme, and actually argue the case that the students work was not up to scratch. I suppose this result does a lot to explain why.
The problem with pseudo-science is that it is typically made up of theories that should be, but are invariably not, empirically verified. For example, ESP is something that can easily be tested in a lab. Far from being open questions (like philosophical debate as to whether god exists), questions that can easily be answered with a simple lab test are closed.
Science doesn't attempt to "explain" anything-- it goes further than this by requiring standards of verifiability. Pseudoscience on the other hand claims to produce results, but mysteriously "stops working" when subjected to a sceptical eye.
Something that is purely conjectural like the existence of alien life forms, god/gods, etc does not fall under the umbrella of science or psedoscience.
BTW, your remark about Godel is utter nonsense. Goodels theorem has nothing to do with belief systems, it merely addresses mathematical axioms and their logical consequences.
Unfortunately, I don't see any way the standard itself can address this. I'm not clear from your post whether it's the compilers themselves or STL implementations that are at fault either. If I had to guess, I'd guess that some compilers are optimising more than others. Note that you need to turn on optimisations to avoid copping big "abstraction penalties", especially with vectors that have non-trivial iterators (ie the iterator is not a typedef or pointer)
I agree that this notion of "portable performance" is a real and serious issue, but I think this problem is not the fault of the standard-- it's largely a problem with implementations (with the exception of std::string, which might or might not be reference counted) I'm not sure what could be done to the standard to improve this.
Actually, it's worse than this. Whether or not string uses reference counting is unspecified. As Austern notes, the trend is that COW reference counted implementations are falling out of favor. The fact that this is ambiguous is in itself a reason not to use std::string if performance matters.
It's worth mentioining that COW reference counted classes are actually a performance liability, because of the overhead incurred by checking when references are handed out (and because you can't give references out without forcing a deep copy). A better reference counted model would be an immutable reference counted string.
compiler that supports the export keyword may help bring code size down
Too bad such a compiler doesn't exist. There are other approaches though--implicit instantiation. Or compilers that are smart enough to collapse multiple instances.
The answer to this one is simple-- never trust a vendor who forces you to instantiate templates a certain way. Especially one that forces you to use -frepo (oh, and never use -frepo ... )
In my experience, they're quite efficient if you compile with optimisation. YMMV. I disagree with "Unnecessarily complex", if the complexity was not necessary, they wouldn't be used.
We need to refine the current standard before we begin adding new material;
The problem is that refinements that remove functionality or otherwise break compatibility are impractical. At best we can deprecate features, but this doesn't mean a whole lot in practice.
Some people argue that, for the sake of completeness, we should add hash-based containers to the standard library.
I don't think "completeness" is a good reason in itself. The container needs to be useful to enough people to justify including it in a standard library. IMO, hash tables are borderline, given that we already have maps.
someone might want balanced binary tree containers,
We already do (set/multiset and map/multimap)
And then we get into the whole issue of graphical development
I don't see how this follows-- it's an enormous leap. Graphical development is inherently nonportable and platform dependent, generic containers are not. The closest we've come to providing platform functionality is in file I/O libraries (especially the C-based ones).
Should a list be sorted via its member method or the sort algorithm?
This is not an "inconsistency". The answer is consistently the same-- the member function should always be preferred over the non-member function. The reason is that member functions are included if and only if they are more efficient than the generic iterator based version (btw, the real inconsistency here is in requiring random access iterators for sort, but not for binary search. There's another good reason to use the member function-- the generic one can't be used on a list!)
I use about 20% of the vector template 80% of the time; it seems to me that C++ needs a functional hierarchy that stems from a set of concise "base" containers.
20% ? The class has 36 member functions, counting overloads and const/non-const pairs, so that gives you 7. operator[] (const/non-const), assignment, a default and copy constructor, a destructor, begin(), end(), size(), and empty() already put you a long way over (that's already 12 of the member functions). I don't forsee you doing anything useful without using at least 6 member functions. As for "concise functional heirarchy", there is one-- the vector,list and deque are sequence containers, and the maps and sets are associative containers. Think of these as "abstract base containers". These "abstract" container families have common requirements.
The auto_ptr<> type has numerous logical and practical problems,
The decision to include auto_ptr as the only smart pointer was a terrible mistake, especially since its semantics (transfer-copy) are inconsistent with the way the rest of the library works-- the library is consistent with a value semantics approach-- that is, a deep-copy policy.
I agree that "one size fits all" doesn't work. The sensible thing to do would be to include several different smart pointer classes (like the collection offered by boost). If one must choose a single one, a deep copy pointer seems sensible.
I'm still not convinced that automatic garbage collection is a good idea in most applications;
Smart pointers are NOT "garbage collection". But they are a very good idea. I agree with your notion that they are not a license to be ignorant about resource management, and that thinking about them this way leads to chaos. However, they are useful in that they let you choose an appropriate ownership model for a given resource. Reference counting (shared ownership of a resource) is one such model. Deep copy/value semantics is another model.
BTW, auto_ptr wasn't intended to be a general cure-all. Several auto_ptr proposals were submitted, and the ugly duckling auto_ptr was the only one that made it through the process.
The C++ container types are heavy and detailed, when what we need is a simple set of light, fast containers, with hooks for adding algorithms that fit individual application needs.
That's what we have. Take a look at the member functions in any of the STL classes. There are relatively few. I count 46 in std::vector.
The entire problem with your reasoning is that you're mentally hung up on a sort of false dichotomy between "high level" and "low level". What about software that needs to handle matrix operations ? Sure one can implement it in C, but do you want to maintain the end result of such a hairball ? What about software that needs to be able to scale in both directions ? Not only is this idea that all languages "should" be "purely" high level, or "purely" low level wrong, the vast success of C++ is a testimony to this.
The fact that there exists a well reasoned explanation of why these things exist most certainly is a convincing defense.
In a truely high-level language you would only need one, and it would rely on the nature of the data to "do the right thing. In a truely low-level language you would need only one and it would do what you told it to, even if it was the wrong thing.
Yawn! See "false dichotomy". C++ is was not designed to be "truly high level", or "truly low level". It's designed to solve real world problems, often at the expense of abstract notions of truth and beauty.
C++ doesn't either, it just gives you a way, assuming you understand the language completely to ask the compiler to make it harder. This adds many layers of complexity and provides you with the situation where the vast majority of C++ programmers continue to use the C-style cast.
(Shrug) C++ is designed to be compatible with C. There are good reasons for this choice, and IMO the vast popularity of C++ is largely because of C compatibility. The fact that a lot of compilers use C-style casts is a reflection of this too- they use it because they are familiar with C.
Shouldn't your language be simple enough that those books aren't necessary, just to explain a core feature? Shouldn't your compiler either do the work of resolving your complex relationships or get the heck out of your way?
There are a lot of properties "your language" "should" have, and no language has all of them. So you have to choose. C++ was not designed for abstract beauty. It was not designed for language masturbators. It was designed for people who need to solve real world problems. Simplicity and abstract beauty are not terribly good predictors of the success a language will have at solving real problems.
In Perl, it's considered a strength because the language is so forgiving that it resolves many of the problems created this way
Horseshit. Perl lacks static type checking, which means that it's very easy to put subtle bugs in code, because of type errors (esp with numeric vs string types) C++ catches this sort of thing at compile time, and in fact with template types, it arguably has a better static checking mechanism than any other popular programming language.
C also requires that you adopt some common usage, but the advantage there is that C is so painfully simple that it is hard to adopt a dialect that is wildly out of step with other programmers
Not at all. Consider the GTK+ object model (which is basically C++ on top of C), compared with more dynamic object models that can also be implemented in C. Consider the millions of different ways one can emulate parametrised types in C. C is only simple if you don't try to do very much with it. The moment you start needing associative containers, functors, and polymorphism, it gets very complex very quickly. Consider this-- how many different ways are there to do object oriented programming in C, and how many in C++ ? C++ provides an object model using well-defined semantics, while to use objects in C, you need to use your choice of idiosyncratic hack.
The other problem with your reasoning is the implicit assumption that a line of code is the level at which a human comprehends code. In practice, one reads code one function at a time. So having a simpler language isn't much help if the resulting functions have deeper nesting (eg switch vs polymorphism), longer parameter lists, and more lines of code.
C++ is a very good accedemic exploration of the value of C as a high-level language. It's ultimately a poor choice for real-world programming,
Hahahahaha ... Academic ??? You're talking about what is arguably the most succesful language for developing useful real world applications. Here's a free clue-- your abstract notions oof "truth", "beauty", and "purity" don't mean sh*t when it comes to "real-world programming".
I would have thought short term cachflow problems would imply a long term profitability problem. It implies that they can't get a bank loan, and can't even get any investors, having already spent all the money the other foolhardy investors dumped in their venture. IMO this isn't going to get better, and it's a good time to bail out.
That they're in the same namespace does not make them "the same". Take a look at the designs of the two. They have very little in common.
There's also documentation on std::string (okay std::basic_string) in "The C++ Standard Library" by Nicolai M. Josuttis. That all makes it seem like string is part of the STL. What's your argument that it's NOT part of the STL?
Simple. It's not part of STL. This obviously begs the question, "what is STL ?". The Josuttis book is about the Standard library. This is NOT the same thing as the STL. The standard library includes strings, streams, and valarrays. STL doesn't. STL is the name of a library developed by SGI and HP that was incorporated into the standard. The string class was part of the library before STL, and was designed independently, which is why it isn't consistent.
string a("%03d %s %0.2f", 1, "hello", 2.75);
That's not even typesafe. You can do the same thing more safely using std::ostringstream. I'm not necessarily saying that there aren't "valid" things one may want to do with a string. My point is that none of these other things require additional member functions. In your above example, you could write a make_string() function that uses sprintf() to create your string.
Wouldn't it be better to have a centralized place where those decisions could be controlled, audited, and tested as a cohesive whole?
No. Smaller classes are easier to test, and less likely to break, because there are less entry points to the private data of the class, which makes it harder to violate class invariants.
And that people should invent their own rich, application-specific APIs. (And if the underlying code behind their class is written using the STL, that's great - it's a rich toolset that's appropriate in many, many situations.)
I agree with this. But I'd do this by adding non-member functions. STL containers are not designed for subclassing, and subclassing them will get you into a lot of trouble in short order (think about the assignment operator, exception safety, and depending on how you extend, the destructor)
I agree, but it's not part of STL.
Yes, it's highly optimized, but the API isn't very rich. I like rich APIs! In other words, build your own string class, and give it a Has-A relationship to the STL string.
This is terrible advice. std::string already has way too many member functions as it is-- and you want to tack on more ??? The main problems with string is that it includes functionality that really should exist in the generic algorithms, and the ambiguity re: whether or not string is reference counted is problematic.
The best way to extend string is to write algorithms or non-member functions. The existing member functions provide more than enough functionality.
Also, I hate that Containers change paradigms on you, some places you can use integer indecies,
You can't treat something that isn't random access as though it is. It's quite simple. BTW, the simplest way to get consistency is to use iterators all the time.
Also, the methods are written along the lines of, "if it's not optimal, you have to write the code yourself." I'm sorry - that sucks. Sometimes I need to remove an element from a Vector.
No. You can remove elements from a vector. Use erase(). The point is that there are generic algorithms. There are only special member functions in cases where a specific implementation for that container is more efficient than a naive iterator based implementation. For example, the list class can remove elements more efficiently, so it provides a special method for it. OTOH, the best one can hope for in a vector is the performance offered by the generic version, so no special member function is provided.
As a general rule, adding member functions is bad, because member functions are more tightly coupled to a class than non-member functions. This is why STL includes a lot of non-member functions. When you find that a container lacks a member function you want, always check to see that there's a generic lowest common denominator non-member. There usually is. Cheers,
While this is true, it's also worth mentioning that compiling with agressive optimisations (-O2 on gcc) makes a huge difference as far as executable size is concerned. For example, the 200k figure could probably be reduced by using optimisation switches. The inlining can sometimes be a blessing in instances where the template code "melts" to almost nothing after optimisation.
STL is a source-code library. There is no STL runtime. In other words, you don't pay for what you don't use.
However, STL classes are probably too big and complex for a lot of embedded systems purposes. Conservative applications of templates can work in embedded systems, but careful attention needs to be paid to code size, and STL is not optisimised for producing small code.
You've got to be kidding! Java does not even have typesafe collection classes, and there appears to be various pushes in the java community to get parameterised types working ...
No, they don't. If they were "selling Linux", ftp.kernel.org would be a better deal.
They provide the source, but not the actual ISOs or other form of download. I consider myself pretty savvy when it comes to dealing with OSS software, and I wouldn't want to take on compiling all of the elements of a distro!
Exactly. They're selling the packaging and more importantly, maintenance of that packaging. They are not selling the software itself. In particular, they may fund software development, but this doesn't directly provide them with revenue (because the end result of that development is given away)
Rubbish. It's a timely clarification regarding the recent confusion with various freeloader movements (eg Napster) and the free software movement.
The problem is that you have software like Napster that represents the freeloader movement getting confused with the free software movement. Popular websites like slashdot do more to hurt than to help with this problem. A lot of people are under the false impression that Linux and open source are about "free beer", and if you believe that, then it's not an enormous stretch to conclude that Linux is about piracy.