BDE FAQ¶
This TEAM page attempts to answer frequently asked questions:
Q: What header do I include for bsl::some_stl_type (like bsl::vector, bsl::ostring, bsl::min)?
Q: Which shared pointer should I use: bsl::shared_ptr or bcema_SharedPtr?
Q: Which should I use std::auto_ptr, bslma::ManagedPtr, or bdema_ManagedPtr?
Q: I see a “bdet_datetime.h: WARNING: unexpected value …” in my console log, what do I do?
Q: How do I links against a DEBUG or DEBUG-SAFE build of BDE?
Q: How do I see the contents of my STL containers in my debugger?
Q: What header do I include for bsl::some_stl_type (like bsl::vector, bsl::ostring, bsl::min)?
A: The C++ standard library in BSL provides a set of headers that parallel those found in the C++ standard. For example:
Type |
Standard Header |
BSL Header |
---|---|---|
|
<algorithm> |
<bsl_algorithm.h> |
|
<ostream> |
<bsl_ostream.h> |
|
<vector> |
<bsl_vector.h> |
Q: Should I use bsl::some_stl_type or std::some_stl_type?
A: For historical reasons BDE provides a series of headers that match those
defined in the C++ standard (like <vector>), and provides a mechanism by which
std::vector
is an alias for bsl::vector
. Much of the code developed at
Bloomberg is built in this fashion (the mechanism by which this is achieved is
referred to as “BSL_OVERRIDES_STD mode”)
We recommend though that clients explicitly refer to the types in BSL (like
bsl::vector
) and include the BSL headers (like <bsl_vector.h>).
Why is that our recommendation? It is preferable to explicitly refer to the types you are using, and in many cases code may be making using of non-standard extensions provided by the BSL standard library types (like allocators).
Q: How do I include bslstl::StringRef?
A: #include <bsl_string.h>
This is obviously confusing. Sorry. If we had it to do over, we’d do something different.
The explanation is that we disallow directly including all types in the bslstl
package because of the BSL_OVERRIDES_STD mechanism. In retrospect, we should
have located the bslstl::StringRef
in a higher level package. In the
future, if we remove the BSL_OVERRIDES_STD mechanism, this small corner of
nonsense will go away.
Q: Which shared pointer should I use: bsl::shared_ptr or bcema_SharedPtr?
A: Use bsl::shared_ptr
.
There is information on the migrating from bcema_SharedPtr
here: smart
pointer migration information,
as well as background information here: Important changes to BDE smart
pointers.
Q: Which should I use std::auto_ptr, bslma::ManagedPtr, or bdema_ManagedPtr?
A: Use: bslma::ManagedPtr
.
There is information on the migrating from bdema_ManagedPtr here: smart pointer migration information, as well as background information here: Important changes to BDE smart pointers.
We don’t recommend using std::auto_ptr
, and do not use it within BDE except
where mandated by an external standard or library. Note that std::auto_ptr
is deprecated in C++11 and has been removed from the C++17 standard.
Q: What is BSL_OVERRIDES_STD?
A: BSL_OVERRIDES_STD is a compile time flag that can be supplied to code
built against the BSL library (i.e., -DBSL_OVERRIDES_STD) that enables code
written to use standard library types in the std::
namespace to use the
standard library types defined in the BSL library in the bsl::
namespace.
Warning
Use of this compile flag is deprecated.
Q: Why does BSL_OVERRIDES_STD mode exist?
A: History. At one point all of Bloomberg used a STLPort
standard
library implementation across all of our supported platforms, which was
modified to support allocators. Allocators were important, particularly for
use with shared memory in the Big, at a time when almost all Bloomberg software
was developed in the Big. The modified STLPort
library was difficult to
maintain and improve, so we moved to the current BSL library, which implements
only those parts of the C++ standard library important to Bloomberg (the parts
using allocators). In order to migrate the large existing code base relying on
the STLPort, BSL_OVERRIDES_STD mode was created.
BSL_OVERRIDES_STD is, unfortunately, complicated because of how various compilers deal with include files (a special thank you to Sun for not allowing a standard header files to be included multiple times!)
Some day, in the future, when C++11 is available on all our platforms, we may be able to move away from our own standard library implementation entirely.
Q: I see a “bdet_datetime.h: WARNING: unexpected value …” in my console log, what do I do?
A: Don’t panic! This warning does not indicate a problem with your task, or have any impact on behavior.
We have introduced that warning to identify if, and how, clients are using
bdet_Datetime
values having a set bdet_Date
(i.e., the date is not
0001-01-01), but an unset bdet_Time
(i.e., 24:00:00) for example,
01JAN1970_24:00:00
.
Note: This warning has been removed from BDE. Rebuilding your task (or potentially the libraries your task builds against) should be sufficient to remove the warning
If you wish to find out where in your code the warning is being triggered, set a breakpoint in a debugger at bdet_datetime.cpp line 40: this is where the “logMessage()” call is handled if a suspicious date is detected, so your code location should be 2 or 3 levels higher up the stack.
Q: How do I links against a DEBUG or DEBUG-SAFE build of BDE?
A: You have to add dbg
and/or safe
flags to the ufid during
configuration.
Q: How do I see the contents of my STL containers in my debugger?
A: See GDB Pretty Printers
Q: How do I contribute to BDE?
A: Background on how to contribute to BDE is here: Contributing to BDE
A walkthrough for how to clone and build the BDE source code are here: Building Using CMake
Reference information for building is here: BDE tools documentation