Right now, the only library I use in my code is boost since I find it
professional and fulfills most of the criteria above. One may wonder
what library on earth is replaceable in an easy manner, but I added that
point since quite many of boost's features go straight into the C++0x
standard. Knowing that your library features in the future may be easy
replaceable with the C++ standard is comforting to know.

If there is any library that you would use in your code, boost would
probably be the most professional. (You can also check out Loki by
Alexandrescu)

Advertisements

On Jun 9, 6:08 pm, DeMarcus <> wrote:
> On 2010-06-07 21:25, Lynn McGuire wrote:
>
> > I was wondering how many people here use boost in their c++
> > implementations ?
>
> I'm very reluctant to use third party libraries in my code for various
> reasons like
>
> * licensing
> * quality (documentation, easy to use, clean, etc.)
> * future maintenance
> * portability
> * replaceability
>
> Right now, the only library I use in my code is boost since I find it
> professional and fulfills most of the criteria above. One may wonder
> what library on earth is replaceable in an easy manner, but I added that
> point since quite many of boost's features go straight into the C++0x
> standard. Knowing that your library features in the future may be easy
> replaceable with the C++ standard is comforting to know.
>
> If there is any library that you would use in your code, boost would
> probably be the most professional. (You can also check out Loki by
> Alexandrescu)

Once I worked at a shop where there were great reservations to
bringing Boost in. The two primary objections were:

1) Having a legacy system (20 years) we already have internal
alternatives to some of the Boost components we are thinking
of using such as hash containers, smart pointers, regex, etc.
Yes Boost is clearly more STL-like and newly hired programmers
might actually know some of them in advance, but:

a) if we start adding in the Boost alternatives we will
have a mixture and that will require learning two libraries
instead of one and possibly degrade maintenance.

b) our proprietary solutions have been thoroughly tested
under OUR conditions and are known to meet OUR requirements.
While Boost has been thoroughly tested by a large community
we have no way of knowing whether it has been extensively
tested under the conditions we are targeting.

2) Boost is large and diverse library. While there are many
components we like and certainly would use, there are some
components that we absolutely do not want used regularly in
our code. For example we don't want to see the few meta-
programming aficionados among us spreading MPL code throughout
"just because they can". While we do have a review process,
the mere existence of those libraries increases review burden
and makes it more likely components that are not widely
understood will be used in our code.

Ultimately the approach we chose was four-fold:

1) only a small, carefully selected and approved subset of
Boost would be installed and only a subset of components
would be approved for use.

2) for now, Boost is approved only for new code or refactoring
as part of implementing new code. In other words, no Boostifying
solely for the purpose of entering the 21st century of C++.
If it ain't broke don't "fix" it.

3) only the approved components were "marketed" to the
developers. Ie we avoiding even talking about the non-
approved components unless we were confident the people
listening would not try to submit them for review ;-)

4) anyone attempting to use non-approved components would
get a smack-down ;-)

The above worked well with the exception of 1) which turned out
to be a lot of manual work. In addition, the dependencies within
Boost itself forced us to install some components (especially
MPL components) that we did not want exposed for common use.

Advertisements

Keith H Duggar wrote:
> On Jun 9, 6:08 pm, DeMarcus <> wrote:
>> On 2010-06-07 21:25, Lynn McGuire wrote:
>>
>>> I was wondering how many people here use boost in their c++
>>> implementations ?
>> I'm very reluctant to use third party libraries in my code for various
>> reasons like
>>
>> * licensing
>> * quality (documentation, easy to use, clean, etc.)
>> * future maintenance
>> * portability
>> * replaceability
>>
>> Right now, the only library I use in my code is boost since I find it
>> professional and fulfills most of the criteria above. One may wonder
>> what library on earth is replaceable in an easy manner, but I added that
>> point since quite many of boost's features go straight into the C++0x
>> standard. Knowing that your library features in the future may be easy
>> replaceable with the C++ standard is comforting to know.
>>
>> If there is any library that you would use in your code, boost would
>> probably be the most professional. (You can also check out Loki by
>> Alexandrescu)
>
> Once I worked at a shop where there were great reservations to
> bringing Boost in. The two primary objections were:
>
> 1) Having a legacy system (20 years) we already have internal
> alternatives to some of the Boost components we are thinking
> of using such as hash containers, smart pointers, regex, etc.
> Yes Boost is clearly more STL-like and newly hired programmers
> might actually know some of them in advance, but:
>
> a) if we start adding in the Boost alternatives we will
> have a mixture and that will require learning two libraries
> instead of one and possibly degrade maintenance.
>

