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

Offline BipBapBop

  • Użytkownik

# Październik 13, 2013, 20:34:46
Witam. Jestem nowy na forum. Pisze sobie swój mały framework, dzięki któremu będę szybciej tworzył to co potrzebniejsze nie tracąc czasu na ponowne przepisywanie tego samego.

Jednak do tej pory miałem wszystko porozrzucane po jednej przestrzeni nazw (nazwijmy ją) "Framework".

Klasa Window (Tworzenie i Obsługa okna) była jednocześnie obok klas i struktur Matematycznych (Wektory, Macierze i Kwaternion) i wrzucone były tam także klasa RendererDirectX11 (Nazwa sama wskazuje)... Jest tego więcej.

Chciałbym to porozrzucać po niższych przestrzeniach nazw (Framework::Utilities, Framework::Graphic ...)
Jednak w tym momencie albo ja nie doczytałem albo nie wiem jak mam używać czegoś z przestrzeni Utilities będąc w Graphic...

Jedynie co mi przychodzi na myśl to using namespace Utilities; lub using Utilities::KLASA; ale wydaje mi się to dziwne i nie widziałem, aby ktoś tak robił więc nie jest to dobre rozwiązanie (na pewno nie estetyczne)

Kolejne pytanie tyczy się notacji węgierskiej ... nie przywykłem do używania w C++. Tutaj typy są jawne, a jeżeli to i nie pomaga to mamy do dyspozycji IntelliSense itp.. Jedynym dobrym pomysłem jest tutaj zadeklarowanie zmiennej globalnej g_ ....
Czy mam używać w swoim kodzie notacji ? Czy mogę to robić po swojemu.

Pozdrawiam, BipBapBop

Offline Mr. Spam

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

Offline Avaj

  • Użytkownik

# Październik 13, 2013, 20:39:50
Ogólnie ludzie zalecają nie używać notacji węgierskiej w sensie, że doklejasz typy zmiennych do ich nazw. To miało faktycznie może jakiś sens gdy nie było podpowiadania składni, teraz możesz sobie podejrzeć typ zmiennej bez większych problemów. Co do nazewnictwa g_, m_ (dla składowych klas) to według uznania.

Offline Rolek

  • Użytkownik

# Październik 13, 2013, 20:41:17
namespace X
{
 namespace A
 {
  int a;
 }
 namespace B
 {
  int foo()
  {
   return A::a;
  }
 }
}
 
int main()
{
 X::A::a = 0;
 return X::B::foo();
}

Offline BipBapBop

  • Użytkownik

# Październik 13, 2013, 21:31:42
@Rolek
Też tak myślałem, ale to rozwiązanie jest dobre jak mam np. właśnie do wykonania jedną/dwie funkcje. Ale np. Jeżeli korzystam z Macierzy itp. z Framework::Utilities w klasie kamery w Framework::Graphic ... no to tutaj jest tego więcej i czytelność kodu idzie do kąta ... nie ma na to jakiejś uniwersalnej odpowiedzi :D ?

Pytanie mam jeszcze do was małe. Jak to jest z formą prawną pobierania skądś kodu. Np. biorąc kod wskażników (cpp/hpp) z bilbioteki na otwartych źródłach to czy moge zamknąć swoją bilbiotekę bez problemów późniejszych ? Nie wiem czy mnie zrozumieliście ?
« Ostatnia zmiana: Październik 13, 2013, 21:39:16 wysłana przez BipBapBop »

Offline steckel

  • Użytkownik

# Październik 15, 2013, 00:10:26
Ogólnie ludzie zalecają nie używać notacji węgierskiej w sensie, że doklejasz typy zmiennych do ich nazw. To miało faktycznie może jakiś sens gdy nie było podpowiadania składni, teraz możesz sobie podejrzeć typ zmiennej bez większych problemów. Co do nazewnictwa g_, m_ (dla składowych klas) to według uznania.
Jakie są zalety nie używania notacji węgierskiej?

Offline Xirdus

  • Redaktor

# Październik 15, 2013, 00:35:05
@Rolek
Też tak myślałem, ale to rozwiązanie jest dobre jak mam np. właśnie do wykonania jedną/dwie funkcje. Ale np. Jeżeli korzystam z Macierzy itp. z Framework::Utilities w klasie kamery w Framework::Graphic ... no to tutaj jest tego więcej i czytelność kodu idzie do kąta ... nie ma na to jakiejś uniwersalnej odpowiedzi :D ?
Javowcom to nie przeszkadza ;) Zawsze możesz zrobić tak:

namespace A
{

}

namespace B
{
    using namespace A;
}

Pytanie mam jeszcze do was małe. Jak to jest z formą prawną pobierania skądś kodu. Np. biorąc kod wskażników (cpp/hpp) z bilbioteki na otwartych źródłach to czy moge zamknąć swoją bilbiotekę bez problemów późniejszych ? Nie wiem czy mnie zrozumieliście ?
Zależy od licencji.

Jakie są zalety nie używania notacji węgierskiej?
Większa czytelność kodu?

Offline steckel

  • Użytkownik

# Październik 15, 2013, 00:41:17
m_iCountBez patrzenia w deklarację wiem, że jest to składowa klasy typu int. Wiem, że niektóre IDE pokazują te informacje po najechaniu myszą, ale:
-trzeba najechać myszą.
-może długo trwać przy dużym projekcie i niewydajnym komputerze.

Offline Xender

  • Użytkownik

# Październik 15, 2013, 00:51:46
https://en.wikipedia.org/wiki/Hungarian_notation#Systems_vs._Apps_Hungarian

