f...@w...gazeta.pl wrote:

>> gadek-bezsensow jw. ktore niestety marnuja moj czas)
>
> (jestem zly bo wlasnie natracilem i tak kupe czasu na
> bezsensy z wandalami na warsztacie a wnioski znikome )

Jasne, wszyscy, którzy się z tobą nie zgadzają, to wandale i dresy...

--
Gof

do góry

M.M. <m...@W...gazeta.pl> napisał(a):

> profesor fir <f...@g...SKASUJ-TO.pl> napisał(a):
>
> > Czy ktos wykorzystuje jakies ustalone (vel nieustalone)
> > schematy dot nazewnictwa samych plikow z kodem? To w
> > sumie dosyc wazna rzecz... Sa na to jakies reguły?
>
> Gdy pracuję sam, to po każdej zmianie projektu zmieniam
> nazwy plików wiele razy i kombinuję na różne sposoby tak długo
> aż jestem zadowolony. Gdy pracuję w grupie to robię to samo, ale
> wtedy próbuję odgadnąć czy inni będą zadowoleni gdy będą czytali
> mój kod.
>
> Pozdrawiam
> P.S.
> Z powodu takich zmian lubię mieć "globalnego" includa w C++, aby
> nie zmieniać w dziesiątkach plików nazwy inkludowanego pliku. Ale...
> może w środowiskach są dobre narzędzia do tego?
>

no, ja tez nie mam jasnosci w nazewnictwie plikow
(a dorobilem sie tego cholerstwa, tj roznych wydzielonych
plikow .c z roznym kontentem eksperymentalnym ponad sto )



--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

przykladowo ostatnio opracowalem kawalek kodu do
rownoczesnej obslugi dwu gryzoni, jak nazwac to
cholerstwo

side.rawinput.mices.c ?

