Slashdot Mirror

hm, boost seems to be there... hopefully things like gtkmm will start making their way in so c++ developers don't need to download half-of-the-world before they can start coding...

soup++

As for regression/unit testing : unless the software arcitecture supporting this, it will not be done. Quite simply because it's time consuming, and changing the arcithecture might very well be too costly. However, there are Open Source tools available, like for C++ test lib. Similar tools excists for Java, based on ideas from one of The Gang of Four in Design Patterns.

First of all, the discussion so far has been pretty immature.

To answers the most common question (why name C++0x), the name of the language is still C++. For standardized languages, it's common to refer to the different dialects by their 2-digit year extensions. Such as C89, F77, C99, etc. The use of C++98 and C++0x are merely used to disginuish the language at that particular standard.

Most of the library features of the new standard are already in the Boost library. Things like threads, regexs, smart pointers, are all there.

The smart pointer is actually one of the most highly debated topics because a stronger smart pointer is easy to implement but requires a new language feature (and even though this feature is likely to make it in, there's a requirement that all proposed libraries not required additional language features).

The focus on the new standard is really expanding the standard library (the goal is a library for C++ as useful as the ANSI library for C). Since C++ is committee based though (unlike Java), it takes a long time for these things to happen since it involves comprimise between many strongly-opinionated smart folks.

On the one hand, the language evolves slowly, but on the other hand, when it is ready, it will be a beautiful thing.

How fast 'n cheap are smart pointers?????

Indirecting through them is quite fast, copying them is much more costly then for normal pointers (because there is a reference count involved), but the total work is still quite tiny. Throwing them away again is much more costly (there is actually a real destructor, and it decrements a value as opposed to the normal "do absolutely nothing at all"). However in real use I have a program that used 2.7% of the CPU before using boost's implementation of them, and it went all the way up to 2.7% afterwards. So at least in my case it was unmesurable.

Anyway as it is just a library issue, and a freely re-distributable open source implementation is available now (I think boost uses a BSDL like license), why wait for C++0x?

Boost also has a lot of other useful stuff in it, and a lot of stuff I don't find useful. It is worth some time to poke through though.

Take a look at boost::lambda. There's a proposal to include it in the standard.
It lets you do the right thing, e.g. :
for_each(a.begin(), a.end(), cout (1 + _1));

Not quite as sexy as a functional language, but useful w/minimal overhead.

lambdas and metafunctions: boost and spirit. However, I agree with you that they should become core langauge fetaures. Notably, that's what Boost is - a group that's working on implementing, in a rigorous and standard-friendly fashion, potential extensions. it's droolworthy; I'd say even moreso than Loki, though visible policies make other people's code far less painful. (Yay, Phoenix!)

As far as type inference, I disagree.

cParentClass * foo = new cChildClass();

what's the redundancy of cFoo = new Foo(); ? You specify the type of the thing and then identify the creator and pass it information. Because you always have matched types and creators simply says that your code doesn't require some of the more complex leveraging of the language.

Auto seems convenient at first, but consider the potential for problems. And really, what does it gain you? Five or six keystrokes, in the greater scheme of things, really just isn't that important. Predictability and specificity are, in my opinion, far more important.

If you're so hard up for horizontal space that you can't make a single definition, stop tabbing 8 spaces, put a using or two in place, or get a bigger monitor. Jeez.

1. The boost guys have developed MPL, which really does seem to work reasonably well.
2. The boost lambda library, if you can get it to compile, gives you most of what you'd want with regard to lambdas.
3. You can sort of use the "any" stuff in the boost library to accomplish this. Honestly though, with C++'s already complex semantics, I would not want to add type inferencing. I suspect things would get FAR too unpredictable.

Try the Boost Lambda library. It's hardly perfect, but it works well for most purposes.

Modern C++ is a wonderful language, at least I think so. But it is much different than the "old" C++, almost to the point of being a different language. So if you've had bad experiences with C++ in the past, perhaps you should give it another look. And C++ is not dead, there are a lot of interesting advancements in the language, and more properly how to use it. There are a whole lot of generic programming and template patterns which are comming out which show that C++ has a lot more power than people ever thought.

Of course C++ does tend to have some problems with Open Source projects, which C usually doesn't have. So I certainly don't frown on C development either. And plain old C is usually very easy to integrate into other languages/environments.

1. C++ compilers are just now catching up to the standard. gcc 3.3 for instance is pretty darn good now, but lots of compilers have lots of problems.
2. C++ can be very slow to compile (or more technically to link), especially as you use lots of templates.
3. The binary ABI is not universal. It's hard to write shared libraries in C++, so it's not as useful for components as it is an entire application.
4. Dynamic linking in of C++ is next to impossible (dynamic linking often uses the dlopen() system calls, and it how most run-time plugin architectures, such as in Apache or Python work).
5. Although in theory C++ is very portable, in practice that is still difficult (usually a victim of poor linkers). C++ which works fine under Linux may have serious problems under say AIX or HP-UX, unless you test on those platforms.

However, C++ is certainly still alive and very viable on a whole. And O'Reilly just published the new C++ in a Nutshell book which covers the ISO standard C++ very well. Also you should look at the Boost Project if you're looking for more advanced C++ libraries (many of the Boost developers actively participate in the C++ standardaization effort, and Boost is often thought of as the testbed for possible language additions for the next round of standardization).

But I do agree, that you need to pick the language according to the project. There is no one best language. When I look for other open source projects with the intent of being able to take advantage of the openness (i.e., modify the code), I tend to look for projects written in Python. I particularly avoid Perl, becuase it is much harder for me to understand. I also avoid Java because it's a proprietary language with no open source JDE/JDK and I think the language sucks when compared to ISO C++. But again, those are my preferences.

Well, I don't see why we need to #define everything. But a good interval arithmetic library would be nice. Now that boost have one for C++ (haven't tried it myself), maybe people will even start using it.

