article on C compiler and standard lib C related to osdev

[h0bby1]

I give up.

Your knowledge of C++ goes well beyond my charted territory.

JFYI: RTTI is usually disabled in well-designed C++ software, just because it is not necessary and incurs some overhead which can be avoided altogether.

Ok it's usually disabled, in which case it's not a problem. But it's there, can be enabled, and needed by some c++ code. Which is why it's mentioned .

But it's ok to give up, you don't seem to have anything relevant to say anyway

But yes the RTTI can be disabled, and should be disabled anyway which is what i say in the article. But still, in the case it's enabled, it will use some functions of the runtime.

It can be proven easily with simple C++ code compiled without using any compiler specific Library. Some case will require RTTI to be enabled, and will fail to link without the C runtime being linked into the exe. And it's still supported by many c++ building environment.

[Griwes]

ok, so it's an abract class. but the term virtual class can also be used.
http://en.wikipedia.org/wiki/Virtual_class

Did you actually try to READ what you've just quoted?

Virtual class is a very different matter from an abstract class. Please learn to read and read that wikipedia article.

Still, what i said about virtual class related to runtime type information is still correct. Both abstract class and virtual class use RTTI to find out the type that is used to construct them at runtime. In case of abstract class, it is mandatory to have a class that will override it's member at runtime, and the base class will never be used in the program, so if you want to know the type of an abstract class at runtime, you need RTTI. And same with virtual class that are constructed using a subclass.

There are many case where you need RTTI to deal with the actual type of a virtual or abstract class. It can be avoided, and should not be recommended for 'clean' c++ design, but they are still there.

For the last time: there is no such thing as "virtual class" in C++. Go grep the standard. We are talking C++, so random OOP concepts that are not defined in the ISO 14882 are irrelevant.

Many cases? About two. I mentioned them long time ago.

You do not need RTTI to find out what type is constructed (WTF). The construction always uses new operator, and the type used in new operator is determined at compile time. Check for member overrides is done at compile time. And if you feel need to know real type of a polymorphic object, except in the few cases I mentioned before, you really have no clue what virtual dispatching is about (tip: it's about invoking a correct function *without* knowing the real type of a polymorphic object. That's the whole Goddamn point.).

I give up.

Your knowledge of C++ goes well beyond my charted territory.

JFYI: RTTI is usually disabled in well-designed C++ software, just because it is not necessary and incurs some overhead which can be avoided altogether.

Nope, well designed software uses exceptions (and they require RTTI) and things *like* Boost.Any (and they require RTTI).

[h0bby1]

For the last time: there is no such thing as "virtual class" in C++. Go grep the standard. We are talking C++, so random OOP concepts that are not defined in the ISO 14882 are irrelevant.

Many cases? About two. I mentioned them long time ago.

You do not need RTTI to find out what type is constructed (WTF). The construction always uses new operator, and the type used in new operator is determined at compile time. Check for member overrides is done at compile time. And if you feel need to know real type of a polymorphic object, except in the few cases I mentioned before, you really have no clue what virtual dispatching is about (tip: it's about invoking a correct function *without* knowing the real type of a polymorphic object. That's the whole Goddamn point.).

you need RTTI if you want to cast a base class back to the subclass it has been constructed with. If you use the Baseclass in some part of the code, constructed using a subclass constructor, and then you need to use at some other point of the code some non virtual member defined in the derived class starting from a pointer to the base class, you need RTTI to know at runtime the actual type of the class.

The thing is that even if you manipulate the class using a pointer to one of it's base class, the compiler can still keep track of the type of the subclass derived from the baseclass that baseclass is an instance of , and with rtti you can cast back the base class pointer to the subclass type it has been constructed as.

it's not necessarily limited to class who have virtual members btw.

But anything that use virtual method in class will also need some compiler specific runtime routines.

But indeed, the two are not necessarily related, and RTTI and handling of class with virtual methods are two different things. But you can also need RTTI to cast a base class with virtual members to the subclass that has been used to construct it, in which case it will involve both part of the runtime involved with the virtual methods, and part of the runtime involved with RTTI.

It's just that using a base class with virtual member to reference an instance of the subclass is the case where you are most likely to need RTTI because it can be useful to know at runtime which subclass the baseclass pointer has been constructed as. As the actual value of the baseclass virtual members depend on which subclass has been used to instanciate it. And a base class with virtual members is more likely to be used as a reference to the subclass instance. And in some case it can be useful to be able to get back the actual subclass instance that the base class has been constructed as.

