Artykuł traktuje o starszym doświadczonym programiście, który programuje w ASP i ma gdzieś nowoczesne techniki programowania, wszystko pisze proceduralnie i nawet nie potrafii używać debuggera. Miła lektura.
A więc przy okazji życzę wam drodzy użytkowicy 4p, żebyście Wy się nie stali takimi dinozaurami i mieli trochę bardziej otwarte umysły niż ten gość z artykułu. Szczególnie to się tyczy programistów C++, nie dostrzegających że dawno są już o niebo lepsze języki programowania.
Happy Flaming :D
0
0
endless_loop napisał(a)
Szczególnie to się tyczy programistów C++, nie dostrzegających że dawno są już o niebo lepsze języki programowania.
obraziłeś moje uczucia religijne
0
niebo lepsze jezyki czyli jakie? C# a co to jest? to w ogole da sie kompilowac?
0
Kompilacja bezpośrednio do kodu natywnego to zło w 100 %.
0
... napisał(a)
niebo lepsze jezyki czyli jakie? C# a co to jest? to w ogole da sie kompilowac?
Ja zapytam: po co to w ogóle kompilowac? imo szkoda pradu.
0
... napisał(a)
niebo lepsze jezyki czyli jakie? C# a co to jest? to w ogole da sie kompilowac?
hmm...
C:\myprogs>csc hello.cs
Kompilator Microsoft (R) Visual C# 2008 w wersji 3.5.30729.1
dla programu Microsoft (R) .NET Framework w wersji 3.5
Copyright (C) Microsoft Corporation. Wszelkie prawa zastrzeżone.
C:\myprogs>ngen hello.exe
Microsoft (R) CLR Native Image Generator - Version 2.0.50727.3053
Copyright (c) Microsoft Corporation. All rights reserved.
Installing assembly C:\myprogs\hello.exe
Compiling assembly C:\myprogs\hello.exe ...
hello, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null
C:\myprogs>hello
dupa
C:\myprogs>
jakieś jeszcze wątpliwości?
Wibowit napisał(a)
Kompilacja bezpośrednio do kodu natywnego to zło w 100 %.
Nie popadajmy w skrajności. Wciąż większość aplikacji desktopowych jest pisana w tym złym, niedobrym C++.
0
Azarien napisał(a)
jakieś jeszcze wątpliwości?
No dobra ale dalej nie wiem PO CO?
0
Nie wiesz po co?
- kod natywny działa zdecydowanie szybciej.
- Wiele projektów jest kontynuowanych. A co za tym idzie nikt nie będzie przepisywać całego kodu.
- Pełna kontrola nad obsługą pamięci
- „Potęga” C# jest śmieszna w porównaniu z potęgą C++
- Przenośność
Jak dla mnie pisanie w C# ma charakter zbudowania tylko małej (na pewno nie rozbudowanej) aplikacji. Na dodatek, wygląda to częściej jak budowanie czegoś z klocków. Co? Że kiedyś mówiono tak o Delphi? No cóż w końcu to ten sam twórca...
0
Te artykuły polaczka w SDJ będą naprawdę ciekawe :D
0
polaczek17 napisał(a)
Jak dla mnie pisanie w C# ma charakter zbudowania tylko małej (na pewno nie rozbudowanej) aplikacji.
Ta, właśnie siedzę w projekcie, który ma 800k linii kodu. To jest małe i nierozbudowane. :D
0
polaczek17 napisał(a)
Jak dla mnie pisanie w C# ma charakter zbudowania tylko małej (na pewno nie rozbudowanej) aplikacji. Na dodatek, wygląda to częściej jak budowanie czegoś z klocków. Co? Że kiedyś mówiono tak o Delphi? No cóż w końcu to ten sam twórca...
...i to pisze klikacz C++ Buildera, Delphi dla klikaczy C++. C++ do dużych projektów jest cholernie niewygodny, chociażby ze względu na brak modularyzacji.
Poza tym 'przenośność' kodu maszynowego to chyba jedna z największych jego wad, tak samo jak to, że nad pamięcią praktycznie nie sposób zapanować w 100%?
0
deus napisał(a)
C++ do dużych projektów jest cholernie niewygodny, chociażby ze względu na brak modularyzacji.
Deus, zauwazylem ze od pewnego czasu zaczynasz sie osmieszac.
0
OK, gdzie C++ ma sensowny model modularyzacji? Ma model obiektów i linkowania pochodzący z C, połatany wyłącznie przestrzeniami nazw, które najlepiej zrealizowane nie zostały... Wszyscy wiemy żeś C++ zealot, ale sam powiedz, czy ten prehistoryczny model nigdy Ci problemów nie stworzyl?
0
Te artykuły polaczka w SDJ będą naprawdę ciekawe :D
O steganografii pisałem :)
...i to pisze klikacz C++ Buildera, Delphi dla klikaczy C++. C++ do dużych projektów jest cholernie niewygodny, chociażby ze względu na brak modularyzacji.
No dobrze to się zgadza. Samo C++ gdzie jeszcze nie daj Bóg GUI trzeba budować za pomocą WINAPI jest nieporęczne i mozolne. Po to wymyślono Visuala i Buildera. Pod tym względem C++ zdecydowanie bije na głowę C#. Chyba, że myślimy o budowaniu typowych aplikacji bazodanowych. W C# to praktycznie zbiór gotowych funkcji, co przyśpiesza pracę.
Poza tym 'przenośność' kodu maszynowego to chyba jedna z największych jego wad, tak samo jak to, że nad pamięcią praktycznie nie sposób zapanować w 100%?
Dla Ciebie to minus a dla innych plus. Wszystko zależy od projektu. Przenośność to przecież jedna z kluczowych zalet niektórych projektów. Poza tym powiedz czemu uważasz przenośność za wadę?
Co do pamięci to panowanie nad nią (nawet jeśli nie w 100%) pozwoli zoptymalizować kod i algorytm. Co już chyba jednak jest sensowną zaletą co?
W C# nie da się aż tak bawić. Skomplikowane algorytmy nawet nie wiadomo jak dobrze napisane wykonują się masakrycznie długo. Przy projekcie gdzie wykonywane są liczne obliczenia to jest dużą wadą.
0
polaczek17 napisał(a)
W C# to praktycznie zbiór gotowych funkcji, co przyśpiesza pracę.
Miło, że odróżniasz język programowania od biblioteki klas .NET Frameworka...
polaczek17 napisał(a)
Przenośność to przecież jedna z kluczowych zalet niektórych projektów. Poza tym powiedz czemu uważasz przenośność za wadę?
Nie uważam przenośności za wadę, za wadę uważam przenośność C++. Bez kupy hacków nie da się jej zagwarantować. Praktycznie co kompilator lub/i platforma to inne rozmiary mają typy danych, inaczej się pewne rzeczy 'zależne od implementacji' zachowują. Tak, tak, to wszystko kwestia 'dobrego stylu' i odpowiedniej biblioteki definiującej 'przenośne' typy za nas.
polaczek17 napisał(a)
Co do pamięci to panowanie nad nią (nawet jeśli nie w 100%) pozwoli zoptymalizować kod i algorytm. Co już chyba jednak jest sensowną zaletą co?
Tak krytyczną optymalizację stosuje się może w 1% projektów, prawda? W C++ jest problem żeby zrobić wydajną alokację/dostęp do obiektów tak żeby nie martwić się odpowiedzialnością za zwalnianie, kiedy trudno określić czas życia obiektu. Do tego dochodzą niekiedy referencje cykliczne. Zobacz jak taki boost::shared_ptr obniża wydajność aplikacji. Teoretycznie wiele z tego można naprawić odpowiednim projektem, ale nie wszystko da się przewidzieć. Efekt jest taki, że tylko nieliczne aplikacje w C++ są faktycznie szczelne, nie ciekną, a operacje na pamięci wykonują w sposób faktycznie bezpieczny.
Gdyby przejść całkowicie na wirtualizację (.NET/JVM/wtf) to część braci tworzącej exploity musiałaby chyba zacząć jeść tapety i zagryzać tynkiem ze ścian.
0
polaczek17 napisał(a)
W C# nie da się aż tak bawić. Skomplikowane algorytmy nawet nie wiadomo jak dobrze napisane wykonują się masakrycznie długo. Przy projekcie gdzie wykonywane są liczne obliczenia to jest dużą wadą.
Pokaż te algorytmy.
0
Nie uważam przenośności za wadę, za wadę uważam przenośność C++. Bez kupy hacków nie da się jej zagwarantować. Praktycznie co kompilator lub/i platforma to inne rozmiary mają typy danych, inaczej się pewne rzeczy 'zależne od implementacji' zachowują. Tak, tak, to wszystko kwestia 'dobrego stylu' i odpowiedniej biblioteki definiującej 'przenośne' typy za nas.
Chyba że tak. Zrozumiałem wcześniej, że uważasz przenośność aplikacji za wadę. A przenośność i "odmiany" C++ są faktycznie wkurzające. Są po prostu wadą. Mimo tego, że na dzień dzisiejszy nie ma chyba ŻADNEGO (popularnego) kompilatora zgodnego ze standardem, to te nieścisłości dotyczą raczej drugorzędnych spraw. Różny rozmiar typów ma też miejsce przy np 16bitowym procesorze i przy 32 bitowym. Standard z resztę jeśli się nie mylę nakłada ograniczenia mówiące aby "int" był co najmniej 16-bitowej długości i nie był dłuższy od "long". "long int" nie może być krótszy niż 32 bity, a "short int" nie może być krótszy jak 16 bitów. Także jakieś ramy są i nie jest to aż tak bolesne.
Tak krytyczną optymalizację stosuje się może w 1% projektów, prawda? W C++ jest problem żeby zrobić wydajną alokację/dostęp do obiektów tak żeby nie martwić się odpowiedzialnością za zwalnianie, kiedy trudno określić czas życia obiektu. Do tego dochodzą niekiedy referencje cykliczne. Zobacz jak taki boost::shared_ptr obniża wydajność aplikacji. Teoretycznie wiele z tego można naprawić odpowiednim projektem, ale nie wszystko da się przewidzieć. Efekt jest taki, że tylko nieliczne aplikacje w C++ są faktycznie szczelne, nie ciekną, a operacje na pamięci wykonują w sposób faktycznie bezpieczny.
Pokaż te algorytmy.
I C# zwalnia nas z martwienia się o to. Niekiedy to jest fajne. Ja bardziej miałem na myśli aplikacje, które jednak wymagają wykonywania obliczeń szybko i skutecznie. Takich projektów jest 1%? Z pewnością będą to niskopoziomowe rzeczy, będzie to grafika. Charles Petzold opisał techniki filtracji obrazów w C# techniką najszybszą jaką udało mu się wymyślić. To jest generowaniem kodu w locie. W C# technika ta jest całkiem fajna i łatwa, ale po 1.) nie daje żadnej gwarancji swojej skuteczności. A po 2.) algorytm i tak działał wolno.
Są po prostu aplikacje gdzie C# jest tylko udręką. Są jednak takie zalety jak podałeś. Wszystko zależy od projektu, który się robi.
0
polaczek17 napisał(a)
Charles Petzold opisał techniki filtracji obrazów w C# techniką najszybszą jaką udało mu się wymyślić. To jest generowaniem kodu w locie. W C# technika ta jest całkiem fajna i łatwa, ale po 1.) nie daje żadnej gwarancji swojej skuteczności. A po 2.) algorytm i tak działał wolno.
Serio, chętnie bym to zobaczył. Bo nie widzę powodu, by operacje na blokach pamięci miałyby być znacząco szybsze w C++.
Poza tym, generowanie kodu w locie jest wolne. Coś tu nie tak.
0
Przykład jest w 8 rozdziale książki "Piękny kod". Niestety nie ma CD, a ja nie za bardzo chce przepisywać 2-3 strony kodu :P
0
Poza tym, generowanie kodu w locie jest wolne.
A to niby czemu jest wolne? Przecież nie chodzi o tak skomplikowany kod jak tworzy kompilator. To działana na zasadzie "szablonu", któremu ustawia się parametry a następnie wykonuje bezpośrednio na procesorze. Przynajmniej jeżeli chodzi o C/C++
0
Nawet mocno niedopracowana platforma jaką jest Java nie jest dużo wolniejsza od natywnego C++:
http://shootout.alioth.debian.org/u64q/java.php
Z tym, że to jest gra nie fair, ponieważ alokacje w Javie powodują alokacje w kernelu napisanym w C, tzn jeżeli używamy JRE jako nakładki na Linuksa czy Windowsa to i tak jądro tego systemu musi zaalokować pamięć. Poza tym procesory posiadają sprzętowe jednostki zarządzania pamięcią (MMU), które przyspieszają działanie C++, a zwalniają działanie Javy.
Najlepszym przykładem na to, że kompilacja do kodu natywnego to zło jest sytuacja na rynku procesorów. Wydajność x86 wzrasta generalnie bardzo powoli - x86 jest ograniczane przez wsteczną kompatybilność na poziomie binarnym z bardzo starym kodem. W komórkach i smartfonach króluje ARM, który ma wygrywa na polu wydajność/ wat. GPU z każdą generacją mają inne zestawy i formaty instrukcji, inaczej rozłożone pamięci podręczne itp itd Ogromna dowolność w budowaniu coraz sprytniejszych GPU jest spowodowana tym, że nikt nie kompiluje shaderów do kodu natywnego. Tłumaczenie shaderów do kodu natywnego odbywa się tuż przed wysłaniem ich na GPU - podobnie jak w Javie. Gdybyśmy od powiedzmy dwudziestu lat wszyscy pisali w językach zarządzanych (tzn pod maszyny wirtualne jak JVM czy CLR) to dzisiaj mielibyśmy dużo wydajniejsze procesory. Ponadto optymalizacje w maszynach wirtualnych byłyby dużo skuteczniejsze (włożone zostałoby w to więcej wysiłku).
Ponadto C++ czy C jest szybkie tylko wtedy, gdy kompilujemy jak największą część kodu do jednego pliku wykonywalnego - inaczej kompilator nie może z inlineować funkcji (z osobnych plików wykonywalnych) i pooptymalizować ich dalej. Kod Javowy (czy C#-owy) składa się w tysięcy plików .class - oznacza to gigantyczne możliwości modularyzacji, można sobie podmienić dowolne pliki .class i mamy inaczej działający, ale równie wydajny program. W C++ musielibyśmy utworzyć miliony plików .dll, aby w taki sam sposób mieć możliwość zmiany zachowania aplikacji, co zabiłoby wydajność. Dodatkowo C++ nie może przeprowadzić dynamicznej dewirtualizacji metod i z tego powodu kod czysto OOP w C++ jest nawet wolniejszy niż w Javie.
Jeżeli chodzi o obróbkę grafiki, czy też wszelkich obliczeń typu: http://en.wikipedia.org/wiki/Embarrassingly_parallel należy algorytmy zakodzić na GPGPU np w OpenCLu. OpenCL, jak na normalny język przystało, jest tłumaczony do kodu natywnego tuż przed wykonaniem, znów tak samo jak w Javie. Nie trzeba więc przekompilowywać programu nawet wtedy, gdy w sterownikach (i zawartym w nich kompilatorze) staną się dostępne nowe optymalizacje. Wystarczy zaktualizować sterowniki.
0
Mimo tego, że na dzień dzisiejszy nie ma chyba ŻADNEGO (popularnego) kompilatora zgodnego ze standardem, to te nieścisłości dotyczą raczej drugorzędnych spraw.
Cóż, faktycznie Comeau do najpopularniejszych nie należy, tak samo jak i Intel.
polaczek17 napisał(a)
Standard z resztę jeśli się nie mylę nakłada ograniczenia mówiące aby "int" był co najmniej 16-bitowej długości i nie był dłuższy od "long". "long int" nie może być krótszy niż 32 bity, a "short int" nie może być krótszy jak 16 bitów. Także jakieś ramy są i nie jest to aż tak bolesne.
Generalnie masz rację, ale nie do końca:
Objects declared as characters (char) shall be large enough to store any member of the implementation’s basic character set. If a character from this set is stored in a character object, the integral value of that character object is equal to the value of the single character literal form of that character. It is implementation-defined whether a char object can hold negative values. Characters can be explicitly declared unsigned or signed. Plain char, signed char, and unsigned char are three distinct types. A char, a signed char, and an unsigned char occupy the same amount of storage and have the same align ment requirements (3.9); that is, they have the same object representation. For character types, all bits of the object representation participate in the value representation. For unsigned character types, all possible bit patterns of the value representation represent numbers. These requirements do not hold for other types. In any particular implementation, a plain char object can take on either the same values as a signed char or an unsigned char; which one is implementation-defined.
Także nawet rozmiar char nie jest jakoś sensownie określony (w limits.h są tylko minimalne wartości dla bajtu), bez ciągłego pilnowania (lub wymuszania w ustawieniach kompilatora, a to się ze względu na 'przenośność' zazwyczaj źle kończy) można się łatwo dorobić signed/unsigned mismatch, czasem prowadzącej nawet do powstania podatności w aplikacji. Także czysty char tylko do bezpośrednich operacji na znakach, bez większych numerycznych kombinacji.
There are four signed integer types: “signed char”, “short int”, “int”, and “long int.” In this list, each type provides at least as much storage as those preceding it in the list. Plain ints have the natural size suggested by the architecture of the execution environment 39) ; the other signed integer types are provided to meet special needs.
_____39) that is, large enough to contain any value in the range of INT_MIN and INT_MAX, as defined in the header <climits>.
Sprawa jest o tyle zabawna, że natural size suggested by the architecture of the execution environment powinno oznaczać rozmiar słowa maszynowego, szerokość rejestru, a nie na każdej architekturze i nie wszystkie kompilatory taki rozmiar stosują, przez wzgląd na przenośność właśnie. climits/limits.h określa tylko podstawowe definicje w typie 'nie mniej niż' (Their implementation-delined values shall be equal or greater in magnitude (absolute value) to those shown), pochodzące z ANSI C, do tego dochodzi zależność z cytatu. Jest to jeden z powodów istnienia w boost nagłówka cstdint.hpp, który zapewnia jasno określone rozmiary, na modłę stdint.h z C99, jego lektura jest bardzo pouczająca...
There are three floating point types: float, double, and long double. The type double provides at least as much precision as float, and the type long double provides at least as much precision as double. The set of values of the type float is a subset of the set of values of the type double; the set of values of the type double is a subset of the set of values of the type long double. The value representation of floating-point types is implementation-defined.
Dopiero tutaj zaczyna się zabawa - np. pod Windows uznaje się, że double == long double ze względu na kompatybilność. Efekt jest taki, że naiwnie portowany GCC zasad się nie trzyma i jest miejscami niekompatybilny z systemową biblioteką standardową C. Żeby było zabawniej to z powodu takiej definicji standardu w Qt istnieje obecnie tylko jeden typ zmiennoprzecinkowy, qreal, zazwyczaj aliasujący double.
Ciekawostka co do literałów:
The type of an integer literal depends on its form, value, and suffix. If it is decimal and has no suffix, it has the first of these types in which its value can be represented: int, long int; if the value cannot be represented as a long int, the behavior is undefined. If it is octal or hexadecimal and has no suffix, it has the first of these types in which its value can be represented: int, unsigned int, long int, unsigned long int. If it is suffixed by u or U, its type is the first of these types in which its value can be represented: unsigned int, unsigned long int. If it is suffixed by l or L, its type is the first of these types in which its value can be represented: long int, unsigned long int. If it is suffixed by ul, lu, uL, Lu, Ul, lU, UL, or LU, its type is unsigned long int.
Warto zwrócić tutaj uwagę na traktowanie liczb zapisanych szesnastkowo - mogą być tak signed jak unsigned jeżeli nie mają przyrostka. Przyrostka dla signed oczywiście nie ma. Efekt jest taki, że literałów hex nie można zostawić samych sobie, zależnie od kompilatora i architektury mogą bardzo różne efekty dawać.
O tym, że Qt i kilka innych bibliotek nie korzysta z wyjątków ze względu na różnice pomiędzy kompilatorami (m.in. olewanie standardu czy niepełną implementację) wspominać chyba nie trzeba. Wielokrotnie widziałem na 4p narzekania na ilość aliasów w WINAPI, a wynikają one m.in. z kwestii przenośności C/C++. Windows NT obsługiwał w swojej historii wiele architektur, ostatnio dorzucono ARM, system jest portowany tam, gdzie jest na niego zapotrzebowanie. Bez tak ogromnej warstwy abstrakcji niemożliwym byłoby przekompilowanie na inną architekturę czegokolwiek innego niż hello-world, zapewne z Notatnikiem włącznie. Swoją drogą częstym błędem popełnianym przez 'programistów Windows' jest unikanie typów z rodzaju *_PTR, jak ULONG_PTR, liczb o szerokości wskaźnika.
C++ jest mocno niskopoziomowy, doliczając problemy z wyrównaniem zmiennych/elementów struktur na niektórych architekturach to o prostej przenośności można zwyczajnie pomarzyć. Bez tony dodatkowych typedefów i makrodefinicji (jawnych bądź realizowanych pośrednio - boost, Qt itd.) niczego nie można być pewnym. Najlepszy numer to brak zasad manglowania nazw, każdy kompilator robi to po swojemu, dodatkowo GCC pomiędzy Windowsem a Linuksem nie jest kompatybilne jeżeli chodzi o generowanie nazw z C, słynny '_'. To tyle jeżeli chodzi o bezstresowe przenoszenie kodu i plików obiektów pomiędzy platformami i systemami.
0
Przenosnosc JAVY to mit. Nie wiem nad jakimi projektami pracujecie ale przy wiekszych i bardziej zlozonych projektach przenosnosc po prostu nie dziala. Za kazdym upgradem virtualnej maszyny trzeba przekompilowywac kod, niekiedy trzeba dokonac kilku zmian. Tak ze te wasze twierdzenia ze wystarczy upgradowac vm/drivery/etc zeby program w javie przyspieszyl to sa brednie wyssane z ch..j.. Zreszta nie dziwi mnie to, z moich obserwacji wynika ze 80% programistow java nie wie co tak naprawde robi. Raz nawet byl przypadek ze koles 2 lata pracowal jako programista javy i w momencie kiedy mial do napisania jakis prosty programik w c++ okazalo sie ze tak naprawde to ten kolega nie wie co to jest wskaznik, jak dziala alokacja pamieci itd. itp.
A teraz mozecie juz wyjsc na korytarz i tam sie wymadrzac, tu sie pracuje.
PS.
deus napisał(a)
C++ jest mocno niskopoziomowy
No tak pisanie przy uzyciu takiego Qt to jest niskopoziomowosc jak ch... aaa chwila Qt to przeciez framework... moment moment.... czym bylaby JAVA bez jej frameworka i miliona zaimplementowanych klas?
0
EgonOlsen napisał(a)
No tak pisanie przy uzyciu takiego Qt to jest niskopoziomowosc jak ch...
Zrób coś dla mnie i popisz trochę z użyciem Qt. Framework nie daje wszystkiego, co jest potrzebne do pisania aplikacji, zaś pointerów to tam się wala od cholery. Co z tego, że są zasady przejmowania obiektów na własność, nakaz alokowania pewnych rzeczy na stercie itd? C++ sam w sobie nadal pozostaje niskopoziomowy, no chyba, że dla Ciebie programowanie sprowadza się do zdziedziczenia z QMainWindow, wrzucenia paru layout managerów i buttonów.
0
@egon - są różne rodzaje przenośności, zacznij je rozróżniać. To że trzeba przekompilować klasy jak wyjdzie nowa VM bez zmian w kodzie to jest pryszcz.
Gdyby wystarczyło jedynie przekompilować program w C++, żeby zaczął działać na innym kompilatorze/systemie to był by cud miód i orzeszki. Tak jednak niestety nie jest. Żeby program się w ogóle skompilował trzeba dokonywać zmian w kodzie tudzież rozbijać kod na wersje dla poszczególnych systemów/kompilatorów. Żeby program działał poprawnie po skompilowaniu trzeba dokonywać kolejnych modyfikacji. Przy dużych systemach to jest po prostu syzyfowa robota.
A jeżeli chodzi o programistę Javy, którego opisałeś to tylko źle świadczy o firmie w której pracuje. Przy normalnej rekrutacji na programistę Javy powinny się znaleźć pytania o działanie systemu operacyjnego jak i VM, które odsiały by takich łebków.
0
Ja rozumiem że dla was niskopoziomowosc to zło. Rozumiem tez że nigdy nie udało się wam napisać softu w c/c++ który np. kompilowałby się pod linuxe i windą (chociaż mój obecny projekt kompiluje sie pod lin/win/mac i jeszcze czyms czego nazwy teraz nie pamietam ale soft juz ma ponad 20lat). Rozumiem też że nigdy nie przydarzyło (i prawdowpodobnie się nie przydarzy) się wam pisać jakieś automatyzacji przemyslowej np. takiej jak ta:
Powaznie uwazacie ze jakies jawki sie do tego nadaja? To teraz sami sobie odpowiedzcie na pytanie na co sa przydatne te jawki i inne dotnety.
deus napisał(a)
EgonOlsen napisał(a)
No tak pisanie przy uzyciu takiego Qt to jest niskopoziomowosc jak ch...
Zrób coś dla mnie i popisz trochę z użyciem Qt. Framework nie daje wszystkiego, co jest potrzebne do pisania aplikacji, zaś pointerów to tam się wala od cholery. Co z tego, że są zasady przejmowania obiektów na własność, nakaz alokowania pewnych rzeczy na stercie itd? C++ sam w sobie nadal pozostaje niskopoziomowy, no chyba, że dla Ciebie programowanie sprowadza się do zdziedziczenia z QMainWindow, wrzucenia paru layout managerów i buttonów.
Tak! Zgadles! A na tych buttonach i labelach jest napisane: hello deus, hello deus, hello deus, hello deus, hello deus.....
0
EgonOlsen napisał(a)
Rozumiem tez że nigdy nie udało się wam napisać softu w c/c++ który np. kompilowałby się pod linuxe i windą (chociaż mój obecny projekt kompiluje sie pod lin/win/mac i jeszcze czyms czego nazwy teraz nie pamietam ale soft juz ma ponad 20lat).
Oczywiście cały projekt napisałeś sam przez 20 lat i ta przenośność to wyłącznie Twoja zasługa, prawda? Nikt nie mówi, że się nie da, po prostu zwracamy uwagę, że przenośność jest zależna od cholernej ilości czynników. Im więcej czynników trzeba uwzględnić tym większy jest jej koszt, prawda?
EgonOlsen napisał(a)
To teraz sami sobie odpowiedzcie na pytanie na co sa przydatne te jawki i inne dotnety.
Na to żeby wkurzać Egony zbyt niskopoziomowe na ogarnięcie poprawnego korzystania z GC, refleksji albo abstrakcji funkcji wyższego rzędu, pattern matchingu itd? Słuchaj, czas to pieniądz, sprzęt jest tani, jeżeli coś można zrobić szybciej w bardziej ekspresyjnych i bezpieczniejszych językach programowania zazwyczaj w nich się to robi.
http://web.cecs.pdx.edu/~apt/cs457_2005/hudak-jones.pdf - Egonie, komentuj, byle z sensem.
0
deus napisał(a)
EgonOlsen napisał(a)
To teraz sami sobie odpowiedzcie na pytanie na co sa przydatne te jawki i inne dotnety.
Na to żeby wkurzać Egony zbyt niskopoziomowe na ogarnięcie poprawnego korzystania z GC, refleksji albo abstrakcji funkcji wyższego rzędu, pattern matchingu itd? Słuchaj, czas to pieniądz, sprzęt jest tani, jeżeli coś można zrobić szybciej w bardziej ekspresyjnych i bezpieczniejszych językach programowania zazwyczaj w nich się to robi.
</quote>
I znowu mnie dostales, niestety tylko deusy wiedza co to GC (w sumie dla nich to stworzono, po co pamietac o zaalokowanej pamieci, a moze to jest czasami zbyt trudne zeby po sobie posprzatac?), polimorfirm, interfejsy oraz doskonale potrafia korzystac z wielokrotnego wirtualnego dziedziczenia.
deus napisał(a)
EgonOlsen napisał(a)
Rozumiem tez że nigdy nie udało się wam napisać softu w c/c++ który np. kompilowałby się pod linuxe i windą (chociaż mój obecny projekt kompiluje sie pod lin/win/mac i jeszcze czyms czego nazwy teraz nie pamietam ale soft juz ma ponad 20lat).
Oczywiście cały projekt napisałeś sam przez 20 lat i ta przenośność to wyłącznie Twoja zasługa, prawda?
deusy pisaly, ja tylko poprawiam bugi i pisze sterowniki rotfl
0
Wiesz co Egon? Przypominasz mi jednego analityka pracującego w pewnej poważnej firmie AV, "dla mnie C++ to nie programowanie". Najchętniej bym Was zapoznał, mógłbym zbierać zakłady kto kogo zabije.
Na komentarz co do podlinkowanego dokumentu czekam nadal.
0
Ty mi tez przypominasz jednego mlodego, ambitnego, co to na wszystkim znał sie najlepiej. Tylko ze jak na takiego mistrza zbyt czesto zmienial firmy i zbyt wiele jego projektow ladowalo w koszu. Moze byl nierozumiany. A co do podsunietego artykulu to nie czytalem bo mi sie nie chce, po prostu mi sie nie chce wiec olałem. Sorry.