The reason for the #define is so that you can turn the use of this library off and on without changing any code. I usually call my floats Real with a typedef so that I can change their underlying representation without a define, but you can't count on this in everyone's code.

This makes no sense. If you think you can do #define double interval_double in C/C++, I see no reason why it should be harder to do in lisp. In fact, as everything else, it should be much easier in lisp, and it has most likely also been done by lispers since at least the 1950's.

That part is easy to do in LISP, I meant that as a jibe against Java lacking operator oveloading. Are exceptions part of LISP now though? I guess you don't need them, you can wrap your expressions in a function that takes an interval_double and deals with error conditions like a catch statement in C++ would. So I guess LISP wins the "you can do it in LISP!" arguement, but at least not the "That's been in LISP since 1832" arguement ;)

I'll have to check out this boost interval arithmetic library, I didn't know about it.

i've been looking at the boost c++ regex library http://www.boost.org/libs/regex/ and i'm going to give it a try. as i'm doing more c++ programming these days ( i've been lucky to have been doing perl for the last couple of years :) ), i've been looking for quality, cross-platform, license-compatible c++ classes; boost seems quite good (and it's peer-reviewed, too)

i also just found this benchmark http://research.microsoft.com/projects/greta/regex _perf.html comparing boost vs. microsoft's greta http://research.microsoft.com/projects/greta/ which gives you "all the power of Perl 5 regular expressions in your C++ applications. These easy-to-use classes let you perform regular expression pattern matches on strings in C++." (from the website)

For an excellent example of the power of the C preprocessor and some of its more advanced usage see The Boost Library Preprocessor Subset for C/C++.

This makes sense when you think about it from their risk-averse perspective: releasing even small pieces of otherwise-useless specialized code is all downside and no upside.

But that's not entirely true... there is a distinct downside, although whether or not you want to bring it up is up to you.

If you don't release the changes back then you must make sure that any GPL or LGPL code you use (or similarly licensed code) is never, ever distributed to an outside party. That places a potentially immense risk on your codebase, since violation could mean forfeiture of all of your copyrights to the code (at least in the case of GPL). At the very least it would mean replacing all of those bits with code written entirely by your company, or purchased from another company and then integrated -- both of which are huge time sucks.

Of course, the risk of pleading this case is that they'll simply say not to use any GPL/LGPL code at all. To which you can only argue time and cost... and I know that without libraries like Boost, OTL, libxml, PCRE, and libcurl we'd be writing a shitload more code, taking far more time, and have a far less stable product.

And that's not even counting things like gcc, automake, gmake, vim, cvs, and other tools we use to actually create and maintain code! (No... no gdb... it seriously dislikes AIX 4.3 and C++)

Lambda library, compile-time parser generator library, graph algorithms, regular expressions, safe threads, and on and on.

If you write a template method, you don't know what kinds of objects you are really working with. It is not always bad, but one of the problems with that is that IDEs will not be able to assist you with code completion and misc. refactorings.

The other problem with templates is that (at least with the C++ implementation) to use them without getting Cobol fingers, one has to write lots of typedefs, and those typedefs do hide what's underneath.

The main advantage of templates is the additional compile-time type checking, which arguably is not really needed, if you write tests for the code.

(C++ also has operator overloading, which lets use templates (conveniently) to implement lamda expressions. But Java doesn't have operator overloading, so this bonus doesn't apply here.)

See also boost::lambda

At least C# doesn't have some awful templating system. (Watch me get replies from people claiming to enjoy templates).

For an excellent example of the power of C++ templates and oft-maligned operator overloading, take a look at Boost's brilliant Spirit Library that allows you to write EBNF-style grammars in C++. eg:

rule<> group = '(' >> expression >> ')';
rule<> factor = integer | group;
rule<> term = factor >> *(('*' >> factor) | ('/' >> factor));
rule<> expression = term >> *(('+' >> term) | ('-' >> term));
bool valid = parse ("(1+2)*3", expression, space_p).full;

At least C# doesn't have some awful templating system. (Watch me get replies from people claiming to enjoy templates).

For an excellent example of the power of C++ templates and oft-maligned operator overloading, take a look at Boost's brilliant Spirit Library that allows you to write EBNF-style grammars in C++. eg:

rule<> group = '(' >> expression >> ')';
rule<> factor = integer | group;
rule<> term = factor >> *(('*' >> factor) | ('/' >> factor));
rule<> expression = term >> *(('+' >> term) | ('-' >> term));
bool valid = parse ("(1+2)*3", expression, space_p).full;