If the baseclass doesn't have virtual member, you are less likely to need to know about the subclass that has been used to construct it.

[Owen]

you need RTTI if you want to cast a base class back to the subclass it has been constructed with.

Wrong.

If you use the Baseclass in some part of the code, constructed using a subclass constructor, and then you need to use at some other point of the code some non virtual member defined in the derived class starting from a pointer to the base class, you need RTTI to know at runtime the actual type of the class.

Wrong

The thing is that even if you manipulate the class using a pointer to one of it's base class, the compiler can still keep track of the type of the subclass derived from the baseclass that baseclass is an instance of , and with rtti you can cast back the base class pointer to the subclass type it has been constructed as.

You can do the cast-back without RTTI

it's not necessarily limited to class who have virtual members btw.

Classes without virtual member have no RTTI-data pointers anyway...

But indeed, the two are not necessarily related, and RTTI and handling of class with virtual methods are two different things. But you can also need RTTI to cast a base class with virtual members to the subclass that has been used to construct it, in which case it will involve both part of the runtime involved with the virtual methods, and part of the runtime involved with RTTI.

Wrong and WRONG. There is no part of the runtime involved with virtual methods (aside from a single function normally used to stuff the vtable entries for pure virtual functions)

It's just that using a base class with virtual member to reference an instance of the subclass is the case where you are most likely to need RTTI because it can be useful to know at runtime which subclass the baseclass pointer has been constructed as. As the actual value of the baseclass virtual members depend on which subclass has been used to instanciate it. And a base class with virtual members is more likely to be used as a reference to the subclass instance. And in some case it can be useful to be able to get back the actual subclass instance that the base class has been constructed as.

In most cases, if you need to use RTTI to establish the type of a class... you're doing something very wrong.

[h0bby1]

and btw beyond this, if the whole process of compiling a c++ files to an executable would be covered by a single spec that all compiler would follow, there would be no need for this article, but unfortunately, it's far from being the case.

[h0bby1]

you need RTTI if you want to cast a base class back to the subclass it has been constructed with.

Wrong.

Right.

If you use the Baseclass in some part of the code, constructed using a subclass constructor, and then you need to use at some other point of the code some non virtual member defined in the derived class starting from a pointer to the base class, you need RTTI to know at runtime the actual type of the class.

Wrong

Right.

The thing is that even if you manipulate the class using a pointer to one of it's base class, the compiler can still keep track of the type of the subclass derived from the baseclass that baseclass is an instance of , and with rtti you can cast back the base class pointer to the subclass type it has been constructed as.

You can do the cast-back without RTTI

you can do the cast back, but for it to works correctly in all case, it need RTTI.

it's not necessarily limited to class who have virtual members btw.

Classes without virtual member have no RTTI-data pointers anyway...

Ok right.

But indeed, the two are not necessarily related, and RTTI and handling of class with virtual methods are two different things. But you can also need RTTI to cast a base class with virtual members to the subclass that has been used to construct it, in which case it will involve both part of the runtime involved with the virtual methods, and part of the runtime involved with RTTI.

Wrong and WRONG. There is no part of the runtime involved with virtual methods (aside from a single function normally used to stuff the vtable entries for pure virtual functions)

There are part of the runtime involved, like the vtable. If you link an exe that use virtual class without the runtime, it will most likely fail to link.

And i'm not sure how it would work out to get a pointer to a base class from a function exported from a program compiled using a different compiler. Like you would have the base class definition included in a program, but instancied in another program compiled with another compiler returning a pointer to the sub class, i'm really not sure it would just work fine in all cases.

It's just that using a base class with virtual member to reference an instance of the subclass is the case where you are most likely to need RTTI because it can be useful to know at runtime which subclass the baseclass pointer has been constructed as. As the actual value of the baseclass virtual members depend on which subclass has been used to instanciate it. And a base class with virtual members is more likely to be used as a reference to the subclass instance. And in some case it can be useful to be able to get back the actual subclass instance that the base class has been constructed as.

In most cases, if you need to use RTTI to establish the type of a class... you're doing something very wrong.

[/quote]

Well very wrong maybe, but it's still things that can be made and that many compiler allow to do.

I'm not saying everyone should do it, or that it's good practice , or that i use it, but it's still something compilers allow to do that need the runtime to work properly.

[Griwes]

