Autor Wątek: [C++] Oddzielanie Klas poprzez Przestrzenie Nazw, Notacje...  (Przeczytany 4595 razy)

Offline Xender

  • Użytkownik

# Październik 15, 2013, 14:26:40
To w sumie na jedno wychodzi jak bym używał przedrostka m_, z tym że jest 1 odwołanie przez wskaźnik mniej.
LOL nope. Skompiluje się dokładnie do tego samego, nie może inaczej. Zawsze, gdy odwołujesz się w metodzie do niestatycznego pola składowego, odwołanie idzie przez this-> - przecież metoda nie weźmie sobie z powietrza, na jakim obiekcie pracuje (za to this jest jej przekazywane przy wywołaniu jako niejawny argument).

Natomiast problem nakroślony przez Joela (columns-rows integer etc) u nas w pracy rozwiązujemy inaczej. Dzięki temu że mamy C++ możemy skonstruować template TypedInteger - czyli silnie typowany int (o zadanej szerokości). Czyli mielibyśmy typy ColumnNumber i RowNumber, które zachowywałyby się tak samo jak inty, oprócz tego że nie da się go zrzutować na gołego inta ani na inne warianty TypedInteger.
Też o czymś takim kiedyś myślałem. Jak z wygodą użytkowania tego?

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline steckel

  • Użytkownik

# Październik 15, 2013, 14:34:30
Osobiście uważam, że kod powinien dać się czytać, subwokalizować, głośno wymawiać, powinno dać się o nim rozmawiać, śledzić go na głos, wygodnei odwoływać się nazw w kodzie. Natomiast mój mózg (a co dopiero aparat gębowy) nie jest w stanie przetworzyć m_iX jako "x", a tym bardziej "lpszSourceName" jako SourceName. Zacinam się przy "lpsz". "lpsz", kurde, to brzmi jakby ktoś skrzyżował węgierskie wymysły z czeskimi półsamogłoskami. "lpsz".
Pierwszy raz się spotykam z tym, że ktoś chce wymawiać kod napisany w C++. Natomiast jeżeli chodzi przetwarzanie mózgu to, tak jak wspominałem wcześniej, uważam, że jest to kwestia przyzwyczajenia. Później takie rzeczy sie odruchowo intepretuje.

Fajna argumentacja w tym artykule. Tylko nie wiem steckel czemu Ci się podoba, skoro w tym artykule jest wylane wiadro pomyj na Twoje stanowisko:P
Przecież to, że artykuł nie zgadza się z moimi przekonaniami nie implikuje tego, że mi się nie spodoba. Ja właśnie dlatego polubiłem ten tekst, bo dał mi nowe spojżenie na używanie przedrostków. I faktycznie więcej sensu jest w nazywaniu przedrostków wg znacznia logicznego zmiennej, a nie dokładnego typu.

Natomiast problem nakroślony przez Joela (columns-rows integer etc) u nas w pracy rozwiązujemy inaczej. Dzięki temu że mamy C++ możemy skonstruować template TypedInteger - czyli silnie typowany int (o zadanej szerokości). Czyli mielibyśmy typy ColumnNumber i RowNumber, które zachowywałyby się tak samo jak inty, oprócz tego że nie da się go zrzutować na gołego inta ani na inne warianty TypedInteger.
Dobry pomysł, ale nie jest zbyt wygodny jak dla mnie.

LOL nope. Skompiluje się dokładnie do tego samego, nie może inaczej. Zawsze, gdy odwołujesz się w metodzie do niestatycznego pola składowego, odwołanie idzie przez this-> - przecież metoda nie weźmie sobie z powietrza, na jakim obiekcie pracuje (za to this jest jej przekazywane przy wywołaniu jako niejawny argument).
W takim razie mój błąd. Dzięki! Zawsze warto wiedzieć więcej.
« Ostatnia zmiana: Październik 15, 2013, 14:38:41 wysłana przez steckel »

Offline Liosan

  • Moderator