Let's face it, languages with security features are more suitable for servers.

Uh, exactly what security features are you looking for?

I'm assuming you're going to be using the STL... if you're not, well then I hope you're not planning on using any Perl modules or Python libraries either, because otherwise you're really comparing apples and oranges (not that you aren't already, but that's another discussion).

std::string and std::vector take care of most of the security concerns you might have -- presuming you use them properly of course. If you need to deal with pointers and std::auto_ptr isn't useful (which, in general, it's not) then use a smart pointer library -- I highly recommend Boost - I've used it's shared_ptr class and like it. In over a year of serious C++ development we've had exactly one memory related problem -- and that was from me misusing boost (and suspecting I was doing so during development but forgetting about it during testing).

The general concerns with C/C++ are buffer overruns and other memory stomps. If you use the right libraries it's not an issue in either (go look at vsftpd's string functions for an example of what I'm talking about in C). If you're writing insecure C++ code then it's most likely because you're ignoring significant language features (like the STL). It's not a language issue.

If you want to see what the future of real world programming looks like, like no further than Boost. I say this because Boost demonstrates the programming techniques of the future that work on compilers available now. In theory, Boost techniques work on any standards compliant C++ compiler. Given that most compilers these days are still pretty weak on their standards compliance, the friendly Boosters have already coded a great number of work arounds so you can still use the libraries.

Something that you might find surprising, though, is that the future is the past. Sort of. The future is shaping up to be a synthesis of great ideas from the past. Functional programming and metaprogramming are making a resurgence, except this time in moderation. You see, in the melting pot that is C++, you're not forced into any particular paradigm, and you get to use what works best for each subproblem. The real beauty, though, is that only library writers really need to be experts in this multi-paradigm thing; application writers can go about their merry business relatively unaffected, except with libraries so powerful you can't understand until you've tried them.

For a sample of libraries to really blow your mind, check out

1) Boost Lambda Library, which adds lambda function capabilities to C++. This is a staggering because C++ doesn't have lambda functions (like Lisp does).

2) Spirit Parser Framework lets you write parsers in a natural EBNF type notation, without the need to run a seperate pre-processing tool like Lex/Yacc (Flex/Bison).

3) Meta Programming Library. This ones a little tougher to wrap your head around if you've never tried writing generically reusable libraries. This is a library designed for other library writers, so #1 and #2 above make extensive use of this.

4) Preprocessor Library. This is a library to help you do meta programming with the C/C++ preprocessor. See, not all inovation is coming from those new fangled template things. You'll just have to look at the examples to get why it's cool.

The best part is that, unlike Perl 6, you can use this stuff now. Play around with, see how it works. You will be stunned, amazed, awed, etc by what these people have done. And you don't have to "get it" to use it.

If you want to see what the future of real world programming looks like, like no further than Boost. I say this because Boost demonstrates the programming techniques of the future that work on compilers available now. In theory, Boost techniques work on any standards compliant C++ compiler. Given that most compilers these days are still pretty weak on their standards compliance, the friendly Boosters have already coded a great number of work arounds so you can still use the libraries.

Something that you might find surprising, though, is that the future is the past. Sort of. The future is shaping up to be a synthesis of great ideas from the past. Functional programming and metaprogramming are making a resurgence, except this time in moderation. You see, in the melting pot that is C++, you're not forced into any particular paradigm, and you get to use what works best for each subproblem. The real beauty, though, is that only library writers really need to be experts in this multi-paradigm thing; application writers can go about their merry business relatively unaffected, except with libraries so powerful you can't understand until you've tried them.

For a sample of libraries to really blow your mind, check out

1) Boost Lambda Library, which adds lambda function capabilities to C++. This is a staggering because C++ doesn't have lambda functions (like Lisp does).

2) Spirit Parser Framework lets you write parsers in a natural EBNF type notation, without the need to run a seperate pre-processing tool like Lex/Yacc (Flex/Bison).

3) Meta Programming Library. This ones a little tougher to wrap your head around if you've never tried writing generically reusable libraries. This is a library designed for other library writers, so #1 and #2 above make extensive use of this.

4) Preprocessor Library. This is a library to help you do meta programming with the C/C++ preprocessor. See, not all inovation is coming from those new fangled template things. You'll just have to look at the examples to get why it's cool.

The best part is that, unlike Perl 6, you can use this stuff now. Play around with, see how it works. You will be stunned, amazed, awed, etc by what these people have done. And you don't have to "get it" to use it.

If you want to see what the future of real world programming looks like, like no further than Boost. I say this because Boost demonstrates the programming techniques of the future that work on compilers available now. In theory, Boost techniques work on any standards compliant C++ compiler. Given that most compilers these days are still pretty weak on their standards compliance, the friendly Boosters have already coded a great number of work arounds so you can still use the libraries.

Something that you might find surprising, though, is that the future is the past. Sort of. The future is shaping up to be a synthesis of great ideas from the past. Functional programming and metaprogramming are making a resurgence, except this time in moderation. You see, in the melting pot that is C++, you're not forced into any particular paradigm, and you get to use what works best for each subproblem. The real beauty, though, is that only library writers really need to be experts in this multi-paradigm thing; application writers can go about their merry business relatively unaffected, except with libraries so powerful you can't understand until you've tried them.

