Kitchen sink syndrome: There are a lot of features in STL, and to use some of them you need functors, etc. Sometimes it's just easier to read if you use a normal for loop instead of using for_each, etc.
This is a known problem in the STL. As some gurus have put it, "STL is not STL enough." What that means is that the STL falls short of using the full power of templates. Check out the Boost bind library (and later, the Lambda Library) for a solution to the for_each problem.
verbose type syntax: When you use the containers, like (say) std::vector, you have to declare your iterators as:
std::vector::iterator i;
If you change to a std::list container, you'll have to change your declarations. Of course, you can mitigate that by using typedefs, and then you only have to change the typedef, but it can still get a bit wordy.
typedef makes this a non-issue. I find the "wordiness" a nice form of in-code documentation.
unexpected results: Understand the difference between remove() and erase() in the containers.
It's unfair to label this "unexpected," but you're right in that knowledge of the API is important. As it is for all libraries.
The benefits of using STL are wonderful. If you write your custom containers/streams/etc. using the STL interface, you can seamlessly use the algorithms portion of the library.
This is the real power of the STL. IMHO too many people concentrate on "containers of X." This goes doubly for the C++ template engine as a whole.
I recommend reading the first part of
Generic Programming and the STL. It'll help you undestand the thinking behind the design.
The STL is great. Some of the stuff coming in the next library standard revision is even better. The stuff in Boost is outstanding.
The biggest problem I have had with the STL is convincing people to use it. The available implementations could be better (smaller, more template specialization, etc.) but the savings in programmer time is well worth the slight cost.
This will be a big win because the performance curve at the 8 register --> 16 register point is pretty steep.
Of course, all of those x86 compilers tuned for 8 registers will have to have some of their transformation throttles removed.:) This is an important secondary effect of adding registers. Not only is spill code decreased, but the efficacy of compiler transformations such as partial redundancy elimination and function inlining increases because values can live longer in their registers.
In my experience, Midiman has not been helpful. I once asked for specs for one of their old parport MIDI interfaces. No dice. They argued with the tired old "trade secret" line. How many ways can one interface to MIDI through the parallel port? I'll not buy from them again.
Lets see, has to be untouched for 3 weeks to go from testing to unstable right?
I assume you mean unstable->testing. It takes nowhere near three weeks for a package to be considered for migration into testing. From the Debian/testing FAQ:
What determines when a package moves into testing?
A (particular version of a) package will move into testing when it satisfies all of the following criteria:
It must have been in unstable for 10, 5 or 2 days, depending on the urgency of the upload;
It must be compiled on (at least) every architecture which the corresponding version in testing was compiled on;
It must have fewer release-critical bugs than, or the same number as, the version currently in testing;
All of its dependencies must either be satisfiable by packages already in testing, or be satisfiable by the group of packages which are going to be installed at the same time;
The operation of installing the package into testing must not break any packages currently in testing. (See below for more information)
A package which satisfies the first four of the above is said to be a Valid Candidate.
At most a package stays in unstable for 10 days. Less if it's a critical update. If packages it depends on are not in testing, then yes, it will hang around in unstable until those packages migrate. That is proper and safe behavior. That along with points 3, 4 and 5 above is what makes testing nearly rock-solid. The only way bugs get into testing is if developers using unstable don't detect a serious bug before the 10 days are up. That's very, very rare for commonly used packages and bugs in uncommon packages rarely hose the system. If it does happen, critical updates can short-circuit the 10-day waiting period.
Lets take Mozilla for example. 0.9.7 gets released, goes into testing... patches get added, things get fixed, more bugs, and all of a sudden, 0.9.8 gets released, starting the whole thing over... meanwhile unstable is still sitting on moz 0.9.2 or so.... just one example.
Again, testing<->unstable in the quote above. You're correct that this can sometimes be a problem. If a package remains broken for a long time, a new release can mess things up if the package maintainer isn't on the ball. Of course, one would hope the maintainer would fix the original package and then port the new release into the fixed package. But sometimes it's not always so easy.
I believe this is why XFree86 4.2 is being held off for now -- Branden wants to make sure that 4.1 is solid.
The whole Testing/unstable/stable transition is horrible. it's jut not designed to keep up with the rapidly changing digital world.
What's horrible about it? I'm running testing and feel that my system is reasonably up-to-date. I'd rather run a minimally-tested system (the Debian auto-builders automatically decide what goes into testing based on bug reports) than run bleeding-edge "current" software that hasn't been checked against my existing setup.
In the worst case, the Debian user can always apt-get -b source <package> from unstable,
though build-deps aren't always satisfiable.
Omaha stations hurt because people have a choice of stations? Very doubtful. In fact I bet they flourish.
Exactly. The one reason I really hesitate to go satellite is that I would lose two of the three PBS feeds we get on cable. I'd be left with the reasonably good PBS from Detroit but would lose the absolutely excellent Toledo PBS station. If I could get Toledo PBS on satellite I'd do it in a second.
With the exception of MIT, the schools you list just don't have the same level of reputation, at least in the engineering programs. NE schools do have a strong tradition of computer science and computer theory, which is something I wish we had more of here in the midwest.
After reflection, I realize that I was far too hard on out NE siblings. There is much fine research and many fine students coming out of the NE. I didn't want to imply that the NE is a wasteland of computing either as it is the home of IBM, Digital, Bell Labs and Data General.
My comment was more of a defense of the midwest than an attack on the NE but it didn't come off that way. My apologies. Coming from a moderately-sized midwest school not known for its engineering program, I know that reputation is not everything. A lot of schools doing very good work don't get the credit they deserve.
Of course, most of that is a sad shell of what it used to be -- a result of changing computing paradigms. But to say that the midwest is a wasteland of computing just displays ignorance about a great deal of important computing history.
I forgot to add that in addition to the presence of the University of Minnesota medical center and the Mayo Clinic, Minnesota is home to some very well-respected biotech companies. 3M and Medtronic are both heavily involved in biotech and of course 3M is also well-known for many other contributrions. So when one looks at the whole technology world, the midwest really isn't so bad off.:)
So why is the NE (along with the Bay Area) such a concentration of high tech if it is so techno-dumb?
As others have pointed out, this is an opinion survey -- it's not scientific fact. There are plenty of tech-saavy people all over.
I don't see high tech companies flocking to the mid west.
Minneapolis/St. Paul was the Silicon Valley of the 50's and 60's. Both Cray and Control Data started in the midwest. Sperry, Honeywell, Unisys and others also had large presences.
Of course, most of that is a sad shell of what it used to be -- a result of changing computing paradigms. But to say that the midwest is a wasteland of computing just displays ignorance about a great deal of important computing history.
Michigan is making a huge push to bring technology firms into the state.
Also, what about all those little schools like Harvard, MIT, BU, NE, etc that are in the NE?
The midwest has a very strong tradition of highly respecting university computing centers: Illinois, Wisconsin and Michigan are always ranked at or near the top, easily on par with the likes of Berkeley and Stanford. Minnesota has a huge supercomputing research center.
With the exception of MIT, the schools you list just don't have the same level of reputation, at least in the engineering programs. NE schools do have a strong tradition of computer science and computer theory, which is something I wish we had more of here in the midwest.
That's not to say wonderful things haven't come out of those schools. But Harvard is not Harvard because of its engineering program. In fact, I believe they tried to kill it at one point (or maybe that was Princeton).
I am willing to bet that the need for transparent networking, while really freaking cool and useful, has deminished greatly in recent years, especially with desktops becoming much more powerful and with the move away from terminal/host to client/server computing.
You'd lose that bet pretty quickly. Right now I am connected to a Sun station in one of the common engineering clusters here from my office in the EECS department. EECS can't sport the money for nice tools like Purify (go figure) so I have to run them on the.engin machines. I'd be pretty much out of luck without X's network transparency.
I use remote X from home all of the time. It's a little slow over dialup, but good enough for what I have to do.
If telnet is useful, it seems pretty obvious to me that a graphical analogue would be as well.
Proof was a much more personal play about a woman's relationship with her father (and indeed, the world around her.) The math is simply part of the plot, not interwoven with the primary thrust. I saw both original casts, and both were phenominal, but the interaction between Mary Louise Parker and the cast was one of the most thrilling dramatic performances I've ever witnessed. She was incredible.
Agreed on all points. Mary Louise Parker was just fantastic. The math is really just a vehicle to explore relationships. Relationships drive good drama.
I haven't seen Copenhagen, so I can't compare. However, I can say that Proof is a wonderful play.
How exactly does make (or really, GNU Make) fail to compute dependencies properly, when you give it all the information needed? (i.e, you include everything into one big Makefile, instead of using recursive make calls.)
Exactly.:) Yes, one can use a tool to aggregate a Makefile, but why do that rather than using a build system that actually works as expected? This is not a slam on make. It's simply an observation that another, perhaps better tool exists.
An open source project that uses their own version of Jam are the boost libraries at http://www.boost.org/
Ahh, you are a knowledgeable one.:) I was hoping someone would mention jam. It not only handles platform-dependent tasks, it's a full replacement for make and actually generates correct dependencies. It might be a little tough to convert a make-based project to jam, but it's the way I would go starting out.
boost.build
is the build system for the Boost libraries which, as mentioned, uses jam. In fact it uses an advanced version of jam with many new features. I'm not sure if those will be rolloed back into the "official" jam sources (boost jam is actually a derivative of FT Jam, from the FreeType project).
Jamfiles (analogous to Makefiles) are platform-independent. A "Jamrules" file holds all the configuration-specific information. Some systems use autoconf to generate this. Boost does not and their build system is very flexible, allowing one to not only define platform-dependent things but also specify build features such as whether to make static of shared libraries (or both!), optimization levels, etc. A single build run can build shared and static libraries at several optimization levels, for example.
How is this definition any less arbitrary than the one I gave? In a sense it is more arbitrary because in addition to defining what human life is, one needs to define the criteria of sentience.
An embryo, no matter how little developed, will grow and develop according to the design of our species. True, some will have more flaws than others, sometimes very serious ones. But it is still human life.
If you're going to argue that a pancreas or liver is sentient, by all means, go ahead.
Where did I do that? An embryo, while having stem cells that can "become" any sort of human cell at all, will still, if left alone, develop into an adult just like you and me. I object to killing this life before it has a chance to do so.
Why do you think "at conception" is the earliest *possible* point we could consider life to have begun? The Catholics, after all, still discourage birth control where possible; it's apparently their view that life begins at ejaculation.
The birth control issue is a complex one. At its core, the teaching stresses that we should be open to the working of God in our lives. Humanae Vitae also considers the effect of artificial birth control on our attitudes toward sex and each other. Once sex has no consequences it is very easy for us to treat it casually and hurt others in the process, either through a degradation of our views of the opposite sex or through sharing a very intimate moment that sends the strongest possible signals of total commitment when no such commitment exists in the relationship.
The relationship argument seals the deal for me as far as premarital sex in general goes. I have no desire to convey a commitment that isn't there yet. To do so causes great harm to the other person.
In the married relationship I have a much harder time with the teaching. It's true that casual sex in marriage is also detramental to the relationship, so in that sense it's important not to cheapen the act by removing all consequences. However, the "Catholic birth control" method of Natural Family Planning also takes away from the spontaneity of sex and can lead to resentment if the times for intercourse are "scheduled."
That said, once conception happens a new life has entered the world and we dare not extinguish it.
Re:Before the flame wars start...
on
GTK-- vs. QT
·
· Score: 1
Anything that can be done with templates can be done with the preprocessor.
That is simply not so. The preprocessor can't do type checking. As Andrei Alexandrescu recently pointed out, the preprocessor cannot be used in general to create C++ typelists (the commas in template specifications confuse the preprocessor).
From a pragmatic standpoint, it's just because it's impossible to define exactly when human life begins that we should be very conservative about it. At conception is the earliest possible point, so it seems reasonable to define it that way.
Of course, there are many higher theological reasons for doing so, but I'm specifically presenting a secular view.
This is something I've always wondered about. Is the much-ballyhooed 35 year age limit for our forefathers a reality? There's no doubt that childhood deaths were more common, but I have a sneaking suspicion that if one made it past, say, 5 years, a good long life was fairly likely.
I'm not bringing this up as a criticism. I'm genuinely curious. If my suspicions are correct, the argument you put forth is a specious one.
I'm all for medical research. As long as it doesn't require the sacrifice or exploitation of human life. The annouced cloning and plans for its use certainly does.
including the research that was just announced, which is not meant to clone entire human beings, but an effort to conduct stem cell research to produce transplantable organs by taking dna from a patient and cloning compatible organ cells, to reduce the risk of rejection.
Research like this and embryonic stem cell research in general raises a very simple ethical question, one so simple that I think most people miss it: Does any of us have the right to use another human being to better ourselves? Whether that human being is fully devloped or not doesn't really matter. The fact is that it is human life.
Whether by cloning or otherwise, using people in this way is simply wrong. Though religious folk have a theological basis for this conclusion, it doesn't take a belief in God to come to it.
The long term plan for this company is to be able to use a synthetic process and skip the reproductive cells altogether, but to get there there needs to be intense research on how the stem cell process works, so that a organ specific process can be developed, which doesn't run the ethical risk of creating a whole person if some cells were quickly stolen from the lab and placed in a womb.
And why, exactly, is cloning necessary to do this? If the end goal is to take cells from the patient, shouldn't the research involve adult stem cells? Not only would we have the ability to clone organs, we'd also be able to rid ourselves of the need to exploit undeveloped human beings.
I find it somewhat ironic that so much research goes on with materials that have the potential to kill large amounts of human life...but research with the potential to create human life is so strongly opposed.
Well, we really don't need to learn anything new to create human life. There is lots of research going on to extend and improve the quality of human life outside the world of embryonic stem cells.
Re:I switched from Gtk-- to Qt
on
GTK-- vs. QT
·
· Score: 1
Of course, moc doesn't have all of these problems but it does do a significant amount of translation not visibile to the compiler.
I don't see how this is a problem in practice. I've made heavy use of Qt, and generated code hasn't made life any more difficult or confusing.
No, you are right. There aren't many debugger problems I can think of that one would encounter with moc. But then I haven't used it heavily so I'm not the best person to ask. What about invoking a signal from the debugger? I was answering the question "in the large" about why, in general, preprocessors are a bad idea. Sometimes you need them, though.
At this point, most compilers can handle the template code necessary to implement signals and slots within the language.
But why templates ? I suppose they might make people with a strong aversion to preprocessors feel better. There are a lot of potential pitfalls with templates (static typing, tight coupling, etc), so I'm sceptical.
Again, using the preprocessor to generate code is really not a great idea. I can't tell you how many times I've cursed software developers who implement C functions as macros so they don't have to cut-and-paste, changing types along the way. This is one of the problems templates solve.
Templates are useful in C++ precisely because it is a statically typed language. I always cringe a little bit when I see code that casts away the compiler's good sense. There are of course cases where it is useful if used in a disciplined manner (void * implementations, for example). If one needs dynamic typing, use a more dynamic language.
I haven't personally found coupling to be a problem. Templates are less tightly bound than non-template code because they don't care anything about class heirarchies. Rather than conforming to type interfaces, template parameters need only conform to syntactic interfaces.
It's true that template code can sometimes result in an "explosion of templates" as one tries to fit a generic component into an existing framework. I have found that it is better to design for genericity at the outset. Templates usually result in better designs for me because I have to think about interfaces, concepts and genericity.
Templates aren't good for everything. I don't think widget classes should be templatized. But signals and slots are components of widgets, not the widgets themselves.
Well, they do parts of it. std::string is a fine string class.
But most compilers don't ship a unicode version.
Excellent point. I think a better solution would have been a TrollTech unicode traits class for std::string. There's much less code to write and the class automatically works with std libraries. Plus most programmers are already familiar with the interface. At the time, of course, TT didn't have this option.
As for containers, one can have containers of pointers in the std C++ library provided they are wrapped in smart pointers like Boost's shared_ptr.
Reference counting is a terrible choice of memory management policy for GUI programming
There are several garbage collectors available for C++. I was just providing a starting place. The fexibility of std allocators is very nice.
The policy Qt uses, where parent widgets manage their children is much smarter.
I found it confusing, but you are right that when there is a definite concept of ownership, reference counting may not work. One can imagine a smart pointer that enforces ownership. std::auto_ptr does that, though it was really only designed to solve a very specific problem and shouldn't be used as a general owned_ptr. Boost's scoped_ptr may be what you're looking for.
The "template bloat problem" should really be called the "template implementation problem." It's only because most std C++ library implementations follow the original SGI offering that we have bloat problems.
Yes and no. Template bloat is a fundamental problem with templates.
I don't see it as a problem at all. Templates prevent the cut-and-paste code one often sees with C. When designed sensibly to factor out common code (via void * or otherwise), templates present an extremely powerful framework providing flexibility without sacrificing type safety or efficiency. It's a classic size vs. speed/development time tradeoff.
Perhaps much of the bloat results from vendors shipping products compiled in debug mode.
Compiler transformations have an enormous impact on the size and speed of template code.
Re:Before the flame wars start...
on
GTK-- vs. QT
·
· Score: 1
Ah, you misunderstood me. I am absolutely not arguing that one should use C to write OO code. I think that's a ludicrous strategy, unless there are very, very good reasons to do so (unavailable compilers, etc.). You are correct that templates as such can't be written in C. One writes templates in C via cut-and-paste.:) My point is that templates are not magical. Sometimes the code looks like it, but it ain't.
I was attempting to show that C++ really isn't the bloated monster that most people seem to think. It is because of ignorance that most people shy away from C++, relying on anecdotal evidence obtained either via hearsay or from programmers not versed in C++ who feel the need to use every new whiz-bang feature and idiom they learn. C++ is a big language and it takes years to master. But once there, one is amazed by its power and flexibility.
Re:I switched from Gtk-- to Qt
on
GTK-- vs. QT
·
· Score: 1
As for the preprocessor, I don't see why it's a "bad thing".
It's a bad thing because the compiler doesn't see it. Debug symbols can't be generated, macros can't be called from within the debugger, constants are only visible as raw numbers, etc. Of course, moc doesn't have all of these problems but it does do a significant amount of translation not visibile to the compiler.
That said, moc was a fine solution to the C++ compiler problem back in its day. At this point, most compilers can handle the template code necessary to implement signals and slots within the language. An advanced signals and slots library is being developed for Boost, a collection of peer-reviewed C++ libraries. Some have already been submitted for inclusion in the standard committee's library technical report (i.e. to be considered for the nex rev. of the standard).
They don't "duplicate it"
Well, they do parts of it. std::string is a fine string class. Actually, probably a little too featureful. As for containers, one can have containers of pointers in the std C++ library provided they are wrapped in smart pointers like Boost's shared_ptr.
As for "poorly", the Qt collection classes do a much better job than STL of avoiding the "template bloat" problem (they do this by using for the most part pointer containers based on the void* implementation)
The "template bloat problem" should really be called the "template implementation problem." It's only because most std C++ library implementations follow the original SGI offering that we have bloat problems. Andrei Alexandrescu (of Modern C++ Design fame) annouced some time back that he is working to build an ultra-efficient STL based on void * implementations where appropriate. I'm not sure what the status on that is, as he is getting heavily involed with Boost. Note that sometimes one wants template bloat because that's where expression templates and functor templates get their efficiency (because they are inlined).
Re:Before the flame wars start...
on
GTK-- vs. QT
·
· Score: 1
Actually, James is correct. Any compiler based on the Edison Design Group frontend can translate C++ into C code. EDG is considered the "son of cfront" by Bjarne. The compilers may not expose this capability but it is there.
Note that I did not say "equivalent C." In the translation to C the compiler loses the chance to apply some very important transformations such as the empty-base-class optimization. Internally, of course, the EDG frontend keeps all the high-level C++ information so compilers can implement their own object model. It's only if the code is lowered to C code that it loses out.
Templates, of course, are implemented via code duplication. It's really not rocket science, though those writing the parsers would disagree.:) In fact it is this duplication that makes expression templates and functor templates so fast.
Slashdot Mirror
This is a known problem in the STL. As some gurus have put it, "STL is not STL enough." What that means is that the STL falls short of using the full power of templates. Check out the Boost bind library (and later, the Lambda Library) for a solution to the for_each problem.
typedef makes this a non-issue. I find the "wordiness" a nice form of in-code documentation.
It's unfair to label this "unexpected," but you're right in that knowledge of the API is important. As it is for all libraries.
This is the real power of the STL. IMHO too many people concentrate on "containers of X." This goes doubly for the C++ template engine as a whole.
Then get Modern C++ Design , join the Boost mailing list and take it to the next level.
The STL is great. Some of the stuff coming in the next library standard revision is even better. The stuff in Boost is outstanding.
The biggest problem I have had with the STL is convincing people to use it. The available implementations could be better (smaller, more template specialization, etc.) but the savings in programmer time is well worth the slight cost.
This will be a big win because the performance curve at the 8 register --> 16 register point is pretty steep.
Of course, all of those x86 compilers tuned for 8 registers will have to have some of their transformation throttles removed. :) This is an important secondary effect of adding registers. Not only is spill code decreased, but the efficacy of compiler transformations such as partial redundancy elimination and function inlining increases because values can live longer in their registers.
In my experience, Midiman has not been helpful. I once asked for specs for one of their old parport MIDI interfaces. No dice. They argued with the tired old "trade secret" line. How many ways can one interface to MIDI through the parallel port? I'll not buy from them again.
I assume you mean unstable->testing. It takes nowhere near three weeks for a package to be considered for migration into testing. From the Debian/testing FAQ:
At most a package stays in unstable for 10 days. Less if it's a critical update. If packages it depends on are not in testing, then yes, it will hang around in unstable until those packages migrate. That is proper and safe behavior. That along with points 3, 4 and 5 above is what makes testing nearly rock-solid. The only way bugs get into testing is if developers using unstable don't detect a serious bug before the 10 days are up. That's very, very rare for commonly used packages and bugs in uncommon packages rarely hose the system. If it does happen, critical updates can short-circuit the 10-day waiting period.
Again, testing<->unstable in the quote above. You're correct that this can sometimes be a problem. If a package remains broken for a long time, a new release can mess things up if the package maintainer isn't on the ball. Of course, one would hope the maintainer would fix the original package and then port the new release into the fixed package. But sometimes it's not always so easy.
I believe this is why XFree86 4.2 is being held off for now -- Branden wants to make sure that 4.1 is solid.
Is that actually true? Dang, I was hoping to switch over to KMail with KDE3. This deficiency kills that idea completely.
What's horrible about it? I'm running testing and feel that my system is reasonably up-to-date. I'd rather run a minimally-tested system (the Debian auto-builders automatically decide what goes into testing based on bug reports) than run bleeding-edge "current" software that hasn't been checked against my existing setup.
In the worst case, the Debian user can always apt-get -b source <package> from unstable, though build-deps aren't always satisfiable.
After reflection, I realize that I was far too hard on out NE siblings. There is much fine research and many fine students coming out of the NE. I didn't want to imply that the NE is a wasteland of computing either as it is the home of IBM, Digital, Bell Labs and Data General.
My comment was more of a defense of the midwest than an attack on the NE but it didn't come off that way. My apologies. Coming from a moderately-sized midwest school not known for its engineering program, I know that reputation is not everything. A lot of schools doing very good work don't get the credit they deserve.
I forgot to add that in addition to the presence of the University of Minnesota medical center and the Mayo Clinic, Minnesota is home to some very well-respected biotech companies. 3M and Medtronic are both heavily involved in biotech and of course 3M is also well-known for many other contributrions. So when one looks at the whole technology world, the midwest really isn't so bad off. :)
Of course, most of that is a sad shell of what it used to be -- a result of changing computing paradigms. But to say that the midwest is a wasteland of computing just displays ignorance about a great deal of important computing history.
Michigan is making a huge push to bring technology firms into the state.
The midwest has a very strong tradition of highly respecting university computing centers: Illinois, Wisconsin and Michigan are always ranked at or near the top, easily on par with the likes of Berkeley and Stanford. Minnesota has a huge supercomputing research center.
With the exception of MIT, the schools you list just don't have the same level of reputation, at least in the engineering programs. NE schools do have a strong tradition of computer science and computer theory, which is something I wish we had more of here in the midwest.
That's not to say wonderful things haven't come out of those schools. But Harvard is not Harvard because of its engineering program. In fact, I believe they tried to kill it at one point (or maybe that was Princeton).
You'd lose that bet pretty quickly. Right now I am connected to a Sun station in one of the common engineering clusters here from my office in the EECS department. EECS can't sport the money for nice tools like Purify (go figure) so I have to run them on the .engin machines. I'd be pretty much out of luck without X's network transparency.
I use remote X from home all of the time. It's a little slow over dialup, but good enough for what I have to do.
If telnet is useful, it seems pretty obvious to me that a graphical analogue would be as well.
Agreed on all points. Mary Louise Parker was just fantastic. The math is really just a vehicle to explore relationships. Relationships drive good drama.
I haven't seen Copenhagen, so I can't compare. However, I can say that Proof is a wonderful play.
Exactly. :) Yes, one can use a tool to aggregate a Makefile, but why do that rather than using a build system that actually works as expected? This is not a slam on make. It's simply an observation that another, perhaps better tool exists.
I've not used Jam or boost.build myself but I'm planning on diving into it in the future.
Ahh, you are a knowledgeable one. :) I was hoping someone would mention jam. It not only handles platform-dependent tasks, it's a full replacement for make and actually generates correct dependencies. It might be a little tough to convert a make-based project to jam, but it's the way I would go starting out.
boost.build is the build system for the Boost libraries which, as mentioned, uses jam. In fact it uses an advanced version of jam with many new features. I'm not sure if those will be rolloed back into the "official" jam sources (boost jam is actually a derivative of FT Jam, from the FreeType project).
Jamfiles (analogous to Makefiles) are platform-independent. A "Jamrules" file holds all the configuration-specific information. Some systems use autoconf to generate this. Boost does not and their build system is very flexible, allowing one to not only define platform-dependent things but also specify build features such as whether to make static of shared libraries (or both!), optimization levels, etc. A single build run can build shared and static libraries at several optimization levels, for example.
How is this definition any less arbitrary than the one I gave? In a sense it is more arbitrary because in addition to defining what human life is, one needs to define the criteria of sentience.
An embryo, no matter how little developed, will grow and develop according to the design of our species. True, some will have more flaws than others, sometimes very serious ones. But it is still human life.
Where did I do that? An embryo, while having stem cells that can "become" any sort of human cell at all, will still, if left alone, develop into an adult just like you and me. I object to killing this life before it has a chance to do so.
The birth control issue is a complex one. At its core, the teaching stresses that we should be open to the working of God in our lives. Humanae Vitae also considers the effect of artificial birth control on our attitudes toward sex and each other. Once sex has no consequences it is very easy for us to treat it casually and hurt others in the process, either through a degradation of our views of the opposite sex or through sharing a very intimate moment that sends the strongest possible signals of total commitment when no such commitment exists in the relationship.
The relationship argument seals the deal for me as far as premarital sex in general goes. I have no desire to convey a commitment that isn't there yet. To do so causes great harm to the other person.
In the married relationship I have a much harder time with the teaching. It's true that casual sex in marriage is also detramental to the relationship, so in that sense it's important not to cheapen the act by removing all consequences. However, the "Catholic birth control" method of Natural Family Planning also takes away from the spontaneity of sex and can lead to resentment if the times for intercourse are "scheduled."
That said, once conception happens a new life has entered the world and we dare not extinguish it.
That is simply not so. The preprocessor can't do type checking. As Andrei Alexandrescu recently pointed out, the preprocessor cannot be used in general to create C++ typelists (the commas in template specifications confuse the preprocessor).
Pardon? Tell that to Thomas Aquinas. :)
From a pragmatic standpoint, it's just because it's impossible to define exactly when human life begins that we should be very conservative about it. At conception is the earliest possible point, so it seems reasonable to define it that way.
Of course, there are many higher theological reasons for doing so, but I'm specifically presenting a secular view.
I'm not bringing this up as a criticism. I'm genuinely curious. If my suspicions are correct, the argument you put forth is a specious one.
I'm all for medical research. As long as it doesn't require the sacrifice or exploitation of human life. The annouced cloning and plans for its use certainly does.
Research like this and embryonic stem cell research in general raises a very simple ethical question, one so simple that I think most people miss it: Does any of us have the right to use another human being to better ourselves? Whether that human being is fully devloped or not doesn't really matter. The fact is that it is human life.
Whether by cloning or otherwise, using people in this way is simply wrong. Though religious folk have a theological basis for this conclusion, it doesn't take a belief in God to come to it.
And why, exactly, is cloning necessary to do this? If the end goal is to take cells from the patient, shouldn't the research involve adult stem cells? Not only would we have the ability to clone organs, we'd also be able to rid ourselves of the need to exploit undeveloped human beings.
Well, we really don't need to learn anything new to create human life. There is lots of research going on to extend and improve the quality of human life outside the world of embryonic stem cells.
No, you are right. There aren't many debugger problems I can think of that one would encounter with moc. But then I haven't used it heavily so I'm not the best person to ask. What about invoking a signal from the debugger? I was answering the question "in the large" about why, in general, preprocessors are a bad idea. Sometimes you need them, though.
Again, using the preprocessor to generate code is really not a great idea. I can't tell you how many times I've cursed software developers who implement C functions as macros so they don't have to cut-and-paste, changing types along the way. This is one of the problems templates solve.
Templates are useful in C++ precisely because it is a statically typed language. I always cringe a little bit when I see code that casts away the compiler's good sense. There are of course cases where it is useful if used in a disciplined manner (void * implementations, for example). If one needs dynamic typing, use a more dynamic language.
I haven't personally found coupling to be a problem. Templates are less tightly bound than non-template code because they don't care anything about class heirarchies. Rather than conforming to type interfaces, template parameters need only conform to syntactic interfaces.
It's true that template code can sometimes result in an "explosion of templates" as one tries to fit a generic component into an existing framework. I have found that it is better to design for genericity at the outset. Templates usually result in better designs for me because I have to think about interfaces, concepts and genericity.
Templates aren't good for everything. I don't think widget classes should be templatized. But signals and slots are components of widgets, not the widgets themselves.
Excellent point. I think a better solution would have been a TrollTech unicode traits class for std::string. There's much less code to write and the class automatically works with std libraries. Plus most programmers are already familiar with the interface. At the time, of course, TT didn't have this option.
There are several garbage collectors available for C++. I was just providing a starting place. The fexibility of std allocators is very nice.
I found it confusing, but you are right that when there is a definite concept of ownership, reference counting may not work. One can imagine a smart pointer that enforces ownership. std::auto_ptr does that, though it was really only designed to solve a very specific problem and shouldn't be used as a general owned_ptr. Boost's scoped_ptr may be what you're looking for.
I don't see it as a problem at all. Templates prevent the cut-and-paste code one often sees with C. When designed sensibly to factor out common code (via void * or otherwise), templates present an extremely powerful framework providing flexibility without sacrificing type safety or efficiency. It's a classic size vs. speed/development time tradeoff.
Perhaps much of the bloat results from vendors shipping products compiled in debug mode. Compiler transformations have an enormous impact on the size and speed of template code.
I was attempting to show that C++ really isn't the bloated monster that most people seem to think. It is because of ignorance that most people shy away from C++, relying on anecdotal evidence obtained either via hearsay or from programmers not versed in C++ who feel the need to use every new whiz-bang feature and idiom they learn. C++ is a big language and it takes years to master. But once there, one is amazed by its power and flexibility.
It's a bad thing because the compiler doesn't see it. Debug symbols can't be generated, macros can't be called from within the debugger, constants are only visible as raw numbers, etc. Of course, moc doesn't have all of these problems but it does do a significant amount of translation not visibile to the compiler.
That said, moc was a fine solution to the C++ compiler problem back in its day. At this point, most compilers can handle the template code necessary to implement signals and slots within the language. An advanced signals and slots library is being developed for Boost, a collection of peer-reviewed C++ libraries. Some have already been submitted for inclusion in the standard committee's library technical report (i.e. to be considered for the nex rev. of the standard).
Well, they do parts of it. std::string is a fine string class. Actually, probably a little too featureful. As for containers, one can have containers of pointers in the std C++ library provided they are wrapped in smart pointers like Boost's shared_ptr.
The "template bloat problem" should really be called the "template implementation problem." It's only because most std C++ library implementations follow the original SGI offering that we have bloat problems. Andrei Alexandrescu (of Modern C++ Design fame) annouced some time back that he is working to build an ultra-efficient STL based on void * implementations where appropriate. I'm not sure what the status on that is, as he is getting heavily involed with Boost. Note that sometimes one wants template bloat because that's where expression templates and functor templates get their efficiency (because they are inlined).
Note that I did not say "equivalent C." In the translation to C the compiler loses the chance to apply some very important transformations such as the empty-base-class optimization. Internally, of course, the EDG frontend keeps all the high-level C++ information so compilers can implement their own object model. It's only if the code is lowered to C code that it loses out.
Templates, of course, are implemented via code duplication. It's really not rocket science, though those writing the parsers would disagree. :) In fact it is this duplication that makes expression templates and functor templates so fast.