# Październik 15, 2013, 14:47:06
Też o czymś takim kiedyś myślałem. Jak z wygodą użytkowania tego?
Spoko, ale bywa irytujące. Zwłaszcza pisanie testów i przerabianie istniejącego kodu z gołych intów na typowane to dwie aktywności przy których wkurza. Tak poza tym to nawet wygodnie, trudniej jest się walnąć wywołując metodę o 6 całkowitoliczbowych parametrach jeśli 2 z nich są typed :)

Liosan

Offline Xion

  • Redaktor
    • xion.log

  • +1
# Październik 15, 2013, 15:34:12
Osobiście inaczej rozwiązywałbym problem metod z 6 parametrami liczbowymi, ale co kto lubi ;-)

Offline steckel

  • Użytkownik

# Październik 15, 2013, 15:42:46
Natomiast problem nakroślony przez Joela (columns-rows integer etc) u nas w pracy rozwiązujemy inaczej. Dzięki temu że mamy C++ możemy skonstruować template TypedInteger - czyli silnie typowany int (o zadanej szerokości). Czyli mielibyśmy typy ColumnNumber i RowNumber, które zachowywałyby się tak samo jak inty, oprócz tego że nie da się go zrzutować na gołego inta ani na inne warianty TypedInteger.
Jak był napisany ten template?
Ja myślałem o tym, żeby opakować sobie int'a w klasę Integer - tak jak jest to w Javie zrobione, a potem poszczególne typy po niej by dziedziczyły.
Inna ciekawa technika:
enum StrongInt { _min = 0, _max = INT_MAX };
« Ostatnia zmiana: Październik 15, 2013, 18:54:53 wysłana przez steckel »

Offline Dab

  • Redaktor
    • blog

# Październik 16, 2013, 11:52:27
Natomiast problem nakroślony przez Joela (columns-rows integer etc) u nas w pracy rozwiązujemy inaczej. Dzięki temu że mamy C++ możemy skonstruować template TypedInteger - czyli silnie typowany int (o zadanej szerokości). Czyli mielibyśmy typy ColumnNumber i RowNumber, które zachowywałyby się tak samo jak inty, oprócz tego że nie da się go zrzutować na gołego inta ani na inne warianty TypedInteger.

Dokładnie. Pomysł z prefiksami ma sens tylko w językach w których nie można definiować własnych typów. Na przykład w shaderach można sobie w ten sposób oznaczać w jakich przestrzeniach są obliczane wektory - pomyłka najczęściej oznacza bardzo upierdliwego buga.

Natomiast w przypadku który jest omawiany w tekście (zabezpieczenie przed XSS) dużo bezpieczniejsze jest po prostu użycie dwóch różnych typów. Gołe dane z formularzy trafiają do aplikacji jako stringi (bo mogą mieć dużo więcej zastosowań niż tylko wyplucie HTMLa), natomiast dopiero przy drukowaniu HTML stringi są odpowiednio formatowane. Ponieważ sytuacja kiedy chcemy wypluć "niebezpiecznego" stringa jest stosunkowo rzadka, to wystarczy dla tych przypadków zastosować dodatkową konwersję.

Co najważniejsze, nie jest to rozwiązanie akademickie, bo stosuje je popularny framework webowy Ruby on Rails. Dane trafiają do aplikacji jako stringi (typ String). Przy drukowaniu następuje konwersja do bezpiecznego HTMLa, przed którą można zabezpieczyć się traktując string funkcją html_safe (np. "foo<br/>bar".html_safe). Wtedy taki string zamienia się w obiekt specjalnej klasy (w tym przypadku ActiveSupport::SafeBuffer).

A jak komuś zależy na rozróżnieniu pól od zmiennych lokalnych w samym tekście, to można odwoływać się do pól zawsze przez this-> - przynajmniej nie nosi to znamion obfuskacji. ;)

To jest dobre z innego powodu - od razu widać gdzie operujemy na danych lokalnych, a gdzie może zmienić się stan obiektu między kolejnymi instrukcjami.

Offline Xender

  • Użytkownik

# Październik 16, 2013, 19:04:40
To jest dobre z innego powodu - od razu widać gdzie operujemy na danych lokalnych, a gdzie może zmienić się stan obiektu między kolejnymi instrukcjami.
Przecież dokładnie o to chodziło również przy używaniu przedrostka m_.