boost::crc

If you actually want to maintain your sanity and avoid boost, check out this page. There are lots of different tutorials.

Quote:Original post by circlesoft
If you actually want to maintain your sanity and avoid boost, check out this page. There are lots of different tutorials.

Teh infid3l!!11

Boost owns. Anyone that says otherwise gets banned [grin]
(Ok, not really, but you get the idea)

Quote:Original post by Coder
Boost owns. Anyone that says otherwise gets banned [grin]
(Ok, not really, but you get the idea)

Hooray for making a library as complex and unreadable as possible! Okay, I won't hate boost for it's functionality, because it actually has that. I hate it for other reasons (many of these are the same reasons behind my hatred of STL):

(1) Old-school coding style - I can't stand to read stuff in lowercase, only separated by underscores ('_'). boost::this_is_unreadable(). Why is a lot of open-source stuff like this? I HAVE NO CLUE - I guess unreadable == guru. This applies to STL as well.

(2) Poor documentation. Even though the Boost documentation is extensive, it is not organized or standardized. Each object type has a different format that you have to naviagate through. For a lot of objects, there isn't even a function or member list. I mean, come on, this is what you go to the docs for. I prefer the MSDN-style docs, where search for the class, and the member list comes up right away. That's what I'm after 95% of the time.

Hell, at least Boost *has* documentation. Much better than STL [lol]

(3) Compile time. Unfortunately, Boost actually has snuck its way into my latest project (I'm using luabind, which requires boost - no, I don't actually use it in my code). The second I included the boost headers, compilation time went through the roof. So I busted out the precompiled header, and that fixed it. But still - I would have thought PCHs are too newfangled for those Boost wizards writing on Linux.

STL, to its credit, doesn't seem to have this problem.

Ok, that's enough for now. Now ban meh! [smile]

Quote:Original post by circlesoft
(1) Old-school coding style - I can't stand to read stuff in lowercase, only separated by underscores ('_'). boost::this_is_unreadable(). Why is a lot of open-source stuff like this? I HAVE NO CLUE - I guess unreadable == guru. This applies to STL as well.

That's a coding standard like any other. I personally find camelCase unreadable. YMMV. The reason why Boost uses it is precisely because the C++ standard library uses it, and Boost is intended to complement it.

Quote:I mean, come on, this is what you go to the docs for. I prefer the MSDN-style docs, where search for the class, and the member list comes up right away. That's what I'm after 95% of the time.

Nobody likes to write documentation.

Quote:Hell, at least Boost *has* documentation. Much better than STL [lol]

MSDN does document the standard C++ library. So does Dinkumware. There also are several books on the topic. What more do you want? The C++ standard library is part of C++, so it's up to platform providers to document it.

Quote:The second I included the boost headers, compilation time went through the roof.

Boost code is very complex. That's the price for its power and ease-of-use. I guess from this comment that you've not been on any large-scale project (then again, neither have I), where rebuilding the program is a significant task.

Quote:So I busted out the precompiled header, and that fixed it. But still - I would have thought PCHs are too newfangled for those Boost wizards writing on Linux.

Not all compilers support precompiled headers. I think GCC recently started to support them.

Quote:Original post by Fruny

Quote:Original post by circlesoft
(1) Old-school coding style - I can't stand to read stuff in lowercase, only separated by underscores ('_'). boost::this_is_unreadable(). Why is a lot of open-source stuff like this? I HAVE NO CLUE - I guess unreadable == guru. This applies to STL as well.

That's a coding standard like any other. I personally find camelCase unreadable. YMMV. The reason why Boost uses it is precisely because the C++ standard library uses it, and Boost is intended to complement it.

Seconded. this_is_much_more_readable_than_this: ThisIsMuchLessReadableToMe.
Basically, the underscores act as spaces to me and I read identifiers in no time. When I write C++ code, that's the convention I use. [smile]

Quote:

Quote:I mean, come on, this is what you go to the docs for. I prefer the MSDN-style docs, where search for the class, and the member list comes up right away. That's what I'm after 95% of the time.

Nobody likes to write documentation.

And the boost documentation isn't that bad, it's good enough IMO. You can always figure out what you need, and when you do that, why don't you write some better documentation yourself? [grin]

Quote:

Quote:Hell, at least Boost *has* documentation. Much better than STL [lol]

MSDN does document the standard C++ library. So does Dinkumware. There also are several books on the topic. What more do you want? The C++ standard library is part of C++, so it's up to platform providers to document it.

And even better than those (ok, in some respects), there's the SGI STL documentation.

Quote:Original post by Fruny
That's a coding standard like any other. I personally find camelCase unreadable. YMMV. The reason why Boost uses it is precisely because the C++ standard library uses it, and Boost is intended to complement it.

Fair enough. Coding standards are highly based on personal opinion. I suppose the most important thing is that they are uniform throughout the codebase of an application. In my case, I have grown accustomed to camel-case, as all companies I have worked for use it.

Quote:Nobody likes to write documentation.

True, but a library is only as good as its documentation. As a developer, I have always prefered Doxygen, since it makes it very easy to lay the framework for complex, yet organized, documentation. I don't really have a problem at all with writing docs as I go.

Quote:MSDN does document the standard C++ library. So does Dinkumware. There also are several books on the topic. What more do you want? The C++ standard library is part of C++, so it's up to platform providers to document it.

Perhaps I will use the Dinkumware docs from now on, they actually look half-decent. The MSDN docs are pretty sparse. Coder pointed me to another good outside doc site before, but I lost my bookmarks a little while ago.

What do I want? I want clear, organized, and fullfilling documentation. The DirectX docs are a great example. They offer very clear member lists for each interface, as well as helpful programming guides. I don't need docs in it with 30 billion code samples and tutorials: I just want a clear list of what members each interface offers (and a description of their functionality, if necessary). Those Dinkumware docs are decent at this - although I do prefer the Doxygen-style docs that I mentioned earlier.

Quote:Boost code is very complex. That's the price for its power and ease-of-use. I guess from this comment that you've not been on any large-scale project (then again, neither have I), where rebuilding the program is a significant task.

Correctimundo. Although like I mentioned, the PCHs fixed this problem quickly, so it is alright. However, on a platform that does not support them, it could be a pain in the butt (if you weren't working on a project that had 10 billion lines of source and took and hour to compile).

Quote:
Not all compilers support precompiled headers. I think GCC recently started to support them.

That's what I was implying.

Quote:Original post by Coder
Seconded. this_is_much_more_readable_than_this: ThisIsMuchLessReadableToMe.
Basically, the underscores act as spaces to me and I read identifiers in no time. When I write C++ code, that's the convention I use. [smile]

Dangit!!! 2 for ummm..."native-case" and 1 for camel-case. [crying]

Quote:
And the boost documentation isn't that bad, it's good enough IMO. You can always figure out what you need, and when you do that, why don't you write some better documentation yourself? [grin]

Why would I write docs for a library that I don't even like or use? Why don't YOU write some! [lol]

Quote:
And even better than those (ok, in some respects), there's the SGI STL documentation.

Aha! That's what I was lookin for.