3 ms·

> it is very easy to screw it up No, it's not. This just a made-up argument. > ... many more lines of code 6 in #define, one of which is blank. Your option h

> it is very easy to screw it up No, it's not. This just a made-up argument. > ... many more lines of code 6 in #define, one of which is blank. Your option however creates an external dependency on the library that somehow needs to be built even though it is supposed to be just a collection of headers. > ... and use of the preprocessor which makes searching through code very difficult Ok, considering your Edit, let's skip this one. > I can easily find all the noncopyable classes by searching for "noncopyable". Similarly, you can find all noncopyable classes by searching for "__no_copying". Besides, why on Earth you would ever need to do that in real life? > I don't have to worry about someone coming along and screwing up the access modifier at a later date. Ah, right. Here we start to really diverge. You are writing code that needs to be protected against incompetent colleagues, and I typically don't. > It is much less likely that someone will misunderstand what the code is trying to do No, of course it is not. This is too a made-up argument. PS. I hate Boost with passion, because it drags C++ in the exact opposite direction from how I am, personally, using it, which is C with classes, uncomplicated inheritance and basic templating. This is beautiful and functional subset of C++ that retains the clarity of C and adds flexibility and convenience that latter is missing. Boost has its place, clearly, but I don't understand programmers who willingly use it, just as I don't understand those who like Bjork.

DerKommissar 14y ago
I have seen this screwed up time and time again. People who don't know how all this works shouldn't be writing C++, but they do and I have to deal with the things they break. Most of my code isn't broken by incompetent colleagues, it's incompetent clients that use the code. Maybe the experience is different when you're writing commercial libraries which is what I've been doing for the past few years. I guess you and I have had vastly different experiences. boost has improved my code immeasurably. I cannot stand the "C with classes" approach. All the code I've come across the uses that approach is always broken in subtle ways the could be avoided by using the simple utilities in boost. I think in the end it is probably just personal preference. I'll agree with you about Bjork. But I am a serious musician and the best musician I have every been in the presence of loved Bjork.

DerKommissar 14y ago

I have seen this screwed up time and time again. People who don't know how all this works shouldn't be writing C++, but they do and I have to deal with the things they break. Most of my code isn't broken by incompetent colleagues, it's incompetent clients that use the code. Maybe the experience is different when you're writing commercial libraries which is what I've been doing for the past few years. I guess you and I have had vastly different experiences. boost has improved my code immeasurably. I cannot stand the "C with classes" approach. All the code I've come across the uses that approach is always broken in subtle ways the could be avoided by using the simple utilities in boost. I think in the end it is probably just personal preference. I'll agree with you about Bjork. But I am a serious musician and the best musician I have every been in the presence of loved Bjork.