For a sample of libraries to really blow your mind, check out

1) Boost Lambda Library, which adds lambda function capabilities to C++. This is a staggering because C++ doesn't have lambda functions (like Lisp does).

2) Spirit Parser Framework lets you write parsers in a natural EBNF type notation, without the need to run a seperate pre-processing tool like Lex/Yacc (Flex/Bison).

3) Meta Programming Library. This ones a little tougher to wrap your head around if you've never tried writing generically reusable libraries. This is a library designed for other library writers, so #1 and #2 above make extensive use of this.

4) Preprocessor Library. This is a library to help you do meta programming with the C/C++ preprocessor. See, not all inovation is coming from those new fangled template things. You'll just have to look at the examples to get why it's cool.

The best part is that, unlike Perl 6, you can use this stuff now. Play around with, see how it works. You will be stunned, amazed, awed, etc by what these people have done. And you don't have to "get it" to use it.

If you want to see what the future of real world programming looks like, like no further than Boost. I say this because Boost demonstrates the programming techniques of the future that work on compilers available now. In theory, Boost techniques work on any standards compliant C++ compiler. Given that most compilers these days are still pretty weak on their standards compliance, the friendly Boosters have already coded a great number of work arounds so you can still use the libraries.

Something that you might find surprising, though, is that the future is the past. Sort of. The future is shaping up to be a synthesis of great ideas from the past. Functional programming and metaprogramming are making a resurgence, except this time in moderation. You see, in the melting pot that is C++, you're not forced into any particular paradigm, and you get to use what works best for each subproblem. The real beauty, though, is that only library writers really need to be experts in this multi-paradigm thing; application writers can go about their merry business relatively unaffected, except with libraries so powerful you can't understand until you've tried them.

For a sample of libraries to really blow your mind, check out

1) Boost Lambda Library, which adds lambda function capabilities to C++. This is a staggering because C++ doesn't have lambda functions (like Lisp does).

2) Spirit Parser Framework lets you write parsers in a natural EBNF type notation, without the need to run a seperate pre-processing tool like Lex/Yacc (Flex/Bison).

3) Meta Programming Library. This ones a little tougher to wrap your head around if you've never tried writing generically reusable libraries. This is a library designed for other library writers, so #1 and #2 above make extensive use of this.

4) Preprocessor Library. This is a library to help you do meta programming with the C/C++ preprocessor. See, not all inovation is coming from those new fangled template things. You'll just have to look at the examples to get why it's cool.

The best part is that, unlike Perl 6, you can use this stuff now. Play around with, see how it works. You will be stunned, amazed, awed, etc by what these people have done. And you don't have to "get it" to use it.

If you want to see what the future of real world programming looks like, like no further than Boost. I say this because Boost demonstrates the programming techniques of the future that work on compilers available now. In theory, Boost techniques work on any standards compliant C++ compiler. Given that most compilers these days are still pretty weak on their standards compliance, the friendly Boosters have already coded a great number of work arounds so you can still use the libraries.

Something that you might find surprising, though, is that the future is the past. Sort of. The future is shaping up to be a synthesis of great ideas from the past. Functional programming and metaprogramming are making a resurgence, except this time in moderation. You see, in the melting pot that is C++, you're not forced into any particular paradigm, and you get to use what works best for each subproblem. The real beauty, though, is that only library writers really need to be experts in this multi-paradigm thing; application writers can go about their merry business relatively unaffected, except with libraries so powerful you can't understand until you've tried them.

For a sample of libraries to really blow your mind, check out

1) Boost Lambda Library, which adds lambda function capabilities to C++. This is a staggering because C++ doesn't have lambda functions (like Lisp does).

2) Spirit Parser Framework lets you write parsers in a natural EBNF type notation, without the need to run a seperate pre-processing tool like Lex/Yacc (Flex/Bison).

3) Meta Programming Library. This ones a little tougher to wrap your head around if you've never tried writing generically reusable libraries. This is a library designed for other library writers, so #1 and #2 above make extensive use of this.

4) Preprocessor Library. This is a library to help you do meta programming with the C/C++ preprocessor. See, not all inovation is coming from those new fangled template things. You'll just have to look at the examples to get why it's cool.

The best part is that, unlike Perl 6, you can use this stuff now. Play around with, see how it works. You will be stunned, amazed, awed, etc by what these people have done. And you don't have to "get it" to use it.

Functional languages may not seem to be getting used much at the moment, but the ideas that they present are seeping into a lot of current thought on language design and use.

The latest incarnations of Python seem to be quite heavily influenced by Functional concepts (lambdas and so on), and they are even creeping into C++, despite the fact that people always seem to classify it as Object Oriented. Several of the boost libraries show this kind of approach - there is a lamda library, a 'function' library that lets the programmer pass functions around as if they were objects and so on.

I don't have enough experience with functional languages to say how close these ideas match up with functional theory, but I'm already using them in production code and benefiting from the results. Anyone else out there think that python and c++ would be better classified as 'hybrid' languages than 'OO' ?

boost.org seems to have some pretty neat stuff; however, i've never used thier stuff...

