Quote:I do apologize to RDragon, but i think it was awfully childish for him to say im "Avoiding Education" by not using boost. I was well aware that boost used the standards, and as i have said above, i have nothing against it.

Agreed, that was a bit over the line.

Now, the nice thing about Boost being written in C++ is, it's written in C++. That means that even if you Cannot Use Boost, you can still use bits and pieces of Boost simply through copying and pasting. Different boost components will give you varying levels of success at this: boost::signal, for instance, pulls in a LOT of other stuff, so that's not really feasible, whereas safe_deleter is, like, three lines of code.

boost::bind and boost::function, unfortunately, won't separate from the rest of Boost without a fight. Bits and pieces of boost::preprocessor will, but the file iteration stuff (which is how you'd want to solve this particular problem) involve hundreds of fiddly little files. So no help there either.

So that's the long version of saying "In this case, snipping off pieces of Boost won't help; but don't rule out using bits of it under other circumstances, even if you don't import it as a whole."

Quote:Original post by Antheus

Quote:we could not use it for the fact that we do not want to require our uses to use libraries that are not standard with every compiler, such as the GCC and MS Visual C++.

This is incorrect statement. At least look at supported compilers, boost will cover much more than that in a reliable, peer-tested and portable manner. Unless your team can afford to support several *dozen* compilers on dozen platforms, which boost does out-of-box.

I think you have misinterpreted. The reason why we cant/dont want to, is we want it to be plug-in-play, as in, no extra non-standard libraries that dont already exist with GCC or VC++. We want you to be able to open up the solution/project, and be able to build there and now.

Quote:Original post by GanonPhantom

Quote:Original post by Antheus

Quote:we could not use it for the fact that we do not want to require our uses to use libraries that are not standard with every compiler, such as the GCC and MS Visual C++.

This is incorrect statement. At least look at supported compilers, boost will cover much more than that in a reliable, peer-tested and portable manner. Unless your team can afford to support several *dozen* compilers on dozen platforms, which boost does out-of-box.

I think you have misinterpreted. The reason why we cant/dont want to, is we want it to be plug-in-play, as in, no extra libraries that dont already exist with GCC or VC++. We want you to be able to open up the solution/project, and be able to build there and now.

Edit: it moved my post down when i tried to edit it 0.o, mabe i accidently pressed the quote button on myself :P

I've run into this problem too, and I can feel your pain. Sadly, the most straight forward approach to handle this is straight up copy-paste-add a template argument. The Boost file iteration stuff works well for this (and iirc Luabind uses it) although it has the strange ability to really muck up readability and maintainability. You can easily argue that the copy-paste method causes just as many maintenance problems, since if you want to change something you now have to go through every iteration, although I do find it a bit easier to read through. There is no real 'clean' way to solve this problem yet in C++. Variadic templates can't come soon enough imo.

Well, good news is going to use boost now. But, with the advisory to make wrappers for the objects i want to use (not all, but most), incase my/their minds change, so its easyer to change.