W dniu 2011-09-05 11:38, Marszalkowski pisze:
>
>
>> A ja masz typy wyliczeniowe, struktury.
> Często robiłem jeden plik inkludowany globalnie z (prawie) wszystkimi:
> typedefs
> const
> enum
> struct
> class
> Nie chcę powiedzieć że używanie globalnie czegoś co jest potrzebne tylko w
> kilku plikach stanowi dobrą metodę. Pierwsza wada to kompilacja wszystkiego
> od nowa - ale kodu miałem z reguły mniej niż 1-2MB i kompilacja szła szybko.
> Podobnie nie miałem problemów z niebezpieczeństwem przypadkowego użycia czegoś,
> co było dostępne. Generalnie - nigdy nie żałowałem że taki projekt zrobiłem.

Moje doświadczenia są dokładnie przeciwne 8-) Zawsze żałowałem, że nie
podzieliłem na czas "The HEADER File", kompilacja wszystkiego zajmowała
zawsze za dużo czasu (szczególnie, gdy kilka razy musiałem zmienić
jedną stałą). A najgorsze było użycie czegoś, co było dostępne, a nie
powinno, oczywiście "na chwilę"...

--
Paweł Kierski
n...@p...net

do góry

On 5-9-2011 10:47, Stachu 'Dozzie' K. wrote:
> On 2011-09-05, Sarr.<s...@g...pl> wrote:
>> On 2-9-2011 22:17, Maciej Sobczak wrote:
>>> On 2 Wrz, 14:04, "Sarr."<s...@g...pl> wrote:
>>>> na tej samej zasadzie mozna by zapytac o kolejnosc sekcji: public,
>>>> protected i private czy tez odwrotnie...
>>>
>>> Znane mi standardy kodowania sugerują najpierw public, potem protected
>>> i na końcu private - ta kolejność wynika z tego, że czytelnik, który
>>> zwykle jest użytkownikiem klasy, najbardziej jest zainteresowany
>>> publicznym interfejsem, więc jest sens go napisać na początku.
>>
>> zapytam tak, czy sa to sztywne standardy kodowania czy nie sa to raczej
>> luzne sugestie na ten temat? nie zawsze czytelnik jest zainteresowany
>> sekcja public,
>
> Ale najczęściej jest. Rzadziej jest zainteresowany sekcją protected,
> czyli dostępną jedynie dla klas pochodnych. Próbujesz na siłę wymyślać
> przykłady.

nie wymyslam, bo akurat z takimi sie spotkalem. dodatkowo, jesli
dziedziczysz z A i B, i virtuale z swoim .h wylistujesz w takiej
kolejnosci, to twoj kolega kodujac podobna klase wylistuje tak jak ty,
dopasowujac sie a nie wymyslajac swoj uklad, dlatego, zeby trzeci kolega
kodujac swoja kalse pol roku pozniej nie musial zastanawiac sie dlaczego
nie ma spojnosci i jak on to powinien zrobic. dlatego stoje na pozycji,
ze czasem lepiej nagiac reguly [ale nie kazdy w swoja strone] niz
sztywno sie ich trzymac.

>>>> a gdzie typedefy w tym
>>>> wszystkim.
>>>
>>> To zależy, czy są publiczne, czy nie, bo patrz wyżej.
>>>
>>>> niekiedy chcac przestrzegac z gory ustalonych regul robi sie
>>>> straszny bajzel w .h.
>>>
>>> Właśnie po to są te reguły, żeby bajzlu nie było.
>>
>> wlasnie z tym standardem robi sie niekiedy niezly bajzel, 3 sekcje,
>> kazda z seria funkcji, typedef'ow, niekiedy dodatkowych struct'ow i
>> enum'ow.
>
> Odłóż apostrof, bo sobie nim oko wybijesz.
> http://poradnia.pwn.pl/lista.php?id=6142

przepraszam, nie uzywam polskiego slownictwa specjalistycznego na
codzien i wydawalo mi sie, ze moj zapis jest czytelny i zrozumialy.
widze, ze na powazniejszy argument zabraklo miejsca ;] kontynuujac
watek, co myslec i public, protected i private dodawanym przed kazda
zmienna [na przyklad w .NET]? ja na przyklad tego nie lubie, ale inni
moga ubostwiac;

>> czasem chcialo by sie miec typedefy razem, enumy i dodatkowe
>> struct'y tez razem. chyba, ze ktos lubi scrollowac mamrtoatac pod nosem
>> 'ten enum w protected to byl gdzies pod ta cala kopa public a przed tymi
>> typedefami z private, nosz szlag, gdziez on jest...' [tego oczywiscie
>> nie traktowac grobowo powaznie, bo jest ctrl+f ;]
>
> Po to są standardy, żeby zawczasu ustalić jak to ma wyglądać i żeby
> programista wiedział czego się spodziewać. Lepiej czasem poprzewijać niż
> za każdym razem się zastanawiać gdzie jest opis struktury danych.