I agree that mixing makes mess.
> b) our proprietary solutions have been thoroughly tested
> under OUR conditions and are known to meet OUR requirements.
> While Boost has been thoroughly tested by a large community
> we have no way of knowing whether it has been extensively
> tested under the conditions we are targeting.
>

The problem, as I see it, is that one has to make a design decision when
starting a new project. The decision is; "how long will this application
live?". If one can put a budget allowing to rewrite the code from
scratch when the lifetime is out, new features and libraries can be
considered. However, it is /very/ hard to make such lifetime decision,
hence we have to rely on refactoring.

In that case I find boost a good option since if a new feature shows up
in the C++ standard it is likely to be similar to the boost version and
a refactoring may be less hard.
> 2) Boost is large and diverse library. While there are many
> components we like and certainly would use, there are some
> components that we absolutely do not want used regularly in
> our code. For example we don't want to see the few meta-
> programming aficionados among us spreading MPL code throughout
> "just because they can". While we do have a review process,
> the mere existence of those libraries increases review burden
> and makes it more likely components that are not widely
> understood will be used in our code.
>

This is also a good point and difficult decision. Shall one start to use
a new feature before it's been around for a couple of years so one knows
the pros and cons?

> Ultimately the approach we chose was four-fold:
>
> 1) only a small, carefully selected and approved subset of
> Boost would be installed and only a subset of components
> would be approved for use.
>
> 2) for now, Boost is approved only for new code or refactoring
> as part of implementing new code. In other words, no Boostifying
> solely for the purpose of entering the 21st century of C++.
> If it ain't broke don't "fix" it.
>
> 3) only the approved components were "marketed" to the
> developers. Ie we avoiding even talking about the non-
> approved components unless we were confident the people
> listening would not try to submit them for review ;-)
>
> 4) anyone attempting to use non-approved components would
> get a smack-down ;-)
>
> The above worked well with the exception of 1) which turned out
> to be a lot of manual work. In addition, the dependencies within
> Boost itself forced us to install some components (especially
> MPL components) that we did not want exposed for common use.
>
> KHD

All in all; it's tricky with all the design decisions. Right now I'm
facing the decision what GUI library to use! Which one shall I take?
Shall I wrap it? What lifespan shall I give the frontend? etc. etc.

On 6/10/2010 8:26 AM, DeMarcus wrote:
> [..] Right now I'm
> facing the decision what GUI library to use! Which one shall I take?
> Shall I wrap it? What lifespan shall I give the frontend? etc. etc.

<offtopic betterNG="comp.software-eng">
Not to barge in, but since you mentioned it, two boilerplate answers
spring to mind. First, do spend time separating UI from the rest of the
application. Your business logic has to be functional regardless what
UI drives it. Second, you probably need a wrapper of some kind. Just
like any other subsystem, UI needs to be tested, and the more you can
automate that, the better, and wrappers allow hooks to be installed and
without hooks automated testing is at the mercy of somebody else's tools
(which as we know can come and go, and they do come buggy, and
platform-specific, etc. etc.)
</offtopic>

Keith H Duggar wrote:
> On Jun 9, 6:08 pm, DeMarcus <> wrote:
>> On 2010-06-07 21:25, Lynn McGuire wrote:
>>
>>> I was wondering how many people here use boost in their c++
>>> implementations ?
>> I'm very reluctant to use third party libraries in my code for various
>> reasons like
>>
>> * licensing
>> * quality (documentation, easy to use, clean, etc.)
>> * future maintenance
>> * portability
>> * replaceability
>>
>> Right now, the only library I use in my code is boost since I find it
>> professional and fulfills most of the criteria above. One may wonder
>> what library on earth is replaceable in an easy manner, but I added that
>> point since quite many of boost's features go straight into the C++0x
>> standard. Knowing that your library features in the future may be easy
>> replaceable with the C++ standard is comforting to know.
>>
>> If there is any library that you would use in your code, boost would
>> probably be the most professional. (You can also check out Loki by
>> Alexandrescu)
>
> Once I worked at a shop where there were great reservations to
> bringing Boost in. The two primary objections were:
>
> 1) Having a legacy system (20 years) we already have internal
> alternatives to some of the Boost components we are thinking
> of using such as hash containers, smart pointers, regex, etc.
> Yes Boost is clearly more STL-like and newly hired programmers
> might actually know some of them in advance, but:
>
> a) if we start adding in the Boost alternatives we will
> have a mixture and that will require learning two libraries
> instead of one and possibly degrade maintenance.
>
> b) our proprietary solutions have been thoroughly tested
> under OUR conditions and are known to meet OUR requirements.
> While Boost has been thoroughly tested by a large community
> we have no way of knowing whether it has been extensively
> tested under the conditions we are targeting.

