OSNews

This may be of the no-help help variety, but one might consider trying the python bindings
http://www.osl.iu.edu/~dgregor/bgl-python/
Keep a python object list, and don't use BGL for more than the essential management of a graph of object ids.

I have also been frustrated when using the Boost Graph Library (BGL) as both the online documenation and the BGL book is very bad. Like you I find it very difficult to explore these data structures in order to construct the graph I want and manipulate it according to my needs. I also know many researchers that decided to not use BGL because of this and that is sad since it is a lost opportunity for research collaboration.

When it comes down to the cryptic error messages from erroneous template instantiations I believe that this is a problem which should be fixed by compilers or tools debugging template use. Some C++ frontends, like EDG, supports the creation of ASTs for erroneous codes and it would be interesting to see if analysing this AST could be a step towards sensible error messages.

I couldn't agree more. I usually follow this rule:

1. <T> - Stop, Think and Go
2. <T> in <T> - Go with Exterme Caution
3. <T> in <T> in <T> - Avoid like poison
4. <T> in <T> in <T> in <T> - motherf--king C++ whores...kill them assholes...

All this and some more C++ crap has completely turned me off of C++. It is becoming the next Perl with so much syntactical mess that it is really easy to write code which is a nightmare for others to maintain.

Before people ask what other syntactical crap, here are two things that i can think of right away:
1. Operator overloading - Wow now you don't know what exactly a + b does
2. multiple inheritance

Edited 2006-12-04 12:19

Operator overloading - Wow now you don't know what exactly a + b does

int rocknrollpewpew(int a, int b) {
return a * b;
}

int c = rocknrollpewpew(a,b);

Oh dear, the meaning of functions isn't immediately obvious. Functions are a load of syntactic crap, I suggest we remove them .

When you are debugging at least you know they are a function call.

How the hell do you know if + is a function call unless ofcourse you plan to make all operators overloaded?

Correct me if I'm wrong, but :

Standard C++ regulates, that the compiler can
only generate the copy constructor, the default constructor and the assignment operator, if they are not implemented. In any other case, including the operator+(), one has to implement the operator explicitly, like you would have to with functions.

If you have something a la

foo a;
bar b;

foobar c( a + b );

in your code, you have either to look for

foobar foo::operator+( bar const& rhs );

or

foobar operator+( foo const& lhs, bar const& rhs);

in your header files. Besides the inconvenience to look potentially for this two different notations, instead of one in case of a hypothetical plus() function, I can see little problems here.

Assuming one uses operator overloading only where it is justified (e.g. to translate arithmetic or gramatical operations like concatination into code), it is imho supperior to functions. I write numerical code for scientific applications, and at least I find

foobar d( a * b + c );

easier to read/maintain/understand than for example

foobar d( plus( prod( a , b ) , c );

Programmers, who abuse operator overloading should be treated with the proverbial clue bat, agreed. But operator overloading can, just like expression template metaprogramming, give you a very handy tool, that saves time and effort und is a joy to use.

Like every tool, it can be misused, though. but just because some developers choosed to obfuscuate the meaning of their programs by using operators, I don't see a reason to bash operator overloading.

Regards

EDIT: foobar c() -> foobar d() in the second and third example, sorry :-)

Edited 2006-12-04 19:55

Agreed. Any programming construct can be abused.

Operator overloading is one that can add clarity and elegance when used in the right context.

and no-one _forces_ you to use it when that context is not apparent.

Sure. However, abusing C++ language features is becoming ingrained practice in the C++ community. Books are being written about how to abuse C++ in particularly heinous ways, and C++ 0x is codifying these acts of violence into the standard.

@Rayiner
I take your point and somewhat agree. I was just making the point that this 'OPERATOR OVERLOADING IS EVIL PERIOD.' stuff that people sometimes spout is disingenuous.

Edited 2006-12-04 20:42

First i didn't mean to write debugger, i meant when i am reading the code.

Operator overloading makes it harder for other people to understand your code.

The example you gave above could simply be:

x = calcMultiply(a, b);
x = CalcSum(x, c);
d(x)

What is wrong here, it is more clear and when you are reading the code, you immediately know that multiply is not simply an arithmatic multiplication.