fwiw (and moderately on topic), clr ("introduction to algorithms", but i suppose with the new edition that should be clrp...) has a boatload of string searching algorithms in it, including (i *think* -- i haven't flipped through much more than the graph section recently) the knuth-morris-pratt algorithm. i've generally found their pseudo-code to be reasonably readable (certainly more so than 90+% of the freely available code that i've tried to read).

Studies have shown that programmer productivity, measured by lines of code over time, varies little between languages.

Great! Now let's move on to some benchmark that actually matters. Lines of code over time has never been a good benchmark. Better ones are number of bugs, time to milestone, number of milestones accomplished on time, and user satisfaction. No, none of them are perfect. Welcome to reality.

the low-level constructs that C and C++ programmers spend time managing are the same ones that can get them into trouble

Sure, if you code using no libraries and are a dumbass about it. Heck, you can avoid most of the vulnerabilities he's talking about in C++ just by using std::string. Most of the other worries can be eliminated by using decent libraries like boost (its pointer templates are great) or Loki. In C it's a bit harder, but there's secure string and memory libraries available there too (I recently poked around in vsftp which is straight C code and uses wrappers for all string functions).

There's no need to move to a different language - although I definitely agree with different languages for different purposes - but you definitely need to know how to write things properly in the language you do use.

And while he acknowledges that high-level languages aren't immune to security bugs, he also seems to forget that most high level languages are written in lower level ones (such as Perl being written in C). A mistake in the code that creates the high level code can leave the entire thing wide open and you're back to square one. On the upside you only have to patch the language. On the downside you have dozens or hundreds of vulnerable programs instead of one or two.

Of course, the author also seems to forget that not everything was written in the past two or three years. Just how old is lpr? Is rewriting it - in any language - really going to be worth it?

Finally, the author's list of vulnerable programs at the start starkly contrasts with his suggestions at the end. Of the six listed four (kernel, openssl, mysql, and glibc) are not applicable for rewriting in high level code - by the author's own admission. One of them (openssl) is not even a language issue - it's implementation. The last two could, in theory, be written in high level languages, but lpr seriously predates Perl or Python. Mutt might have been a candidate for a high level language though - so 1 out of the 6 is a viable gripe.

The author does make a good point... it's just buried in his pointless bashing of C/C++. You need to know your tools, and you need to know how to code securely. The tools can help, but if you don't code securely then all they can do is block the more egregious sins... and those are rarely the ones that get exploited (they get blocked or patched quickly).

Also note that C++ is flexible enough to do it the java way. For example:

class Object {};

class String : public Object {
public:
String(string s) :internal(s) {}
operator string() { return internal; }
private:
string internal;
};

class Int : publoc Object{
public:
Int(int i) :internal(i) {}
operator int() { return internal; }
private:
int internal;
};

stack<Object&> MyStack;

Then you can do it the "Java" way. If you don't feel like typing that code, boost has a library that does the same thing.

Actually, there is one key thing that templates can do that nothing in C can: code generation. Templates can allow you to generate type-safe, generic classes (particularly data structures) well-optimized to the actual data type they contain. Aside from hand coding multiple implementations for different data types, or losing type-saftey by using void pointers, you just can't do this in C. Ditto for stuff like design patterns implemented as templates or a number of other powerful techniques. Read Modern C++ and take a look at some of the modern C++ websites (especially Boost).

www.boost.org
The documentation for the tuple library is here

What you want are "expression templates" (do a search, or look at Boost) which does what you suggest with plain C++.

Spirit has to be seen to be believed. Basically you contruct a parser which looks like normal extended Backus-Normal Form (EBNF) but the source you write is 100% C++ source code - not run through a preprocessor:


struct calculator : public grammar<calculator> {
template <typename ScannerT>
struct definition {
definition(calculator const& self) {
expression = term
>> *( ('+' >> term)[&do_add]
| ('-' >> term)[&do_subt]
);
term = factor
>> *( ('*' >> factor)[&do_mult]
| ('/' >> factor)[&do_div]
);
factor = lexeme_d[(+digit_p)[&do_int]]
| '(' >> expression >> ')'
| ('-' >> factor)[&do_neg]
| ('+' >> factor);
}
rule<ScannerT> expression, term, factor;
rule<ScannerT> const& start() const { return expression; }
};
};


This is truly a testimony to the power and expressiveness of C++ operator overloading and templates.

As an aside, Perl6 is slated to have lexer/yaccer rule syntax built into the language itself. It's really an exciting time for users of computer languages.

Spirit has to be seen to be believed. Basically you contruct a parser which looks like normal extended Backus-Normal Form (EBNF) but the source you write is 100% C++ source code - not run through a preprocessor:


struct calculator : public grammar<calculator> {
template <typename ScannerT>
struct definition {
definition(calculator const& self) {
expression = term
>> *( ('+' >> term)[&do_add]
| ('-' >> term)[&do_subt]
);
term = factor
>> *( ('*' >> factor)[&do_mult]
| ('/' >> factor)[&do_div]
);
factor = lexeme_d[(+digit_p)[&do_int]]
| '(' >> expression >> ')'
| ('-' >> factor)[&do_neg]
| ('+' >> factor);
}
rule<ScannerT> expression, term, factor;
rule<ScannerT> const& start() const { return expression; }
};
};


This is truly a testimony to the power and expressiveness of C++ operator overloading and templates.

As an aside, Perl6 is slated to have lexer/yaccer rule syntax built into the language itself. It's really an exciting time for users of computer languages.

I was not basing my comparison of the GUI speed on server side benchmarks. The Windows API is not object oriented or even good.

Where the hell did I mention the Windows API? If you're talking about Windows Forms, it is a part of the .NET framework. See? To clarify, it IS object oriented and, however subjective this statement may be, it IS good.

Even if I was talking about the Windows API, I'm still not entirely sure of what you're on about. Passing IDs? You mean handles? Yeah it's not object oriented - it doesn't have to be, it's written in C: a procedural language. I suppose the Linux Kernel developers must really suck in your eyes, 'cause they're not OOP monkeys.

And if you want to talk about wasting programmer time, compare the time it takes to implement a simple tree control in Swing compared to the time it takes to implement something similar in Windows Forms. That's FORMS, not API.

This is a compounded advantage compared to Swing with the current state of JITC. When JITC is as good as C compilers, Swing will be faster than native widgets because of the ability to inline function calls of the API.

Yeah, Java code will get faster as the Java JITC gets better, but so will .NET code as the .NET just-in-time compilation improves. I've heard (but can't substantiate at this moment in time) that when you install the .NET framework, the code is actually compiled from MSIL to native code (as in, native code not bytecodes that are then JITC at runtime) to a certain degree. How can Java possibly compete with this? Of course, this may very well be a 'windows-only' thing.

But faster than native widgets? I very, very much doubt it - but we'll see.

On the general speed of Java verses CLI, I only admit my findings as some evidence since there is no real good evidence. Sure my evidence is flawed, but I stated it out right so as to not decieve anyone. I didn't make an unsupported claim like you did.

You're right, my bad. My claim was unsupported. However I do know that on my system, it takes an eternity for simple things like a Swing JFileDialog to appear.

I didn't intend to mislead or deceive anyone. It was a mistake, I admitted it in a previous post, I'm admitting it now.

I don't care about ISO/ANSI/ECMA standards because by and large they mean less than I've seen from Java. There are few, if any, C++ compilers that are up to spec. Even if they were, the standard class library is too little to be usefull. There are standard text based IO streams, but you have to use some third party library for anything else you need or write your own. The end cost for developing C/C++ programs is much greater than Java because of this. These third party libraries can't really be taught in school because there are usually 3-8 different competing libraries that are all considered on equal footing in the marketplace.

There's a lot that isn't taught in schools.

Comparing Java to C/C++ is a waste of time. Yes, Java is easier to program with. No, it can't do everything. Live with it. As for cost, it really depends on the sort of application.

Boost adds a lot of functionality to the standard C++ library - not nearly as much functionality as the Java runtime, but then it's not quite so high level either. As I said, you're barking up the wrong tree.

What language do you think is used for low level native Java methods?

Java changes quicker than C/C++ because it's not an ECMA standard.

I don't know about you, but Java changing a lot says to me that it has a lot of problems.

Ah the futilities of arguments between us techie types :)

