[C/C++] Wlasna biblioteka
Ostatnio zmodyfikowano 2012-01-17 16:33
jsc |
» 2012-01-16 21:10:59 Nieźle: Różne kompilatory to różne asemblery. |
|
akwes |
» 2012-01-16 21:14:19 gcc to nie kompilator tylko zestaw kompilatorów, w którym jest g++. wpisałem g++ zamiast gcc z przyzwyczajenia Ciężko żebym kompilował kod C++ dokładnie tym samym co C (odwrotnie się da, wiem, ale tak to dostanę kod c a nie cpp). gcc cos.cpp -S daje to samo co g++ cos.cpp -S . Przynajmniej w tym kodzie. Z tego co wiem to gcc powinno kompilować według rozszerzenia albo sztywno używając parametru -x. Ale tak jak mówię, o kosztach obiektowości wiem tylko z słyszenia. Efekt w asm. Może być również naznaczony tym że C++ domyślnie wstawia więcej linijek bo jakby je porównać to kod robiący coś jest właściwie taki sam. |
|
jsc |
» 2012-01-16 21:33:36 Dobra, jeśli to prawda to udowodniłeś, że identyczny kod ma gorsze kompilatory w C++ niż w C, a to o kosztach obiektowości niczego nie dowodzi, a fakt że śmiecą już na tym etapie wyklucza je z prawdziwej próby. |
|
akwes |
» 2012-01-16 21:41:32 Czyli czego oczekujesz? Kompilacji programu w cpp kompilatorem c? I może jeszcze kompilacje delphi przez kompilator cobola?
To chyba oczywiste że to będą różne kompilatory. GCC to najpopularniejszy zestaw kompilatorów dla systemów uniksowych. Wątpię aby kompilatory używane do kompilacji jądra Linuksów niepotrzebnie śmieciły.
Kwestia napisania wiarygodnego kodu, który będzie można porównać. |
|
jsc |
» 2012-01-16 21:49:46 W takim razie czym się różnią pliki cos.c i cos.cpp, że aż trzeba różnych kompilatorów? |
|
akwes |
» 2012-01-16 22:01:12 Różnią się językiem, w którym są napisane.
Różnica to na przykład to że plik cos.cpp w strukturze ma użyty domyślnie modyfikator dostępu public, a ten w cos.c nie ma tego, bo coś takiego jak dostęp tam nie istnieje, C89 i C99 nawet nie znają takich słów kluczowych jak private czy public.
Niby to wynika z OOP ale to detal, który ma wagę przy małych programach, nie brałbym tego pod uwagę przy liczeniu linii asemblera. |
|
jsc |
» 2012-01-16 22:05:52 Private i public to jest informacja dla kompilatora, aby nawet nie próbować kompilować (czyli tego nie znajdziesz w asemblerze) pewnych czynności na obiekcie. |
|
akwes |
» 2012-01-16 22:10:12 Post wyżej poprawiony. Dzięki @jsc. Jednak dalej jest to różnica w tym co robi kompilator i jak się zachowuje. Masz jakiś pomysł na większy kod, który można porównać? //edit Oto co mi się udało na razie wygrzebać. http://www.brighthub.com/internet/web-development/articles/82024.aspxAs for performance, from a user stand point, the difference between structured and object-oriented programming may be minimal. However in some cases the fact that object-oriented programs are slower seeing as there is extra work the interpreter has to go through to compiler the classes as opposed to the structure method of running in a top down sequence.
| http://www.tayfunbilsel.com/?page_id=9Object Oriented Programming can be pointless and not necessary and slow as well. If you are a performance freak, procedural programming is the way you should go.
| http://programmers.stackexchange.com/questions/125753/does-object-orientation-really-affect-algorithm-performanceObject orientation may prevent certain algorithmic optimizations, because of encapsulation. Two algorithms may work particularly well together, but if they are hidden behind OO interfaces, the possibility to use their synergy is lost.
Look at numerical libraries. A lot of them (not only those written in the 60s or 70s) are not OOP. There is a reason for that -- numerical algorithms work better as a set of decoupled modules than as OO hierarchies with interfaces and encapsulation.
|
Tylko wszystko to jest gdybanie. O tym, że OOP produkuje więcej kodu ASM przeczytałem jako wrzuconą ciekawostkę w jednej z książek o programowaniu mikrokontrolerów ATMEGA (chciałem zrobić wyświetlacz widmowy jednak na razie brak czasu). |
|
1 2 « 3 » 4 5 |