I like to write code which the programmer can understand when they are reading it. Ambiguity is something that i hate and C++ has many constructs that are ambiguous.

Well beauty is in the eye of the beholder. If I code a formula, I find it easier, if the formula in the code actually looks like the formula on the paper. Since the applications I write are mainly numerical, my background may have something to do with this, though.
But, as I have stated in my previous comment, operator overloading is esp. suitable for such situations, where operation is connected very closely to the operator in everyday life, not for every problem.

>What is wrong here, it is more clear and when you are
>reading the code, you immediately know that multiply
>is not simply an arithmatic multiplication.

Well, I assumend that it should become clear from the context of my post, that I intended to describe a situation where "+" is indeed an arithmetic operation or a grammatic operation, that is somehow logically connected to the operator. My FORTRAN programming colleages have little problems to understand

std::string a;
std::string b;

std::string c( a + b);

, but not everybody immediatly grasps, what is meant by

std::string c( returnConnectedString( a , b ) );

It boils down to find a meaningful name (and not all programmers speak English, or the language you choose to code in). If a symbol is easier to understand than a name, then I'm happy if a language allows me to use it.

Furthermore, I see no immediate problems with your code, but please consider, that there are situations, where your solution is probably not optimal, just one example:

If your code is performance critical, eliminating temporaries (x in your code) can increase the performance substantial. Expression TEmplates in combination with operator overloading allow to write code, that reads (for me) very simple and natural and completly avoids temporaries.


Regards

I disagree with the performance point you made, the temporary are always generated even if you do operator overloading using

a * b + c

x = foo()
foofoo(x)
will have exactly same performance as
foofoo(foo())
in an optimized build.

I agree to some extent that if the operator choice is done carefully, it ends up making more sense but this also has to do with documentation.

STL has some operator overloaded but it is done so carefully that they are never obtrusive or have hidden meaning.

STL avoid overloading operator when possible. As an example, many String templates namely MFC CString has an operator (LPCSTR) which convers the CString object automatically to C style string i.e. char*. BTW did you know you could overload typecasts using operator overloading?

But STL did not chose it and they instead have a function .c_str() and after using it, i think it was an intelligent choice.

If you look at the whole STL, it has very little operator overloading however where ever it uses overloading, it just makes sense.

Sadly good use of operator overloading is quite less in my experience as compared to its misuse hence my default stand is to never use it.

Ofcourse you will find exceptions like STL but because C++ gives such facilities which gets easily abused, i compared it to Perl and i rather stick to C because it does the job you want it to and it does what you read it does not what it is doing behind the ambiguous syntax.

Instead of overloading, c++ could have defined new syntax which would make sense and be clear to reader so they could use

a @* b @+ c or something similar and i wouldn't have complained because @* in this case will always be a function and is explicit but will still maintain the feel of arithmatic operation that you want.

The debugger should show the function 'operator+()' on the stack.

So what is the problem?

The aim of BGL is to be a graph manipulation tool so they define graph operations which can be used in performing analysis. Graphviz is a set of simple graph visualization tools and stores these graphs in the dot format, and although the scope of graphviz is limited it is excellent at what it does. BGL supports the dot format, but also supports more complex graphs plus an extensice set of graph operations so Graphviz can not be compared to BGL.

boost is good library, except it's documentation. Boost documentation sucks ass ! I wish Microsoft had made documentation for boost.

Boost is a good library, in general. However, Boost.Lambda, Boost.PPP, and BGL are real abuses of the template mechanism. Good code doesn't make the language do things it doesn't want to, and C++'s template mechanism is a way of specifying generic data structures and algorithms, not a general macro language.

As usual some f--k-ups are modding normal comments down, like I care

Yeah, don't you dare suggest that Microsoft can do something well :-)

Yeah, it's neither tutorial for programmers (explain classes, methods and how all this stuff connects together, examples included) nor article for non-programmers. It mostly says what CAN be done with graphs - nothing more. Programmers will usually already know what graph is and how to work with them - they'd just need good API documentation.

Edited 2006-12-04 11:35

Yes, of course, that's what BGL is trying to do. The complex template API isn't there for kicks, its there to allow code reuse. However, when a small mistake will get you pages of template expansions as an error message, then people aren't going to want to reuse that code.