-
Data: 2009-05-18 17:15:31
Temat: Re: jak napisać szybki program
Od: "Mateusz Loskot" <m...@l...net> szukaj wiadomości tego autora
[ pokaż wszystkie nagłówki ]"A.L." <a...@a...com> wrote in message
news:ti4315lppo0dg90vvabkugm4fgf1s93mhi@4ax.com...
> On Mon, 18 May 2009 17:28:34 +0100, "Mateusz Loskot"
> <m...@l...net> wrote:
>
>>
>>
>>Wszystko co Kolega pisze jest gleboko sluszne, jednak moim zdaniem
>>stosowanie notacji prefiksowej, zarówno w odniesieniu do
>>typów użytkownika jak i typów wbudowany jest dobrym nawykiem.
>>Oczywiście tam gdzie jest to poprawnie użyte dla danego algorytmu.
>
> Pozwole sie nie zgodzic. Nie ma nic gorszego nie "dobre nawyki".
IMHO, to jest uogólnienie.
> Zwlaszcza nieuzasadnione
Dana jest zmienna
int var = 0;
dalej użyta jako licznik w pętli.
W celu ziększenia wartości var o 1 mamy kilka możliwości,
rozpatrzmy dwie z nich: ++var lub var++.
Którą wersję Kolega by wybrał i jak uzasadniłby wybór?
Ja wybrałbym ++var ponieważ 1) przyzwyczajam się do pre-inkrementacji
dla liczników/indeksów, a to automatyzuje wybób operatora przy zastosowaniu
iteratorów oraz 2) w przypadku gdy zmienię typ zmiennej var z wbudowanego
na własny, nie muszę wyszukiwać i zmieniać użycia operatorów, bo wiem
iż konsekwentnie używałem pre-inkrementacji.
Czy Kolegi zdaniem, nawyki opisane w 1 i 2 są dobre czy "dobre" ?
Jeśli zdaniem Kolego są one "dobre", to proszę o wyjaśnienie dlaczego nie są
dobre.
>>Maciej nie sprecyzował typu dla 'var', więc uznałem to za ogólne
>>zalecenie, kóre dotyczy również operatora inkrementacji dla typów innych
>>niż wbudowane.
>
> Moja reakcja byla dokladnie odwrotna: poniewaz nie sprecyzowal typu
> dla 'var', mogl to byc wbudowany.
Zgoda, kwestia interpretacji. Dlatego dobrze zawsze wyjaśniac propozycje
precyzyjnie.
> Tak na matrginesie, jak ktos potzrebuje ladnej dyskusji nad ++ to
> polecam na pzyklad
>
> http://en.allexperts.com/q/C-1040/Increment-operator
s.htm
Dzięki, zajrzę.
Pozdrawiam
--
Mateusz Loskot, http://mateusz.loskot.net
pl.comp.lang.c FAQ: http://pl.cpp.wikia.com/wiki/FAQ
C++ FAQ: http://parashift.com/c++-faq-lite
Następne wpisy z tego wątku
- 18.05.09 17:35 A.L.
- 18.05.09 19:11 Piotr Kulinski
- 18.05.09 19:34 Boguś
- 18.05.09 19:47 jelen
- 18.05.09 20:44 Maciej Sobczak
- 18.05.09 20:50 A.L.
- 18.05.09 20:53 A.L.
- 18.05.09 20:58 A.L.
- 18.05.09 21:07 jelen
- 18.05.09 21:12 Marteno Rodia
- 18.05.09 21:28 A.L.
- 19.05.09 07:37 Paweł Kierski
- 19.05.09 08:32 Jędrzej Dudkiewicz
- 19.05.09 09:34 Mateusz Loskot
- 19.05.09 09:48 Mateusz Loskot
Najnowsze wątki z tej grupy
- Brednie w wiki - hasło Dehomag
- Perfidne ataki krakerów z KRLD na skrypciarzy JS i Pajton
- Instytut IDEAS może zacząć działać: "Ma to być unikalny w europejskiej skali ośrodek badań nad sztuczną inteligencją."
- Instytut IDEAS może zacząć działać: "Ma to być unikalny w europejskiej skali ośrodek badań nad sztuczną inteligencją."
- Instytut IDEAS może zacząć działać: "Ma to być unikalny w europejskiej skali ośrodek badań nad sztuczną inteligencją."
- U nas propagują modę na SI, a w Chinach naukowcy SI po kolei umierają w wieku 40-50lat
- C++. Podróż Po Języku - komentarz
- "Wuj dobra rada" z KDAB rozważa: Choosing the Right Programming Language for Your Embedded Linux Device
- Nowa ustawa o ochronie praw autorskich - opis problemu i szkic ustawy
- Alg. kompresji LZW
- Popr. 14. Nauka i Praca Programisty C++ w III Rzeczy (pospolitej)
- Arch. Prog. Nieuprzywilejowanych w pełnej wer. na nowej s. WWW energokod.pl
- 7. Raport Totaliztyczny: Sprawa Qt Group wer. 424
- TCL - problem z escape ostatniego \ w nawiasach {}
- Nauka i Praca Programisty C++ w III Rzeczy (pospolitej)
Najnowsze wątki
- 2025-05-03 gazowe kuchnie są znacznie bardziej szkodliwe dla zdrowia, niż dotychczas sądzono
- 2025-05-03 Czyli jednak elektryki są TANIE i powszechnie dostępne dla obywateli
- 2025-05-03 Elektryki do Morskiego Oka do utylizacji
- 2025-05-03 Crash testy na publicznej drodze - 4 BMW zderzone
- 2025-05-03 pojebane Google
- 2025-05-03 Brednie w wiki - hasło Dehomag
- 2025-05-03 gazowe kuchnie są znacznie bardziej szkodliwe dla zdrowia, niż dotychczas sądzono
- 2025-05-03 Chiny => Koordynator Produkcji / Przedstawiciel ds. rozwoju produktu <
- 2025-05-03 Gdańsk => Konsultant wdrożeniowy (systemy controlingowe) <=
- 2025-05-03 Warszawa => Frontend Developer (Angular13+) <=
- 2025-05-02 Gliwice => Business Development Manager - Network and Network Security
- 2025-05-02 Warszawa => Senior Frontend Developer (React + React Native) <=
- 2025-05-02 Polska => Senior Key Account Manager <=
- 2025-05-02 Warszawa => Senior Programmer C <=
- 2025-05-02 Gdańsk => Team Lead Data Engineer (Snowflake) <=