I am curious about this... I have used Java and C++ fairly extensively and I find C++ really isn't that hard to debug. Garbage collection in Java is certainly nice but with a decent implementation of smart pointers and using the STL, I don't have memory leaks and runaway pointers. Where do you find you spend/spent most of your time debugging C++ applications?

I have been using Qt for the last 1.5 years to develop an application for post-processing of segmented (medical) image data as part of my master thesis. The application is available under the GPL at sourceforge

During development one major disadvantage of Qt has surfaced, and I think it shows that the Trolltech has choosen a terribly wrong solution to a complex problem.

In order to support their signals-and-slots mechanism (which is an elegant concept, and allows for easy implementation of both the model-observer pattern and the mediator pattern) they have added two new keywords to the language, namely signals and slots. In order to support these you _HAVE_ to run a preprocessor called moc (Meta Object Compiler) for your program to link. But moc does not support templates.

Mostly we have managed to work around this limitation by having a non-template superclass which declares the signals and slots (luckily slots can be virtual) and then have the template parts in a subclass, but this leads to unnatural class hierarchies.

Other libraries have managed to support a signals-and-slots mechanism without such an ugly hack. Both Boost.signals and libsic++ implement them. However their syntax is not as nice as Qt's. If C++ really need even more syntax is of course another question :-)

While not all applications rely upon templates, they have some interesting uses, and if an applications first starts to use them, most classes easily ends up as template classes. See the book Modern C++ Design for "new-school" uses of templates. This could easily be the direction C++ development is headed, and it's a shame Qt will not be able to be a part of it.

There has been talk of doing some higher level things such as networking, graphics and user interfaces, but nobody can come up with specifications that are simple enough, or that are easily ported between platforms.

Coolest new bit is the Spirit parser generator. Who needs seperate lex+yacc files, embed that BNF in the C++ :)

Boost.Python might be what you're looking for.

True, if you know a priori that you are dealing with character data, your file metadata are highly stable, and the recursive nature of a file hierarchy is the scariest piece, one would suppose that a customized file system database engine might not be too huge.
But I speak well above my skill level, having just written my first little bit using a RegEx. Go, boost.
Maybe keeping an eye on Hans is a good idea.