By making your proprietary code simply forward to the boost or std
equivalents, you get your existing test coverage plus that of boost and
your standard library vendor. You can then migrate to boost/std as you
touch areas of code using them.

On Wed, 2010-06-09, DeMarcus wrote:
> On 2010-06-07 21:25, Lynn McGuire wrote:
>> I was wondering how many people here use boost in their c++
>> implementations ?
>>
>
> I'm very reluctant to use third party libraries in my code for various
> reasons like
>
> * licensing
> * quality (documentation, easy to use, clean, etc.)
> * future maintenance
> * portability
> * replaceability
>
> Right now, the only library I use in my code is boost since I find it
> professional and fulfills most of the criteria above.

In a way I can understand that. But:

Something people often forget when talking "libraries": special-purpose
libraries. For example, I target Unix exclusively. If I need support
for handling PNG images or ZLIB compression, I'll do what everyone
else does and use libpng and zlib, respecively.

Although these are definitely third-party, noone in his sane mind
would say "to hell with those, I'll use my own implementation, which
will be ready in a few years".
> One may wonder
> what library on earth is replaceable in an easy manner, but I added that
> point since quite many of boost's features go straight into the C++0x
> standard. Knowing that your library features in the future may be easy
> replaceable with the C++ standard is comforting to know.

[...]
>> One may wonder
>> what library on earth is replaceable in an easy manner, but I added that
>> point since quite many of boost's features go straight into the C++0x
>> standard. Knowing that your library features in the future may be easy
>> replaceable with the C++ standard is comforting to know.
>
> So you added a criterion because you knew only Boost met it?
>
> /Jorgen
>

No, and yes in a way. I'm very reluctant to use proprietary code, no
matter how good it is, if I can't replace it in an easy manner. Boost is
free /and/ replaceable with new features in C++0x.

The best solution, with for instance GUI libraries, would be to have the
interface non-proprietary and free. Then I would have no problem paying
for implementations of that interface as long as I can just switch a
file when I want to change the implementation.

Therefore, open standardized interfaces and implementation
replaceability is the way to go for proprietary libraries in the future!

On Jun 13, 10:45 am, DeMarcus <> wrote:
> >> I'm very reluctant to use third party libraries in my code for various
> >> reasons like
>
> >> * licensing
> >> * quality (documentation, easy to use, clean, etc.)
> >> * future maintenance
> >> * portability
> >> * replaceability
>
> [...]
>
> >> One may wonder
> >> what library on earth is replaceable in an easy manner, but I added that
> >> point since quite many of boost's features go straight into the C++0x
> >> standard. Knowing that your library features in the future may be easy
> >> replaceable with the C++ standard is comforting to know.
>
> > So you added a criterion because you knew only Boost met it?
>
> > /Jorgen
>
> No, and yes in a way. I'm very reluctant to use proprietary code, no
> matter how good it is, if I can't replace it in an easy manner.

Many companies are losing control of their operations --
BP is a good example. Three months ago BP wouldn't have
blinked an eye at spending millions to compensate for
choosing a low-quality approach that appeared to give them
more control. Now that their future is in jeopardy,
perhaps their decision-making process will improve.

