To Stl or !Stl, That Is the Question

To STL or !STL, that is the question

Projects with strict memory requirements such as for embedded systems may not be suited for the STL, as it can be difficult to control and manage what's taken from and returned to the heap. As Evan mentioned, writing proper allocators can help with this, but if you're counting every byte used or concerned with memory fragmentation, it may be wiser to hand-roll a solution that's tailored for your specific problem, as the STL has been optimized for the most general usage.

You may also choose not to use STL for a particular case because more applicable containers exist that are not in the current standard, such as boost::array or boost::unordered_map.

C++ STL question: allocators

STL classes by default allocate their internal buffers from the heap, although these classes also allow custom allocators that allow a user to specify an alternate location to allocate from - e.g. a shared memory pool.

C++ STL type_traits question

The example below should illustrate the difference. Let's add struct X:

struct X
{
  X(int)
  {
  }
};

and modify one foo as below:

template <typename T> void foo(T t, true_type)
{
    std::cout << t << " is integral";
    X x(t);
}
template <typename T> void foo(T t, false_type)
{
    std::cout << t << " is not integral";
}

Then:

template <typename T> void bar(T t)
{
    foo(t, typename is_integral<T>::type());
}

Will still compile for all T types (including integer types; it may cause warning but will compile).

The other equivalent code:

template <typename T> void foo(T t)
{
    if(std::is_integral<T>::value)
    {
        std::cout << "integral";
        X x(t);
    }
    else
        std::cout << "not integral";
}

will often fail to compile as you will not be able to instantiate X for types other then integral and eventually floating point and user defined classes which have operator int() (operator short() or operator long() will not do).

What is the point of STL?

It's the C++ standard library that gives you all sorts of very useful containers, strings, algorithms to manipulate them with etc.

The term 'STL' is outdated IMHO, what used to be the STL has become a large part of the standard library for C++.

If you are doing any serious C++ development, you will need to be familiar with this library and preferably the boost library. If you are not using it already, you're probably working at the wrong level of abstraction or you're constraining yourself to a small-ish subset of C++.

C++ STL question related to insert iterators and overloaded operators

What would work would be using the constructor (which would make more sense instead of the assignment):

class MyContainer {
public:
 string value;

    MyContainer(const string& s): value(s) {
    }
};

Then the second problem is that set also requires its contents to be comparable.

As to the cause, insert_iterator works by overloading operator=:

insert_iterator<Container>& operator= (typename Container::const_reference value);

As you can see, the righthand value must be either the value type of the container or implicitly convertible to it, which is exactly what a (non-explicit) constructor achieves and the assignment operator doesn't.

---

Technically you could also make it work without changing the class (e.g if you don't want an non-explicit constructor) by providing a suitable conversion function:

MyContainer from_string(const std::string& s)
{
    MyContainer m;
    m = s;    //or any other method how to turn a string into MyContainer
    return m;
}

which can be used with std::transform:

transform(strings.begin(), strings.end(), inserter(containers, containers.end()), from_string);

Is STL a part of core of c++?

(1) and (2) both depend on your definitions. "The STL" is technically not part of standard C++, but sufficiently large portions of it were adapted into the original standard that the name stuck. But yes, the templated containers commonly reffered to as the STL are part of the official, standard C++ library. "Core" might be a stretch; a compiler can actually leave them out of freestanding implementation, but you're almost never going to find yourself writing for a freestanding implementation so the distinction doesn't really matter.

(3) Do they serve any other purpose? Yes, that is one purpose. As Steve Jessop points out below, they also connect things like streams, that can be iterated without actually being a container, to algorithms.

(4) Are you referring to std::list? Then you are correct. Unless you want to play with semantics; they are stored sequentially, but maybe not contiguously.

(5) In the original standard, published in '98, this would have been a maybe. In the modified standard from '03, this got changed to a yes. In both cases, the semantic argument from (4) can also be applied

C Analog To STL

Yes, glib is a pretty good choice: it includes a lot of utilities for manipulating containers like linked lists, arrays, hash tables, etc. And there is also an object-oriented framework called GObject that you can use to make objects with signals and slots in C (albeit with rather verbose function call names like gobject_set_property, since C doesn't have any syntax for objects). And there is also code for main loops so you can write event-driven programs.

For more info see wikipedia: https://en.wikipedia.org/wiki/GLib

Glib was originally part of GTK, but the non-GUI code has been completely factored out so that you can use it in command-line programs: http://library.gnome.org/devel/glib/stable/

Some questions about Vector in STL

1. In a contiguous memory block on the heap. A vector<int> allocates memory the same way new int[x] would.
2. Only if you use the at method. It throws an std::out_of_range exception if the boundary check fails. The operator[] doesn't perform bounds checking.
3. Because an array gives direct access to memory, while accessing a vector element most likely involves a method call. The difference can be ridiculously small though, especially if your compiler decides to inline the calls.
4. In general, you'll use a vector if you want your container to have a dynamic size, and a simple array if a known fixed size is enough. Be sure to check out the other containers, like deque and list, to be sure you pick the most appropriate one. Otherwise, if you need to deal with non-C++ APIs, you'll obviously need to have access to a regular array. (edit) @BillyONeal says you should use &vector[0] to get the address of the underlying array, but use it with care since it can change if the vector's capacity changes.

Should I learn to use the C++ STL containers instead of building them?

As a software engineer/developer, you should know how a particular data structure works under the hood. and you should be able to customize/invent one when you need it. that's the reason they thought you so.

But generally you won't need to reinvent the wheel. so when there are tried and tested data structures available, like the std::stack, there's no need to do it again. specially because you'll have more bug issues in your implementation than those of STL or any other well designed one like Boost.

---

Related Topics