(nie za bardzo,a z drugiej strony pewna kaskadowa
organizacja w nazwach moglaby sie przydac (nie - wrzucanie
wszystkich plikow na rownych prawach, vel uzywanie folderow
ktore tez chyba mi nie specjalnie pasuje)

--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

ifr <f...@w...gazeta.pl> wrote:

> (nie za bardzo,a z drugiej strony pewna kaskadowa
> organizacja w nazwach moglaby sie przydac (nie - wrzucanie
> wszystkich plikow na rownych prawach, vel uzywanie folderow
> ktore tez chyba mi nie specjalnie pasuje)

Cywilizowany świat używa folderów, od tego one są. Co ci w nich nie pasuje?

--
Gof

do góry

Adam Wysocki <g...@n...invalid> wrote:

> Cywilizowany świat używa folderów, od tego one są. Co ci w nich nie pasuje?

Poza tym nie mices tylko mice.

Lub nawet mouses:

http://alt-usage-english.org/excerpts/fxmouses.html

--
Gof

do góry

Użytkownik " ifr" <f...@W...gazeta.pl> napisał:

> przykladowo ostatnio opracowalem kawalek kodu do
> rownoczesnej obslugi dwu gryzoni, jak nazwac to
> cholerstwo

double.trouble.c-psikpsik

AK

do góry

On 2012-05-28 23:27, M.M. wrote:
> Z powodu takich zmian lubię mieć "globalnego" includa w C++

#include "all.hpp"

To *chyba* wpływa Ci zasadniczo na prędkość kompilacji o ile to nie jest
hello world. Widuje taki kfiatki w projektach opensource, autorzy jednak
zazwyczaj maskują swoje lenistwo za pomocą bardziej śmiesznych argumentów.

> nie zmieniać w dziesiątkach plików nazwy inkludowanego pliku.

No właśnie - jeśli nazwiesz go poprawnie, to istnieje wysoka szansa że
ta "zamiana" to cut/paste w sposób 100% automatyczny na wszystkich
plikach projektu. Nazwij pliki sensownie - a nie będzie bolało.

do góry

Sebastian Biały <h...@p...onet.pl> napisał(a):

> On 2012-05-28 23:27, M.M. wrote:
> > Z powodu takich zmian lubię mieć "globalnego" includa w C++
>
> #include "all.hpp"
Tak, tyle że zwykle używam nazwy
#include "include.h"

> To *chyba* wpływa Ci zasadniczo na prędkość kompilacji o ile to nie jest
> hello world.
Hmmmmm
Jeśli zmieniam nagłówek który jest wcielony w wielu plikach to
i tak i tak kompilacja długo trwa. Jeśli używam nagłówków z jakiś dużych
bibliotek to i tak narzut na czas kompilacji głównie spowodowany
nagłówkami bibliotecznymi a nie moimi. Jeśli nagłówek nie jest często
wcielany, to bez większych oporów usuwam go z globalnych inkludów. Gdy
zmieniam tylko plik źródłowy, to kompilacja może być nawet szybsza,
bo kompilator nie męczy się z wielokrotnym wcielaniem i omijaniem tego
samego nagłówka. Jakby kompilacja trwała zbyt długo to bym nie używał
globalnego inkluda. Może taki problem pojawia się od projektów o
rozmiarze 50MB kodu?


> Widuje taki kfiatki w projektach opensource, autorzy jednak
> zazwyczaj maskują swoje lenistwo za pomocą bardziej śmiesznych argumentów.
Co to za argumenty? Moim nie jest lenistwo.

> No właśnie - jeśli nazwiesz go poprawnie, to istnieje wysoka szansa że
> ta "zamiana" to cut/paste w sposób 100% automatyczny na wszystkich
> plikach projektu. Nazwij pliki sensownie - a nie będzie bolało.
Niby tak, ale jeśli mam dużo małych klas i dość zawiłą strukturę
dziedziczenia/agregowania to jakoś wygodnie mi się patrzy gdy mam
w jednym pliku inkludowane w takiej kolejności w jakiej trzeba.

Ponadto taka wygoda jest potrzebna na początkowym etapie projektu. Gdy
projekt się rozrasta to nazwy są poprawiane rzadziej. Jakby kompilacja
okazała się zbyt długa, to można inkludować tylko tam gdzie potrzeba.
Jednak w moich projektach średnio po 0.5MB - 2.0MB kodu nie dotarłem
nigdy do takiego problemu.

Pozdrawiam


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On 30.05.2012 17:52, Sebastian Biały wrote:
> On 2012-05-28 23:27, M.M. wrote:
>> Z powodu takich zmian lubię mieć "globalnego" includa w C++
>
> #include "all.hpp"
>
> To *chyba* wpływa Ci zasadniczo na prędkość kompilacji o ile to nie jest
> hello world.
A to akurat zależy co zmieniasz w kodzie - jak zrobisz z tego
prekompilowany header to można trochę zaoszczędzić przy zmianach w .cpp,
ale już zmiana w .h skutkuje budowaniem całości ;)

--
Pozdrawiam
Michoo

do góry

On 2012-05-30 23:53, M.M. wrote:
> Jeśli zmieniam nagłówek który jest wcielony w wielu plikach to
> i tak i tak kompilacja długo trwa.

Odcinasz sobie drogą między innymi do ccache i distcc skazując na
przesyłanie dużej ilości plików przez sieć bądź hashowania
niepotrzebnych danych.

> Jeśli używam nagłówków z jakiś dużych
> bibliotek to i tak narzut na czas kompilacji głównie spowodowany
> nagłówkami bibliotecznymi a nie moimi.

Czy każdy plik .c uzywa *wyszystkich* funkcji bibliotecznych? Więc
nieinkluduj skoro zjadają znaczacy czas. jesli autor bibliteki
dostarczył tylko all.h to popełnia szkolny błąd. Nie wszyscy tak robią,
patrz np. boost.

> Jeśli nagłówek nie jest często
> wcielany, to bez większych oporów usuwam go z globalnych inkludów. Gdy
> zmieniam tylko plik źródłowy, to kompilacja może być nawet szybsza,
> bo kompilator nie męczy się z wielokrotnym wcielaniem i omijaniem tego
> samego nagłówka.

Mam wrażenie ze mylisz include.h z sztuczką "precompiled header".

> Jakby kompilacja trwała zbyt długo to bym nie używał
> globalnego inkluda. Może taki problem pojawia się od projektów o
> rozmiarze 50MB kodu?

Taki plik skutecznie blokuje distcc/ccache oraz Incredibuild. Przy czym
nie jest to latwo dostrzec bez większego projektu i też zależy.

>> Widuje taki kfiatki w projektach opensource, autorzy jednak
>> zazwyczaj maskują swoje lenistwo za pomocą bardziej śmiesznych argumentów.
> Co to za argumenty? Moim nie jest lenistwo.

A rózne. Zaczynając od stwierdzenia "no przeciez gdzies musi być using
namespace std" po "to ułatwia debugowanie" i tym podobne bzdury.

> Niby tak, ale jeśli mam dużo małych klas

Czy klikaset klas to wystarczająco dużo? Bo mam, a nie używam all.h.

> w jednym pliku inkludowane w takiej kolejności w jakiej trzeba.

Nie istnieje w ogóle potrzeba inkudowania czegokolwiek poza paroma
wyjątkami:

a) jak po czyms dziedziczysz
b) jak uzywasz czegoś na co nie ma forwarda ( np. enum)
c) jak masz jakies templates które muszą się rozwijać inline
d) jak trzymasz przez wartość
e) i pewno coś zapomniałem

95% kodu nie wymaga inkludowania niczego poza fizycznie uzywanymi typami.

> Ponadto taka wygoda jest potrzebna na początkowym etapie projektu.

To ogromna wygoda. Zmieniasz spację w pliku x i make robi Ci update
wszystkiego. Bajer. Witamy w latach 80-tych.

do góry