For the last time: there is no such thing as "virtual class" in C++. Go grep the standard. We are talking C++, so random OOP concepts that are not defined in the ISO 14882 are irrelevant.

Many cases? About two. I mentioned them long time ago.

You do not need RTTI to find out what type is constructed (WTF). The construction always uses new operator, and the type used in new operator is determined at compile time. Check for member overrides is done at compile time. And if you feel need to know real type of a polymorphic object, except in the few cases I mentioned before, you really have no clue what virtual dispatching is about (tip: it's about invoking a correct function *without* knowing the real type of a polymorphic object. That's the whole Goddamn point.).

you need RTTI if you want to cast a base class back to the subclass it has been constructed with. If you use the Baseclass in some part of the code, constructed using a subclass constructor, and then you need to use at some other point of the code some non virtual member defined in the derived class starting from a pointer to the base class, you need RTTI to know at runtime the actual type of the class.

The thing is that even if you manipulate the class using a pointer to one of it's base class, the compiler can still keep track of the type of the subclass derived from the baseclass that baseclass is an instance of , and with rtti you can cast back the base class pointer to the subclass type it has been constructed as.

it's not necessarily limited to class who have virtual members btw.

But anything that use virtual method in class will also need some compiler specific runtime routines.

But indeed, the two are not necessarily related, and RTTI and handling of class with virtual methods are two different things. But you can also need RTTI to cast a base class with virtual members to the subclass that has been used to construct it, in which case it will involve both part of the runtime involved with the virtual methods, and part of the runtime involved with RTTI.

It's just that using a base class with virtual member to reference an instance of the subclass is the case where you are most likely to need RTTI because it can be useful to know at runtime which subclass the baseclass pointer has been constructed as. As the actual value of the baseclass virtual members depend on which subclass has been used to instanciate it. And a base class with virtual members is more likely to be used as a reference to the subclass instance. And in some case it can be useful to be able to get back the actual subclass instance that the base class has been constructed as.

If the baseclass doesn't have virtual member, you are less likely to need to know about the subclass that has been used to construct it.

Ok, first, you apparently have no idea what the terminology is in a language you are talking about - there's no such thing as subclass in C++.

For the second last f*cking time.

The whole point of virtual functions is that you don't have to know the real type.

The whole point of designing interfaces is that you won't ever need to know real type.

But anything that use virtual method in class will also need some compiler specific runtime routines.

WTF is this bullshit. First, there is no such thing as "method" in C++. It's called "member function". And virtual calls are just "fetch virtual table pointed to by vptr, fetch function address, call it". I have been using virtual functions in my kernel almost since the very beginning with -fno-rtti and it all worked. Magic?

But you can also need RTTI to cast a base class with virtual members to the subclass that has been used to construct it, in which case it will involve both part of the runtime involved with the virtual methods, and part of the runtime involved with RTTI.

No, it will invoke just RTTI. Virtual functions have nothing to do with downcasting, except they enable doing so with dynamic_cast.

And for the last time.

In sane code, except rare cases I mentioned numerous times now, you will never encounter downcasting.

If the baseclass doesn't have virtual member, you are less likely to need to know about the subclass that has been used to construct it.

...I won't even comment this.


--------------------


You have serious problems, mate. You have some little pieces of knowledge, and you think you have it all. The misconceptions in your posts are clearly visible to anyone knowing the core features of C and C++. Please stop embarrassing yourself and being a stubborn quasi-expert.

If you want to teach, learn the subject first. That's the basic rule, I thought I will never ever need to mention it, because it's basic enough for children to grasp it, but you have failed at following it.

Anyway, I am out of these forums. The amount of bullshit, RTFM and people lacking the ability to read, learn and Google is too high for this to be usable. I might come back when you guys start banning idiots posting gibberish posts, quasi knowledge and RTFM questions, but until then, there is no point in even reading the threads here.


PS

and btw beyond this, if the whole process of compiling a c++ files to an executable would be covered by a single spec that all compiler would follow, there would be no need for this article, but unfortunately, it's far from being the case.

Lack of standardized C++ ABI is a feature. Portability is impossible when an ABI is required to work the same way everywhere.

