@somekind: nikt nie twierdzi, że Delphi jest cudownym językiem; po prostu co innego fakt, że script kiddies mają tendencję do pisania "wuasnych botuff" do Tibii w Delphi, a co innego, gdy już chodzi o irracjonalny hejt na tę odmianę Pascala.
Ale gdzie w negatywnej opinii jest ten "irracjonalny hejt"? To zjawisko spotyka tutaj raczej @mcodera, tylko dlatego, że wymienił kilka konkretnych wad Delphi. A to, co opisał, czyli np. rozwlekłość składni (sekcja var, pojebane begin i end), nierozróżnianie wielkości liter, różne sposoby wywoływania metod (o ile dobrze zrozumiałem, to jest to syf największy z możliwych), "udziwnione" operatory porównania i przypisania. Takie rzeczy faktycznie nakłaniają do pisania niechlujnego kodu, i utrudniają zmianę języka, bo wymaga ona złamania wielu przyzwyczajeń.
Może i wymienił kilka konkretnych wad Delphi, lecz nie wspomniał o żadnej wadzie składni siplasplasowatej, a takich jest również niemało.
A to, co opisał, czyli np. rozwlekłość składni (sekcja var...
Sekcja var może i faktycznie być czymś dziwnym dla kogoś, kto cały czas pisze w C++, lecz w gruncie rzeczy fajnie jest mieć wszystkie zmienne zadeklarowane w jednym miejscu.
Dzięki temu można uniknąć sytuacji pokroju:
Kopiuj
int main()
{
int i = 1;
{
int i = 2;
}
}
Yup, ten kod jest poprawny i kompiluje się
Chociaż z drugiej strony dzięki deklarowaniu zmiennych stricte tam, gdzie są potrzebne, uniknąć można np.tego:
Kopiuj
Var ListX, ListY, ListZ: TSplittingPlaneList;
Sp : PSplittingPlane;
I, Index : Integer;
Tri : TTriangle;
Axis: Integer = __NOAXIS;
sx, sy, sz, bx, by, bz, _width, _height, _depth, hw, hh, hd, _x, _y, _z: Double;
O, P0, P1, P2, E0, E1, E2: TVector3;
traversal_cost, intersection_cost, best_cost, cost, nosplit_cost, split_position, surface_area, templ, tempr, surface_area_l, surface_area_r: Double;
nl, nr, flag: Integer;
bounds0, bounds1: TBoundingBox;
Jest to fragment mojej implementacji k-d tree z SAH :P
pojebane begin i end
Dlaczego Twoim zdaniem pojebane?
Równie dobrze można by stwierdzić, że "pojebane" jest mało czytelne rozwiązanie z C++, czyli klamerki.
nierozróżnianie wielkości liter
W tym nie widzę żadnej wady. A może to właśnie wadą jest, że C++ nie rozróżnia wielkości liter?
różne sposoby wywoływania metod
Są tylko dwie metody (z nawiasami oraz bez) i naprawdę nie jest to syf największy z możliwych.
Nikt przecież nie zabrania Ci wszędzie pisać (); notacja beznawiasowa to tylko ułatwienie.
Ja mógłbym natomiast powiedzieć, że "wadą" C++ jest różny wybór przestrzeni nazw:
Kopiuj
using namespace foo;
using foo::xyz;
foo::
Tylko czy naprawdę jest to wada? W rzeczywistości to przecież ułatwia pisanie kodu.
Podobnie ułatwia notacja beznawiasowa.
"udziwnione" operatory porównania i przypisania
Co jest w nich dziwnego?
= to porównanie
:= to przypisanie
Jest to logiczne i zrozumiałe dla każdego, kto miał z tym językiem kontakt na przynajmniej parę dni.
Natomiast można by powiedzieć, że w C++ operator przypisania jest 'dziwny':
Kopiuj
int a, b, c;
a = b = c;
Co akurat ma swoje zalety (aka inicjacja wielu zmiennych na raz), lecz u początkujących może spowodować drobny mindfuck.
Takie rzeczy faktycznie nakłaniają do pisania niechlujnego kodu
Ale klamerki i makra z C++ oraz kompilatory, które bez specjalnych przełączników nie trzymają się w 100% standardu* to zachęcają do pisania poprawnego kodu [rotfl]
Kopiuj
#include <iostream>
#define r return
#define HEX__(n) 0x##n##LU
#define c std::cout
#define u__(x) ((x&0x0000000FLU)?1:0)+((x&0x000000F0LU)?2:0)+((x&0x00000F00LU)?4:0)+((x&0x0000F000LU)?8:0)+((x&0x000F0000LU)?16:0)+((x&0x00F00000LU)?32:0)+((x&0x0F000000LU)?64:0)+((x&0xF0000000LU)?128:0)
#define t int
#define l for
#define u(d) ((unsigned char)u__(HEX__(d)))
#define $ unsigned t
#define n unsigned char
t main(){$ __[]={u(1101000),u(1101011),u(1111111),u(10000111),u(10001101),u(10100100)};l($ _=0;_<u(110);_++)c<<[_]($ $$)->n{r(n)$$-10*_;}(__[_]);r 0;}
Ten kod powyżej oczywiście wyświetla słowo hakier w konsoli, co widać na pierwszy rzut oka, czyż nie?**
Ach, no i to piękne deklarowanie wyrażeń lambda w C++!
```cpp
[]()->int{}
```
i utrudniają zmianę języka, bo wymaga ona złamania wielu przyzwyczajeń.
Och, zapamiętanie, że w C++ porównuje się poprzez ==, a nie = jest niewątpliwie ciężką zmianą, współczuję wszystkim, którzy borykają się z syndromem Pascalowego porównania [*]
Może jestem dziwny, ale jak zaczynałem uczyć się C++, to ten błąd popełniałem przez... 4 godziny? Potem się przyzwyczaiłem i teraz już właściwie zawsze piszę == (jeżeli mowa o składni C-podobnej) oraz =, jeżeli mowa o Pascalowo-podobnych językach.
`*` np.:
```cpp
int len;
cin >> len;
char tab[len];
```
`**` oczywiście nikt takiego kodu zazwyczaj nie pisze - podałem jedynie przykład ukazujący, że czytelność języka nie zależy od składni (no, chyba, że mowa np.o Pythonie, ale pomijając języki z narzuconym formatowaniem kodu), tylko od programisty. Mówienie, że istnienie "begin" oraz "end" nakłania do pisania niechlujnego kodu to bullshit. Prędzej napiszesz coś nieczytelnego w C++, niżeli Pascalu.