On Jun 14, 2:53 am, Brian <> wrote:
> On Jun 13, 10:45 am, DeMarcus <> wrote:
>
> > >> One may wonder
> > >> what library on earth is replaceable in an easy manner, but I added that
> > >> point since quite many of boost's features go straight into the C++0x
> > >> standard. Knowing that your library features in the future may be easy
> > >> replaceable with the C++ standard is comforting to know.
> > > So you added a criterion because you knew only Boost met it?
> > No, and yes in a way. I'm very reluctant to use proprietary code, no
> > matter how good it is, if I can't replace it in an easy manner.
>
> Many companies are losing control of their operations --
> BP is a good example. Three months ago BP wouldn't have
> blinked an eye at spending millions to compensate for
> choosing a low-quality approach that appeared to give them
> more control. Now that their future is in jeopardy,
> perhaps their decision-making process will improve.

What is BP? British Petroleum? What it has to do with boost (or other
libs) usage when developing software?

On Jun 14, 5:18 pm, Öö Tiib <> wrote:
> On Jun 14, 2:53 am, Brian <> wrote:
>
>
> > Many companies are losing control of their operations --
> > BP is a good example. Three months ago BP wouldn't have
> > blinked an eye at spending millions to compensate for
> > choosing a low-quality approach that appeared to give them
> > more control. Now that their future is in jeopardy,
> > perhaps their decision-making process will improve.
>
> What is BP? British Petroleum?

Two letter acronyms are good signal of closing downfall. People want
to get done with that nonsense quick even when naming it. When there
is "General Motors" it makes sense. When there is "GM", it is nonsense
that no one cares about and it will be soon flushed by history. So ...
if you care, use terms that make sense (like "Best Practice") and do
not tell about soon-to-be-ruins (like that "BP").

On Jun 15, 7:33 am, Öö Tiib <> wrote:
> Two letter acronyms are good signal of closing downfall. People want
> to get done with that nonsense quick even when naming it. When there
> is "General Motors" it makes sense. When there is "GM", it is nonsense
> that no one cares about and it will be soon flushed by history. So ...
> if you care, use terms that make sense (like "Best Practice") and do
> not tell about soon-to-be-ruins (like that "BP").

What about (pre-Carly) HP? They were known simply as HP for years,
and were considered THE BEST equipment until Carly decided she'd
rather
get rich selling ink.

On Jun 15, 9:33 am, Öö Tiib <> wrote:
> On Jun 15, 4:04 pm, "Eric J. Holtman" <> wrote:
>
> > Brian Wood <> wrote in news:275eceac-42c1-4eb0-8847-
> > :
>
> > >> What is BP? British Petroleum?
>
> > > Yes, British Petroleum.
>
> > BP hasn't been British Petroleum for sme time.
>
> > It's just "BP".
>
> Two letter acronyms are good signal of closing downfall. People want
> to get done with that nonsense quick even when naming it. When there
> is "General Motors" it makes sense. When there is "GM", it is nonsense
> that no one cares about and it will be soon flushed by history.

I'm not sure if I agree or disagree with this. I hope it isn't
true as all of the US states have two letter abbreviations.
I live in Minnesota but don't like using the MN abbreviation.
I write Minn. or the whole name.
> So ...
> if you care, use terms that make sense (like "Best Practice") and do
> not tell about soon-to-be-ruins (like that "BP").

There's a lot to learn or remember from BP's mistakes so disagree
with that. I'm reminded of the "be careful what you wish for"
saying. I bet a lot of people wished they could get a job with
BP. Now those that did are collectively responsible for the
destruction of a big chunk of the world. The only responsible
action at this point may be to liquidate the company. Kind of
ironic that an oil company has to liquidate itself in order to
do the right thing.

On Jun 15, 6:36 pm, red floyd <> wrote:
> On Jun 15, 7:33 am, Öö Tiib <> wrote:
>
> > Two letter acronyms are good signal of closing downfall. People want
> > to get done with that nonsense quick even when naming it. When there
> > is "General Motors" it makes sense. When there is "GM", it is nonsense
> > that no one cares about and it will be soon flushed by history. So ...
> > if you care, use terms that make sense (like "Best Practice") and do
> > not tell about soon-to-be-ruins (like that "BP").
>
> What about (pre-Carly) HP? They were known simply as HP for years,
> and were considered THE BEST equipment until Carly decided she'd
> rather
> get rich selling ink.

Yes Hewlett-Packard used HP brand from start i think. Some people
manage to make a strong brand even from a ugly abbreviation. The
markets they initially targeted were science, economics and business
that do not care about aesthetics as much as efficiency and they were
good at it.

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!