And there is no need for this "article", as the whole subject is covered by cross compiler pages (although they'd need some more "clang is a native cross compiler" notes).

[h0bby1]

http://www.openrce.org/articles/full_view/23

RTTI (Run-Time Type Identification) is special compiler-generated information which is used to support C++ operators like dynamic_cast<> and typeid(), and also for C++ exceptions. Due to its nature, RTTI is only required (and generated) for polymorphic classes, i.e. classes with virtual functions.

[h0bby1]

WTF is this bullshit. First, there is no such thing as "method" in C++. It's called "member function". And virtual calls are just "fetch virtual table pointed to by vptr, fetch function address, call it". I have been using virtual functions in my kernel almost since the very beginning with -fno-rtti and it all worked. Magic?

You don't necessarily need RTTI to use virtual function. You just need it for some dynamic_cast that use the classes.

And for the last time.
In sane code, except rare cases I mentioned numerous times now, you will never encounter downcasting.

yes ok, so if everyone follow your definition of 'sane code', with a 'sane setup' limited to be setup using gcc then yes you don't need those. But it's not exactly the only definition possible.

You have serious problems, mate. You have some little pieces of knowledge, and you think you have it all. The misconceptions in your posts are clearly visible to anyone knowing the core features of C and C++. Please stop embarrassing yourself and being a stubborn quasi-expert.

Well most if not all people posting in this thread have shown also how biased they are toward windows, and mostly take a biased point of view on things, and consider anything out of this bias in not sane.

If you want to teach, learn the subject first. That's the basic rule, I thought I will never ever need to mention it, because it's basic enough for children to grasp it, but you have failed at following it.

I already learned the subject, you can then play with term used, and originally the article is more about C than C++.

Anyway, I am out of these forums. The amount of bullshit, RTFM and people lacking the ability to read, learn and Google is too high for this to be usable. I might come back when you guys start banning idiots posting gibberish posts, quasi knowledge and RTFM questions, but until then, there is no point in even reading the threads here.

ok as you want lol if you can't talk calmy and remain centered in a discussion or explain calmy what you have to say, internet might be too much for you.

Lack of standardized C++ ABI is a feature. Portability is impossible when an ABI is required to work the same way everywhere.

And there is no need for this "article", as the whole subject is covered by cross compiler pages (although they'd need some more "clang is a native cross compiler" notes).

yes it's not needed if you don't consider than any other compiler than gcc is 'insane' and that anyone using different programming method is also insane, but if you want to actually use other compilers than gcc, and multiple compiler to make inter operable objects, then the cross compiler method will just doesn't make it happen.

If you want to exclude linux, you can safely skip any gcc related information and stick with visual studio default runtime as well without even needing any gcc ever at all. Gcc is not necessary to build an OS or anything else actually. Neither as a cross compiler or as a host compiler. There are plenty of other compilers out there that can be used to build pretty much anything you want to build. But i got it that any setup that doesn't use gcc as a cross compiler is not sane according to you, but some other people opinion might differ about that.

[h0bby1]

the article is not about linux vs windows, or about good or bad coding practice in C or C++, it's about how the process of making an exe out of a C program works, and what need to be done if you want to make some C program that can be compiled with different compilers and being inter operable with each others.

Which i have successfully made, on many project, not by accident, and also using c++, virtual classes or other things. either on windows, linux, macos, using various compilers.

It's just crystal clear if you use virtual function without care, you'll need runtime function specific to the compiler used linked with the executable. Just try to compile some c++ code on any compiler without using the compiler's runtime and C library. Most of the time, it will not link because it need some functions of the runtime specific to handling of virtual function, and possibly rtti in some cases.

If any feature of any compiler or build environment can be used by a compiler to generate executable code, good or bad, sane or insane, holy linux god made standard or not, it still need to be issued to avoid problems.

and as far as i know, the behavior of any specific compiler can still be defined rather clearly. Either it is regarding virtual functions, RTTI, calling convention, or other things, each compiler will still have normally a documented behavior and format used, and can be also configured in a build configuration to override the default behavior they have. Or to follow a particular fashion of handing a particular thing.

Either it use gcc or not, or as a cross compiler or not.

[h0bby1]

the only thing that most post in this thread revolve around is showing a bias against windows toward gcc, and to make gcc the only possible solution to develop an os, which is completely wrong to begin with. I don't think lot of people who posted in that thread know much about visual studio and windows development in general.

And using virtual functions, require some compiler specific handling. Including potentially RTTI. I'm not saying any c++ program using virtual function need to have RTTI, or that it's good or bad practice to make c++ code that need RTTI, but it's still something that many c++ compiler will allow, and that will require compiler specific handling.

In itself it's normal, i expected that most people involved in os development will be unix users, with the whole almost political take on community open source development, anti commercial anti microsoft thing that is at the core of linux originally, that any program must be open source, and in that case it's not a problem if all programs must be compiled using a compiler specific to the host, but it's quite a linux paradigm of software development that doesn't apply to all cases. And it can be considered as not that sane in many regards as well.

Then i don't pretend i know how every compiler of the planet will handle everything that can be possibly made in a C or c++ program for any architecture, still i know pretty well how gcc and visual studio will behave for i386 and bit x64, at least for C program, and that an os can be fully made without using gcc at all , neither as a cross compiler or other, and that any gcc who can compile exe for i386 or x64 can be used to make exe that are inter operable with exe made with visual studio or other compilers for the same cpu target.

Some compilers might have too specific behavior on many thing to prevent them to make inter operable exes, the borland c++ for windows is such a case.

You would think who care about borland c++, but it actually has a very nice thing to build GUI that is much superior to the one of visual studio that use the MFC. But borland is a bit on the policy to provide a complete environment to build application on its own, and doesn't have compatibility and standard in mind, so it's special case, lot of compiler can follow a bit this policy as well.

But most of the time, you can still design C program in sort that you can know how any compiler will compile them using compiler specific directive, to be able to produce executable for a particular target with any compiler that can understand directive for anything that might be required to work on the target platform.

This can perfectly be done, it's no magic, it's no accident, it just matter of knowing how the compiler works, and how to specify what you want the compiler to do to produce an executable for the particular target. If the exe has to use functions imported from other module compiled with a different compiler, it can also be done, and it's no magic and no accident.

Using gcc as a cross compiler is only one possibility. There are also other possibility, using other compilers, on other platforms, that can be just safe and sane as well . And then you most likely can make any gcc to produce exe that will be compatible with it if it support the target cpu arch and can understand some directive that are required to make an exe supporting the particular requirement of the target system.

If you don't want to allow the use of any other compiler than the one you use to develop application then the cross compiler option can be viable, otherwise using gcc as a cross compiler and relying on it to develop everything is just a bad solution. If you don't have a linux installed, it's really not a good solution at all. And using other solution doesn't mean any gcc can't be used to compile some module in a safe manner, with a sane build environment that will produce compatible exe in a safe and sane manner based on some well documented gcc feature and specific syntax that any gcc who can compile an exe for the particular cpu will recognize in a well documented manner.

[gerryg400]

the only thing that most post in this thread revolve around is showing a bias against windows toward gcc

I presume by windows, you mean MSVC (because windows is an OS and GCC is a set of tools and can't really be compared).

I suspect that the reason that many of us prefer gcc to MSVC is that it's possible to create a GCC cross-compiler that will run on any of the major platforms (Windows, Linux and Mac included) that will produce identical code on each platform. That means when I compile my OS on my Windows machine it produces exactly the same iso file that is produced when I compile it on Mac or Linux. To me that is of utmost importance. Any other result is an absolute deal-breaker.

I personally have no bias towards Linux. I couldn't care less what operating system I use to do osdev because the host operating system plays no part in the developement other than being the entity that executes the tools. I just build my cross-compiler and get to work.

[h0bby1]

given this c++ program, that i don't claim to be a perfect implementation of anything, but just to show how it's compiled, in the instance using g++ without using any compiler specifc runtime.

Code: Select all

//Base class with virtual function
class BaseClass
{
   public:
     virtual int my_virtual_func()=0;
};


//subclass derived from the base class implementing the virtual function.
class SubClass : public BaseClass
{
   public:
     int my_virtual_func()
     {
       return 1;
     }
};
//crapy new operator to make the exe to compile
char class_memory[128];

void *operator new (unsigned int size)
{
return class_memory;

}

//C function needed by gcc runtime
extern "C"
{
//call when pure virtual function are called
void __cxa_pure_virtual() { while (1); }

//function used specific to gcc runtime
void __libc_csu_init(int argc, char **argv, char **envp){}
void __libc_csu_fini(int argc, char **argv, char **envp){}

int main(int argc,char **argv){return 1;}

//main entry point
int __libc_start_main(int (*main) (int, char * *, char * *), int argc, char * * ubp_av, void (*init) (void), void (*fini) (void), void (*rtld_fini) (void), void (* stack_end))
{
    int ret;

    BaseClass *MyBaseClass;
    SubClass  *MySubClass;

    MyBaseClass      = new SubClass();

    MySubClass       = (SubClass  *)MyBaseClass;

    MySubClass->my_virtual_func();
    
    while(1){}
}

}

again, it's not even supposed to be run or a working executable, or to be a valid code for anything. It needs more things to deal with gcc runtime to be able to compile workable executable from c++.


=>

debian:/home/h0bby1# g++ -nodefaultlibs pouet.cpp -o pp
/tmp/cc4T4lnT.o:(.rodata._ZTI8SubClass[typeinfo for SubClass]+0x0): undefined reference to `vtable for __cxxabiv1::__si_class_type_info'
/tmp/cc4T4lnT.o:(.rodata._ZTI9BaseClass[typeinfo for BaseClass]+0x0): undefined reference to `vtable for __cxxabiv1::__class_type_info'
/tmp/cc4T4lnT.o:(.eh_frame+0x11): undefined reference to `__gxx_personality_v0'
collect2: ld returned 1 exit status
debian:/home/h0bby1#

debian:/home/h0bby1# g++ --no-exceptions -nodefaultlibs pouet.cpp -o pp
/tmp/ccY3JBOV.o:(.rodata._ZTI8SubClass[typeinfo for SubClass]+0x0): undefined reference to `vtable for __cxxabiv1::__si_class_type_info'
/tmp/ccY3JBOV.o:(.rodata._ZTI9BaseClass[typeinfo for BaseClass]+0x0): undefined reference to `vtable for __cxxabiv1::__class_type_info'
collect2: ld returned 1 exit status
debian:/home/h0bby1#

debian:/home/h0bby1# g++ --no-rtti --no-exceptions -nodefaultlibs pouet.cpp -o pp
debian:/home/h0bby1#

i don't even really know what it's doing here internally, and i don't pretend to know everything at how gcc handle the compilation of virtual classes, with or without rtti, but i know both gcc and visual will require some code from their respective runtime, that are specific to each compiler, to be able to make it works. And that if you don't want use compiler specific runtime, you need to take some precaution in the way virtual function are used.

but the scope of this article is more related to C than C++, so actually the point about RTTI and virtual class should not even belong there, another whole article should be made about c++, and RTTI should not be an issue with C program.

This program shouldn't even really require RTTI to be enabled, but still, if you use class with virtual members, it will use some compiler specific function in the runtime. You don't necessarily care about it, because the runtime will be linked statically anyway, BUT if you want to avoid to link with the compiler specific runtime, and you use virtual functions, you need to disable rtti. that's all. period.

[h0bby1]

the only thing that most post in this thread revolve around is showing a bias against windows toward gcc

I presume by windows, you mean MSVC (because windows is an OS and GCC is a set of tools and can't really be compared).

I suspect that the reason that many of us prefer gcc to MSVC is that it's possible to create a GCC cross-compiler that will run on any of the major platforms (Windows, Linux and Mac included) that will produce identical code on each platform. That means when I compile my OS on my Windows machine it produces exactly the same iso file that is produced when I compile it on Mac or Linux. To me that is of utmost importance. Any other result is an absolute deal-breaker.

I personally have no bias towards Linux. I couldn't care less what operating system I use to do osdev because the host operating system plays no part in the developement other than being the entity that executes the tools. I just build my cross-compiler and get to work.

I don't know why, but most people i've met that are interested into os development are not mainly window users/developers . They are generally more linux users, i'm not exactly sure why =)

but yes gcc is clearly one of the most portable compiler around, i don't specially have bias toward a particular os or compiler, there are things i like and don't like in all, but i don't want to exclude any platform that can be used as development platform.

with the way i use, it will not produce identical code, gcc or visual or intel compiler can have their own way to compile and optimize things, but exe produced must still be compatible with each others, in the sense i can use gcc to compile some library or app or anything, and put the binary produced by gcc on the iso along side with other exe/shared libs compiled with visual studio or icc, that's what my goal is.

I still prefer visual studio IDE, because it has many feature to analyze the code , like finding all references to a symbol, and i like the way it manage projects, dependencies, and i have a tool to convert visual studio solution file to makefile to compile it with gcc under POSIX environment.

Depending on a cross compiler or a specific build environment can also be a solution, but different compilers can be used to produce compatible exe and libraries as well. And the feature involved and how to enable them are still well documented for most compilers.

[Combuster]

A few administrative sidenotes:
I just put up the disputed tag on the page because you started publishing the page elsewhere and it took me only ten seconds to find a glaring error - one explicitly mentioned in this thread.

Also, adding entire chapters is definitely not a "minor" edit.