The documentation states that:
The nested class describes an object whose construction ensures that
the standard iostreams objects are properly constructed, even before
the execution of a constructor for an arbitrary static object.
As seen at:
https://msdn.microsoft.com/en-gb/library/fbyc90zw.aspx
But since static objects have an undefined init ordering how does ios_base::Init ensure that it runs before them?
I would hazard that the order of initialization of static variables is undefined, but the order of constructor calls for creation of an object/variable (static or not) is well defined.
The ios_base::Init class is nested in the ios_base class. So when any ios_base instance is constructed, the ios_base::Init constructor is run as well.
It doesn't matter which of the possible static instances of an object using ios_base exist or what order they run in. All that matters is that the ios_base::Init gets to run and initialize the standard streams first (all other constructor calls to ios_base::Init likely do nothing since the work is already done by the first constructor call).
Related
I am learning about virtual function tables and their representation by analyzing a binary of a simple program written in Visual C++ (with some optimizations on).
A few days ago I asked this question while being stuck on virtual method table content with identical COMDAT folding on.
Now I'm stuck on something else: whenever I analyze a class, I need to find its Virtual Method Table. I can do this by finding either its RTTITypeDescriptor or _s_RTTIClassHierarchyDescriptor, finding a cross reference on it, which should lead me to the _RTTICompleteObjectLocator. When I find a cross reference to the Complete Object Locator, it is written just before the VMT (basically -1st entry of the VMT).
This approach works on some classes (their names start with C in my program). Then there are classes, that are named with I in the beginning and I am able to pair them with other classes starting with C -- for example there is class CClass and it inherits from IClass. These I-classes are probably serving as interfaces to the C-classes and thus they probably only contain abstract methods.
By searching a cross reference to Type Descriptor or Class Hierarchy Descriptor of any of the I-classes I cannot find anything -- there is no Complete Object Locator that would lead me to the VMT of the class (that should be full of references to pure_virtual call if I am correct about the all-abstract methods in the I-classes and if I understand correctly what VMT of abstract class looks like).
Why do the I-classes have no VMT? Did the compiler optimize it out because it would just be full of references to pure_virtual call and manages it in a different way?
These "interfaces" abstract classes probably have need no user written code in any their constructors and destructors (these either have an empty body and no ctor-init-list, or simply are never user defined); let's call these pure interface classes.
[Pure interface class: concept related but not identical to Java interfaces that are (were?) defined as having zero implementation code, in any member function. But be careful with analogies, as Java interfaces inheritance semantic isn't the same as C++ abstract classes inheritance semantic.]
It means that in practice no used object ever has pure interface class type: no expression ever refers to an object with pure interface type. Hence, no vtable is ever needed, so the vtable, which may have been generated during compilation, isn't included in linked code (the linker can see the symbol of the pure interface class vtable isn't used).
From p498 of Programming Language Pragmatics, by Scott
With a reference model for variables, every object is created
explicitly, and it is easy to ensure that an appropriate constructor
is called.
With a value model for variables, object creation can happen
implicitly as a result of elaboration. In Ada, which doesn’t provide
automatic calls to constructors by default, elaborated objects begin
life uninitialized, and it is possible to accidentally attempt to use
a variable before it has a value. In C++, the compiler ensures that an
appropriate constructor is called for every elaborated object, but the
rules it uses to identify constructors and their arguments can
sometimes be confusing.
What does it mean by creating an object "explicitly" and "implicitly as a result of elaboration"?
What does "elaboration" mean?
Thanks.
The situation is this: I want to use a single duktape/C function for all functions I define on my objects + prototypes. For that I have a function map which takes a function name and a callback (a std::function actually) and can so easily do some common processing and have simpler callbacks (can even use in-place lambdas for that).
That already works nicely, with one problem: same named functions on different objects. In order to disambiguate I now use the heap pointer of an object (or a prototype, which is also an object) as further qualifier. Hence when my central duktape/C function is called I first look if the function is global (i.e. is a defined on the global object). If that fails I get the this binding and do a lookup with its heap pointer. If that also fails I walk the prototype chain and see if I can find the function on one of the prototypes.
This works well to 99%, except in cases where I don't have a this binding (or a wrong one, like for Function.prototype.apply()).
My question is therefor: how can I get the original prototype for a function in my central duktape/C callback?
The answer is simpler than I first thought. For that central function map you need to have the function name. That has to be set as property on the function object you create when you define a new function on an object or prototype.
The same approach can be used for the original object/prototype. Simply add a back reference to that to your function object as another property (say "ptr"). With that you can easily get not only the function's name but also the context for it's execution. And no walk of the inheritance chain is necessary since we already have the correct object/prototype.
I recently read in "Professional C# 4 and .NET 4" that:
You can never instantiate an interface.
But periodically I see things like this:
IQuadrilateral myQuad;
What are the limitations in using interfaces directly (without having a class inherit from the interface)? How could I use such objects (if they can even be called objects)?
For example instead of using a Square class that derives from IQuadrilateral, to what extent could I get away with creating an interface like IQuadrilateral myQuad?
Since interfaces don't implement methods, I don't think I could use any methods with them. I thought interfaces didn't have fields to them (only properties), so I'm not sure how I could store data with them.
The answer is simple, you can't instantiate an interface.
The example you provided is not an example of instantiating an interface, you are just defining a local variable of the type IQuadrilateral
To instantiate the interface, you would have to do this:
IQuadrilateral myQuad = new IQuadrilateral();
And that isn't possible since IQuadrilateral does not have a constructor.
This is perfectly valid:
IQuadrilateral myQuad = new Square();
But you aren't initiating IQuadrilateral, you are initiating Square and assigning it to a variable with the type IQuadrilateral.
The methods available in myQuad would be the methods defined in the interface, but the implementation would be based on the implementation in Square. And any additional methods in Square that are not part of the IQuadrilateral interface would not be available unless you cast myQuad to a Square variable.
You can't create an instance of an interface.
The code you showed defines a variable of type IQuadrilateral. The actual instance this variable points to will always be of a concrete class implementing this interface.
Background Knowledge
Think of an interface as a contract. In a contract between two people, it defines what is capable, what is expected from the parties involved. In programming, it works the same way. The interface defines what to expect, what must exist for you to conform to that interface. Therefore, since it only defines what to expect, it itself, doesn't provide the implementation, the "code under the covers" so to speak, does.
A property behaves like a field, but allows you to intercept when someone assigns a value to it or reads the value. You can also deny reading or writing to it, your choice when you define the property. Interfaces work with properties instead of fields because of this. Since the "contract" is just defining what property should be there (name and type), and if it should allow a read or write capabilities, it leaves it up to the implementer to provide this.
Take for example the IEnumerator interface from the .NET framework. This interface was designed to allow iteration over a collection of objects. The purpose is not to change items, or randomly access them, it's just for getting object A and moving to the next, and the next, and the next, as many times as needed. Many collection type classes implement this: Queue, ArrayList, SortedList, Stack, etc. All these types of objects store many objects and now they all share the common "contract": the ability to iterate one-by-one over them.
However, you can see that the IEnumerator interface has a MoveNext() method declared. Why? This is because the items may not be served in the same manner. For example, people will generally access the ArrayList from the first item to the last. But a Stack was designed opposite, for people to access the last object down to the first.
Questions Answered
With all this knowledge, the limitation of declaring a variable as the interface type as opposed to the class type that implemented the interface is that you only get access to what the interface (the contract) says should be there. The benefit though is that you can assign to this variable any class type that implements the interface.
Background: I am programming a .NET compiler (very similar to C#) for a school project. One of the features I am currently trying to add is tailcall recursion within methods.
More info: In CIL, the "this" is passed into instance methods as if it were just another argument. So, accessing the first argument of a static method, you would emit ldarg.0, but accessing the first argument of an instance method, you would emit ldarg.1, and accessing "this" in an instance method you would emit ldarg.0. (Instance methods are even more similar to extension methods than I ever imagined.)
Question: Can you set "this" using starg.0 without any side effects?
Why this is in question: Whether or not a method is an instance method is set with the MethodBuilder, which is a bit of a black box. Although "this" seems just like any other argument, for all I know some JIT compilers keep track of "this" separately and change their behavior depending on this value. If there are side effects when you set "this" in an instance method, then how can I avoid them?
You may want to have a look at how F# implements tail-call.
You can extract this as a local variable. This way you will know that you can set it safely. (I hope I understand your question correctly)