• Metaclasses (meaning classes whos instances are in turn classes) are, naturally, templates.
• Higher order functions can be implemented using templates (see boost::function.
• Macroses are external to the language, use cpp at will.

As for the rest, it would be nice, but we can continue surviving without these until 1.6 or so ;-)

Doing mainly C++ development I've learned to love the STL and most recently the Boost libraries and I've long regretted that Java didn't support templates. It always confused me that with as much emphasis was placed on strong typing in Java that there was so much need for casting.

Although I'm glad to see the introduction of templates, I'm also concerned about how some of the problems I've encountered with C++ templates will be avoided. The biggest problem I've encountered has been the lack of interface checking.

For example the templated function for_each(begin, end, function) iterates from 'begin' to 'end' calling 'function' on each item inbetween. However there is no mechanism to specify that the type of passed to 'begin' and 'end' must have an equality operator and an operator* and 'function' must take one parameter of the type returned by *begin. This can cause very strange compiler errors when a user tries to pass a variable that doesn't support the proper operations to be compatible with the function. These errors actually appear to occur within the templated code, not the user-written code and can make determining the cause of these errors very difficult.

The Boost Concept Check library provides a way for programmers writing templated C++ code to enforce the interface requirements on the templated parameters in a way that gives more informative error messages. However this is rarely used, even in the Boost libraries. The documentation on the Boost Concept Check gives a good example of the kind of errors that C++ programmers dread.

In order for Java templates to be successful they will need to provide some manner of enforcing requirements on the interface necessary for the templated code to work and provide useful errors at compile time if it doesn't.

Doing mainly C++ development I've learned to love the STL and most recently the Boost libraries and I've long regretted that Java didn't support templates. It always confused me that with as much emphasis was placed on strong typing in Java that there was so much need for casting.

Although I'm glad to see the introduction of templates, I'm also concerned about how some of the problems I've encountered with C++ templates will be avoided. The biggest problem I've encountered has been the lack of interface checking.

For example the templated function for_each(begin, end, function) iterates from 'begin' to 'end' calling 'function' on each item inbetween. However there is no mechanism to specify that the type of passed to 'begin' and 'end' must have an equality operator and an operator* and 'function' must take one parameter of the type returned by *begin. This can cause very strange compiler errors when a user tries to pass a variable that doesn't support the proper operations to be compatible with the function. These errors actually appear to occur within the templated code, not the user-written code and can make determining the cause of these errors very difficult.

The Boost Concept Check library provides a way for programmers writing templated C++ code to enforce the interface requirements on the templated parameters in a way that gives more informative error messages. However this is rarely used, even in the Boost libraries. The documentation on the Boost Concept Check gives a good example of the kind of errors that C++ programmers dread.

In order for Java templates to be successful they will need to provide some manner of enforcing requirements on the interface necessary for the templated code to work and provide useful errors at compile time if it doesn't.

Doing mainly C++ development I've learned to love the STL and most recently the Boost libraries and I've long regretted that Java didn't support templates. It always confused me that with as much emphasis was placed on strong typing in Java that there was so much need for casting.

Although I'm glad to see the introduction of templates, I'm also concerned about how some of the problems I've encountered with C++ templates will be avoided. The biggest problem I've encountered has been the lack of interface checking.

For example the templated function for_each(begin, end, function) iterates from 'begin' to 'end' calling 'function' on each item inbetween. However there is no mechanism to specify that the type of passed to 'begin' and 'end' must have an equality operator and an operator* and 'function' must take one parameter of the type returned by *begin. This can cause very strange compiler errors when a user tries to pass a variable that doesn't support the proper operations to be compatible with the function. These errors actually appear to occur within the templated code, not the user-written code and can make determining the cause of these errors very difficult.

The Boost Concept Check library provides a way for programmers writing templated C++ code to enforce the interface requirements on the templated parameters in a way that gives more informative error messages. However this is rarely used, even in the Boost libraries. The documentation on the Boost Concept Check gives a good example of the kind of errors that C++ programmers dread.

In order for Java templates to be successful they will need to provide some manner of enforcing requirements on the interface necessary for the templated code to work and provide useful errors at compile time if it doesn't.

ttfkam wrote:
Do it in a higher-level language first. Make sure your algorithms are clean and efficient. If and only if you see a performance or resource problem do you rework portions(!!!) in C. As a bonus, the higher level language acts as a code template for faster C development.

Amen.

