OSDev.org

Karlosoft wrote:The major part of compilers adds instructions or doesn't do some optimizations.

lemonyii wrote:the constructor, i have to call it before my kmain() for global variables

lemonyii wrote:say, what can i get from c++ , in spide of the cost of rewriting my kernel?

• Virtual functions - At runtime some functions may have to be resolved so the right ones are called (it's hard for the compiler to predict what the outcome is going to be).
• Exceptions - Although you're going to have these turned off when writing your kernel anyways. It is possible to implement support for this, but I wouldn't advise it. It causes extra instructions to be inserted on the stack so stack unwinding is possible. And the claims "It won't be slow unless I explicitely use throw/try/catch" are false AFAIK. The compiler has to keep track of what functions were called when so it can backtrace through the stack if necessary.
• RTTI (Run-Time Type Identification) - Allows you to know the type of variables at runtime. Anything that is done at runtime and not at compile-time may slow down your code (type checking is usually done at compile-time). It is unlikely that you'll need this. Even if you do, there are workarounds to it.

• Access to classes (basically structures that have variables set to private by default, unless stated otherwise).
• Structures are extended with class-like attributes (access modifiers such as public, private and protected).
• Structures/Classes can have member functions, operator overloads, (multiple) inheritance, etc.
• Practically any function can be overloaded (multiple functions with the same name, but different argument types).
• References - Basically the same as pointers (AFAIK equally fast). Pointers can be null, references can't. They also allow you to directly access a variable as if it were a pointer. The downside is you can't directly see from the use of a variable that it's a reference (pointers have specific syntax, like p->var, (*p) = x, etc. while references have the same syntax as usual variables.
• Default arguments for functions in their declarations, e.g. void foo(int var = 5) allows you to execute foo() and foo(7).

berkus wrote:You can provide static and stack memory allocators for some things for the time before you have real malloc working - which is easy thanks to STL design.

Partially true, but it is possible to call it right at the start of kmain, or at any time in your kernel

class A{
public:
       A(){
           cout<<"constructor"<<endl;
       }
       int b;
};
A a;
int main(){
    cout<<"main"<<endl;
    a.A::A(); //nor can a.A() pass compiling
    while(1);
    return 0;
}

Creature wrote:

• Exceptions - Although you're going to have these turned off when writing your kernel anyways. It is possible to implement support for this, but I wouldn't advise it. It causes extra instructions to be inserted on the stack so stack unwinding is possible. And the claims "It won't be slow unless I explicitely use throw/try/catch" are false AFAIK. The compiler has to keep track of what functions were called when so it can backtrace through the stack if necessary.
• RTTI (Run-Time Type Identification) - Allows you to know the type of variables at runtime. Anything that is done at runtime and not at compile-time may slow down your code (type checking is usually done at compile-time). It is unlikely that you'll need this. Even if you do, there are workarounds to it.

berkus wrote:In the end, the question is how comfortable you feel with the language. This determines your overall efficiency as a programmer and the joy you get from writing code.

Owen wrote:

Creature wrote:

• Exceptions - Although you're going to have these turned off when writing your kernel anyways. It is possible to implement support for this, but I wouldn't advise it. It causes extra instructions to be inserted on the stack so stack unwinding is possible. And the claims "It won't be slow unless I explicitely use throw/try/catch" are false AFAIK. The compiler has to keep track of what functions were called when so it can backtrace through the stack if necessary.
• RTTI (Run-Time Type Identification) - Allows you to know the type of variables at runtime. Anything that is done at runtime and not at compile-time may slow down your code (type checking is usually done at compile-time). It is unlikely that you'll need this. Even if you do, there are workarounds to it.

Lies. Exceptions and RTTI cause absolutely no performance overhead compared to code built without them. When GCC says it has "zero cost" exception handling, it means it. Now, exceptions and RTTI imply runtime overhead when used; but their existence doesn't cause overhead in and of itself.

Creature wrote:

Owen wrote:

Creature wrote:

• Exceptions - Although you're going to have these turned off when writing your kernel anyways. It is possible to implement support for this, but I wouldn't advise it. It causes extra instructions to be inserted on the stack so stack unwinding is possible. And the claims "It won't be slow unless I explicitely use throw/try/catch" are false AFAIK. The compiler has to keep track of what functions were called when so it can backtrace through the stack if necessary.
• RTTI (Run-Time Type Identification) - Allows you to know the type of variables at runtime. Anything that is done at runtime and not at compile-time may slow down your code (type checking is usually done at compile-time). It is unlikely that you'll need this. Even if you do, there are workarounds to it.

Lies. Exceptions and RTTI cause absolutely no performance overhead compared to code built without them. When GCC says it has "zero cost" exception handling, it means it. Now, exceptions and RTTI imply runtime overhead when used; but their existence doesn't cause overhead in and of itself.

The user indicated with his last code sample that he was using GCC, but he never said he was using GCC for his kernel as well. Even if he is, not all compilers (and their versions) handle exception handling the same way. Note also that this "zero cost" exception handling comes at a price: it may take away the problem of having extra overhead when no exceptions are called anyways, but if they are, it will AFAIK give you an additional performance penalty (even worse than the original penalty, if I read the manuals correctly).

PS: I was not aware of the "zero cost" exception handling, thanks for your post.

The user indicated with his last code sample that he was using GCC, but he never said he was using GCC for his kernel as well. Even if he is, not all compilers (and their versions) handle exception handling the same way.

And yes, it makes thrown exceptions very expensive. Guess what? Exceptions are supposed to be exceptional.

Lies. Exceptions and RTTI cause absolutely no performance overhead compared to code built without them. When GCC says it has "zero cost" exception handling, it means it. Now, exceptions and RTTI imply runtime overhead when used; but their existence doesn't cause overhead in and of itself.

C++ Bare Bones article on wiki explains how to call static object constructors before your program runs. In your place I would read the wiki from start to finish THROUGH.

lemonyii wrote:what is ___gxx_personality_v0 on linking?

lemonyii wrote:what is ___gxx_personality_v0 on linking?