If I recall, the standard allows string::c_str()
to return pretty much anything that satisfies:
- Storage which is large enough for the contents of the string and the terminating
NULL
- Must be valid until a non-const member of the given
string
object is called
So in practice, this means a pointer to the internal storage; as there is no way to externally track the life of the returned pointer. I think your optimisation is safe to assume this is (small) constant time.
On a related note, if string formatting is performance limiting; you may find better luck deferring the evaluation until absolutely needed with something like Boost.Phoenix.
Boost.Format
I believe defers the formatting internally until the result is required, and you can use the same format object repeatedly without re-parsing the format string, which I've found to make a significant difference for high-frequency logging.
Why is multiple inheritance possible in C++, but not in C#?
I think (without having hard reference), that in Java they wanted to limit the expressiveness of the language to make the language easier to learn and because code using multiple inheritance is more often too complex for its own good than not. And because full multiple inheritance is a lot more complicated to implement, so it simplified the virtual machine a lot too (multiple inheritance interacts especially badly with garbage collector, because it requires keeping pointers into the middle of object (at the beginning of the base))
And when designing C# I think they looked at Java, saw that full multiple inheritance indeed wasn't missed much and elected to keep things simple as well.
How does C++ resolve the ambiguity of identical method signatures inherited from multiple base classes?
It does not. There is a syntax to call base class method from specific base explicitly, but there is no way to override only one of the virtual methods and if you don't override the method in the subclass, it's not possible to call it without specifying the base class.
And why is the same design not incorporated into C#?
There is nothing to incorporate.
Since Giorgio mentioned interface extension methods in comments, I'll explain what mixins are and how they are implemented in various languages.
Interfaces in Java and C# are limited to declaring methods only. But the methods have to be implemented in each class that inherits the interface. There is however large class of interfaces, where it would be useful to provide default implementations of some methods in terms of others. Common example is comparable (in pseudo-language):
mixin IComparable {
public bool operator<(IComparable r) = 0;
public bool operator>(IComparable r) { return r < this; }
public bool operator<=(IComparable r) { return !(r < this); }
public bool operator>=(IComparable r) { return !(r > this); }
public bool operator==(IComparable r) { return !(r < this) && !(r > this); }
public bool operator!=(IComparable r) { return r < this || r > this; }
};
Difference from full class is that this can't contain any data members. There are several options for implementing this. Obviously multiple inheritance is one. But multiple inheritance is rather complicated to implement. But it's not really needed here. Instead, many languages implement this by splitting the mixin in an interface, which is implemented by the class and a repository of method implementations, that are either injected into the class itself or an intermediate base class is generated and they are placed there. This is implemented in Ruby and D, will be implemented in Java 8 and can be implemented manually in C++ using the curiously recurring template pattern. The above, in CRTP form, looks like:
template <typename Derived>
class IComparable {
const Derived &_d() const { return static_cast<const Derived &>(*this); }
public:
bool operator>(const IComparable &r) const { r._d() < _d(); }
bool operator<=(const IComparable &r) const { !(r._d() < _d(); }
...
};
and is used like:
class Concrete : public IComparable<Concrete> { ... };
This does not require anything to be declared virtual as regular base class would, so if the interface is used in templates leaves useful optimization options open. Note, that in C++ this would probably still be inherited as second parent, but in languages that don't allow multiple inheritance it's inserted into the single inheritance chain, so it's more like
template <typename Derived, typename Base>
class IComparable : public Base { ... };
class Concrete : public IComparable<Concrete, Base> { ... };
The compiler implementation may or may not avoid the virtual dispatch.
A different implementation was selected in C#. In C# the implementations are static methods of completely separate class and the method call syntax is appropriately interpreted by compiler if a method of given name does not exist, but an "extension method" is defined. This has the advantage that extension methods can be added to already compiled class and the disadvantage that such methods can't be overriden e.g. to provide optimized version.
Best Answer
Let's think about this very carefully. libA.so is statically linked with the STL. However, the STL does not exist in isolation, it requires the C runtime (CRT). They both reside in the libstdc++.a static library. This means that libA.so and libB.so have separate CRT data structures. In particular, the heap used by libA.so is different from the heap used by libB.so. Allocating a string from libA's runtime heap and attempting to free from libB's runtime will simply not work because libB's runtime has no records of allocating the string. The only way to correctly destruct the string is by calling the destructor within libA.so.
One might ask: but libB.so receives a copy of the string, right? Yes that's right but who has allocated this copy? It has been allocated using the copy constructor within the context of the libA's runtime.
That said, you can still use the string from libB.so. You just cannot destruct it from there.
You can also let libB receive a pointer to the string and then creating a copy of it within the context of the libB's runtime. That copy can be destructed by libB.
And that's why static linking is sometimes bad.