Kragg wrote (in his reply to ttfkam):
Prototyping in a higher-level language (c# is easy, java everyone knows) is a superb idea, provided you
- can release the final product as interpreted, with slow execution speed

Most programs spend 90% of their CPU time executing 10% of their code. If that 10% is optimized in a low-level language such as C, a large-scale interpreted program can boast performance that's virtually indistinguishable from an equivalent program written entirely in a low-level langauge. However, there's likely to be a huge difference in programmer productivity.

As a reference, see this Dr. Dobbs article, which states:
""" ... 90 percent of the software's running time occurs in only 10 percent of the code. This is the whole basis for virtual memory: Potentially, a program can run at full speed with only 10 percent of itself--or whatever the working set is--loaded into memory at any given time. Unlike that nasty segment stuff, the programmer does not specify any of this in advance. The operating system "discovers" a program's working set on-the-fly, through page faults.
"""

- can afford the time to port all to C, in which case DO, this is an excellent way to make a watertight C program

Why port 90% of the application's code to a low-level and less productive programming language, when that 90% will inevitably evolve and require maintenance as the program is utilized in unforeseen ways? I've never written a large program that didn't end up having features added incrementally over a long period of time after the initial release.

- are happy to learn how to make managed code/vm code call to native and vice-versa (this is far from a trivial problem)

If it's "far from a trivial problem", you're using the wrong tool.

Take Python, for example: it's simple to interface between Python and C using Python's C API. Recently, a tool named Pyrex has appeared that makes it almost trivial. Pyrex is amazing.

Kragg suggested prototyping in C# or Java, but Python surpasses both of those as a prototyping tool. Python is higher-level than C# or Java (and thus better suited to prototyping and/or malleable fusion with C) because it features:
- dynamic typing ("dynamic", not "weak" like Perl)
- no obession with a particular programming paradigm; use procedural, functional, or OO as appropriate
- high-level data structures built into the language
- more convenient dynamic code loading
- interactive development at a "Python prompt" (the value of this cannot be overestimated)
- no separate compilation step in the edit-test-debug cycle
- more concise syntax
- excellent interface capabilities to C (or C++ via Boost.Python, or Java via Jython)

I suggest that the fusion of a truly high-level (higher than Java-level) language with C is far more broadly applicable than Kragg claims.

Boost is a very professional set of c++ libraries meant to extends the standard library. It contains a modified version of the Jam build system that works very well as a cross-platform Makefile alternative. Check it out

Hello? If you use C++ and don't know about Boost, you've been living in a cave. Come on out and see, it's really cool. Also check out Modern C++ Design by Alexandrescu.

There are a great variety of cross-platform libraries and frameworks that you would find useful. For example, for a humble JPEG coded, the Independent JPEG Group's JPEG library works really well and runs on everything from DOS to a Cray. It is portable beyond belief. For a lossless graphics format there is libtiff. (I don't know what's available for cross-platform video format software, but I'm sure there is some.)

If you're going to write in in C++, my favorite framework for GUI, file API's, TCP networking, multithreading and database is ZooLib. (But note that presently the best code to use is what's in CVS because it hasn't had a release in a long time (Real Soon Now, really!).

I've started writing a book about ZooLib that is released under the GNU Free Documentation License.

But if you don't like ZooLib, it's important to use some cross-platform framework. There are many to choose from.

Another important framework is the Simple DirectMedia Layer. You will want this for your rendered scenes and for sound (ZooLib does 2-D graphics, it's not a 3-D API).

If you write in C++, do as much as you can with the Standard Template Library. There are some excellent books that teach how to use it.

For a long time, the STL has got a bad rap, in part because the template definitions in the header files are hard to read, and in part because of poor compiler implementations of the C++ ISO standard, or poor implementations of the library itself. But by now there are excellent implementations for every OS that is in common use. For example, on Windows, don't bother with Visual C++ - use Metrowerks CodeWarrior or Comeau C/C++.

Even if you choose to work with a broken compiler, the STLPort library provides a compliant standard library that will work almost anywhere.

I was rather intimidated by the STL when I first encountered it but once I got a good book and learned how to use it, I thought it was the best thing since sliced bread.

Boost has many portable C++ libraries that are of excellent quality.

Finally, I am (slowly) building a website devoted to educating developers in cross-platform and portable programming called ByteSwap.net. Read my first article there Writing Cross-Platform Software - Getting Started. More articles will appear when I get more free time!

Well, I don't like my exceptions that strict, and I'm not keen on the single object hierachy either :) That's pure opinion, so I won't try to start an argument..

Similarly for garbage collection, although I should point out that there's nothing stopping you from doing garbage collection (Boost's shared_ptr is a commonly used implementation) within your own stuff. If you want a dynamically allocated (ie with new) object to be automatically deleted when it's scope vanishes, std::auto_ptr should take care of it.

The std::map container will let you index on strings (or any other kind of object, for that matter) and look up with myData["key"].

I think that a smaller standard library, with distinct functionalities farmer out to third party libraries, is a good thing. Although, as you've pointed out, many projects have insisted on inventing their own strings, instead of using the standard ones. This is a huge problem, but I get the feeling it's slowly going away.

Property helpers are a big plus, I'll grant you that :P

I would claim that _destructors_ are the single biggest advantage C++ has over Java, C#, perl, python and the rest
Absolutely. A function (destructor) that is guaranteed to be called at some point after another function (constructor) has been called, even if an exception is thrown in between, is incredibly useful. While there are a number of powerful resource managment techniques in c++ (see for example the smart pointer classes over at boost, for me the approach of 'Resource Aquisition Is Initialisation' has proven to be very effective in avoiding headaches with with memory leaks (or database handle leaks, or file handle leaks, or ....)

Though its not obvious how to do it, it is possible to make some assertions work at compile time in C++.

For a good example of this check out the boost library and look for static_assert.