wiem, ze to moze okazac sie punktem zaczepnym do pod-dyskusji ale
niestety nie jest tak, ze zawsze da sie to zawczasu ustalic. co do
opisow, to jest zupelnie osobna historia, jedni twierdza uparcie, ze
wszystko ma byc w .h, bo uzytkownik ma prawo wiedziec wszystko o
interfejsie. inni, ze nie wszystko jest dla uzytkownika a, caly .h jest
nieczytelny a minimalna zmiana w opisie wymusza rekompilacje, wiec
lepiej jest trzymac opisy w .cpp. ale czy nie zaczynamy tym sposobem
czegos w stylu brace-wars?

pozdawiam,
Sarr.

do góry

On 2011-09-05, Sarr. <s...@g...pl> wrote:
> On 5-9-2011 10:47, Stachu 'Dozzie' K. wrote:
>> On 2011-09-05, Sarr.<s...@g...pl> wrote:
>>> On 2-9-2011 22:17, Maciej Sobczak wrote:
>>>> On 2 Wrz, 14:04, "Sarr."<s...@g...pl> wrote:
>>>>> na tej samej zasadzie mozna by zapytac o kolejnosc sekcji: public,
>>>>> protected i private czy tez odwrotnie...
>>>>
>>>> Znane mi standardy kodowania sugerują najpierw public, potem protected
>>>> i na końcu private - ta kolejność wynika z tego, że czytelnik, który
>>>> zwykle jest użytkownikiem klasy, najbardziej jest zainteresowany
>>>> publicznym interfejsem, więc jest sens go napisać na początku.
>>>
>>> zapytam tak, czy sa to sztywne standardy kodowania czy nie sa to raczej
>>> luzne sugestie na ten temat? nie zawsze czytelnik jest zainteresowany
>>> sekcja public,
>>
>> Ale najczęściej jest. Rzadziej jest zainteresowany sekcją protected,
>> czyli dostępną jedynie dla klas pochodnych. Próbujesz na siłę wymyślać
>> przykłady.
>
> nie wymyslam, bo akurat z takimi sie spotkalem.

Wymyślasz na siłę. Więcej ludzi będzie używać twojego modułu niż
rozszerzać go dziedziczeniem, a takich z kolei będzie więcej niż
zmieniających sam moduł. Przynajmniej w większości typowych modułów.

Bardziej się opłaca ułatwić pracę tym pierwszym ludziom, bo będzie ich
najwięcej.

>>>>> a gdzie typedefy w tym
>>>>> wszystkim.
>>>>
>>>> To zależy, czy są publiczne, czy nie, bo patrz wyżej.
>>>>
>>>>> niekiedy chcac przestrzegac z gory ustalonych regul robi sie
>>>>> straszny bajzel w .h.
>>>>
>>>> Właśnie po to są te reguły, żeby bajzlu nie było.
>>>
>>> wlasnie z tym standardem robi sie niekiedy niezly bajzel, 3 sekcje,
>>> kazda z seria funkcji, typedef'ow, niekiedy dodatkowych struct'ow i
>>> enum'ow.
>>
>> Odłóż apostrof, bo sobie nim oko wybijesz.
>> http://poradnia.pwn.pl/lista.php?id=6142
>
> przepraszam, nie uzywam polskiego slownictwa specjalistycznego na
> codzien i wydawalo mi sie, ze moj zapis jest czytelny i zrozumialy.
> widze, ze na powazniejszy argument zabraklo miejsca ;]

Poważniejszym argumentem jest dbałość o zgodność z regułami. Jakoś
większość ludzi których cenię za wiedzę (w tym: wiedzę programistyczną)
dba również o czystość używanego przez nich języka. Jeśli ktoś leje
z góry do dołu na zasady gramatyki czy ortografii, prawdopodobnie będzie
też ignorować dobre praktyki inżynierskie.

>>> czasem chcialo by sie miec typedefy razem, enumy i dodatkowe
>>> struct'y tez razem. chyba, ze ktos lubi scrollowac mamrtoatac pod nosem
>>> 'ten enum w protected to byl gdzies pod ta cala kopa public a przed tymi
>>> typedefami z private, nosz szlag, gdziez on jest...' [tego oczywiscie
>>> nie traktowac grobowo powaznie, bo jest ctrl+f ;]
>>
>> Po to są standardy, żeby zawczasu ustalić jak to ma wyglądać i żeby
>> programista wiedział czego się spodziewać. Lepiej czasem poprzewijać niż
>> za każdym razem się zastanawiać gdzie jest opis struktury danych.
>
> wiem, ze to moze okazac sie punktem zaczepnym do pod-dyskusji ale
> niestety nie jest tak, ze zawsze da sie to zawczasu ustalic.

Oczywiście że nie zawsze się da ustalić wcześniej. Nikt nie mówi że
standardy kodowania są prawdą objawioną raz na zawsze.

--
Secunia non olet.
Stanislaw Klekot

do góry

On Sep 5, 9:43 am, "Sarr." <s...@g...pl> wrote:
> On 2-9-2011 22:17, Maciej Sobczak wrote:
>
> > Właśnie po to są te reguły, żeby bajzlu nie było.
>
> wlasnie z tym standardem robi sie niekiedy niezly bajzel, 3 sekcje,
> kazda z seria funkcji, typedef'ow, niekiedy dodatkowych struct'ow i
> enum'ow.

Wtedy właśnie standard znakomicie działa: pokazuje ci, że
prawdopodobie przekombinowałeś i powinieneś uprościć swoje klasy.

do góry