Ogólnie Systems Hungarian powstało przez niezrozumienie oryginalnego whitepaperu. IMHO tylko zaciemnia kod. Natomiast Apps Hungarian jest dla mnie OK.

Offline Xirdus

  • Redaktor

  • +1
# Październik 15, 2013, 01:13:44
m_iCountBez patrzenia w deklarację wiem, że jest to składowa klasy typu int. Wiem, że niektóre IDE pokazują te informacje po najechaniu myszą, ale:
-trzeba najechać myszą.
-może długo trwać przy dużym projekcie i niewydajnym komputerze.
I tak 90% czasu spędzasz nie na pisaniu, tylko myśleniu co napisać. Ta sekunda na najechanie myszką cię nie zbawi (i odbijesz ją sobie kiedy następnym razem będziesz pisał identyfikator tej zmiennej). A co do niewydajnych komputerów: jakbyś nie zauważył, od ponad dziewięciu miesięcy mamy rok 2013.

Offline steckel

  • Użytkownik

# Październik 15, 2013, 01:29:43
Mnie tez jest bliżej do Apps Hungarian, mimo że wcześniej nie słyszałem o takiej notacji. Po prostu dla mnie notacja węgierska to używanie przedrostków, choć może to być niepoprawna definicja.

I tak 90% czasu spędzasz nie na pisaniu, tylko myśleniu co napisać.
Zgadzam się.

Ta sekunda na najechanie myszką cię nie zbawi (i odbijesz ją sobie kiedy następnym razem będziesz pisał identyfikator tej zmiennej).
Nie zbawi mnie, ale też niczego nie wnosi, więc nie ma znaczenia.

A co do niewydajnych komputerów: jakbyś nie zauważył, od ponad dziewięciu miesięcy mamy rok 2013.
Co w związku z tym? Komputery bez upgradów nie stają się lepsze wraz z upływem czasu. Do tego dochodzi jak wielki jest projekt i jak wiele zasobów potrzebuje IDE, by móc od razu wyświetlić informacje o zmiennej. Więc jeżeli nie jesteśmy uzależnieni od tego jak szybko IDE nam podpowie (czyli używamy przedrostków) to uważam to za dobry argument. Tym bardziej, że nie zawsze korzystamy z IDE, które podpowiada (np. Notepad++, czy serwisy typu pastebin.com).

Co do czytelności, która jak na razie jest jedynym argumentem za nie używaniem przedrostków, to uważam, że to jest tak naprawdę kwestia przyzwyczajenia.

Offline Xender

  • Użytkownik

# Październik 15, 2013, 01:54:09
A, odnalazłem link, którego szukałem (obszerniej wyjaśnione Apps vs Systems Hungarian): http://www.joelonsoftware.com/articles/Wrong.html

Offline Xion

  • Redaktor
    • xion.log

# Październik 15, 2013, 11:48:02
Cytuj
Bez patrzenia w deklarację wiem, że jest to składowa klasy typu int.
Rozumiem, że masz też w kodzie liczniki typu string?...

Cytuj
Wiem, że niektóre IDE pokazują te informacje po najechaniu myszą
Każde szanujące się IDE (a nawet wiele edytorów) kolorują pola inaczej niż zmienne lokalne.

Cytuj
-może długo trwać przy dużym projekcie i niewydajnym komputerze.
Jeśli twój komputer ma takie problemy z odwołaniem się do deklaracji pola w tym samym pliku, to nie chcę nawet myśleć, co się dzieje przy próbie zbudowania listy sugestii do autouzupełniania...

Offline Xender

  • Użytkownik

# Październik 15, 2013, 13:07:34
Każde szanujące się IDE (a nawet wiele edytorów) kolorują pola inaczej niż zmienne lokalne.
Ja nigdy chyba takiego bajerka nie wdziałem (albo nie zauważyłem). Przydaje się rzeczywiście?

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. ;)

Offline steckel

  • Użytkownik

# Październik 15, 2013, 13:33:13
A, odnalazłem link, którego szukałem (obszerniej wyjaśnione Apps vs Systems Hungarian): http://www.joelonsoftware.com/articles/Wrong.html
Świetny artykuł! Pozwala lepiej spojżeć na używanie przedrostów i dlaczego są one ważne.

Rozumiem, że masz też w kodzie liczniki typu string?...
Lepszy przykład: mam pole "m_iX" i wiem, że jest to współrzędna wyrażona liczbą całkowitą, a nie np. zmiennoprzecinkową.

Każde szanujące się IDE (a nawet wiele edytorów) kolorują pola inaczej niż zmienne lokalne.
I to znów jest uzaleznione od IDE.

Jeśli twój komputer ma takie problemy z odwołaniem się do deklaracji pola w tym samym pliku, to nie chcę nawet myśleć, co się dzieje przy próbie zbudowania listy sugestii do autouzupełniania...
Jeżeli to jest ten sam plik to nie ma problemu, aczkolwiek mam w zwyczaju rozdzielać definicje od deklaracji.
Natomiast budowanie listy sugestii do autouzupełniania jest faktycznie frustrujące.

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 w sumie na jedno wychodzi jak bym używał przedrostka m_, z tym że jest 1 odwołanie przez wskaźnik mniej.

Offline Liosan

  • Moderator

  • +1
# Październik 15, 2013, 13:47:41
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".

A, odnalazłem link, którego szukałem (obszerniej wyjaśnione Apps vs Systems Hungarian): http://www.joelonsoftware.com/articles/Wrong.html
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

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.

Liosan