nazewnictwo plikow z kodem

[profesor fir]

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?


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

[Grzegorz Niemirowski]

profesor fir <f...@gazeta.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?

Najlepiej na początk nazwy każdego pliku wstawić słowo "profesor".

--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 0 days, 13 hours, 3 minutes and 14 seconds

[f...@wytnij.gazeta.pl]

Grzegorz Niemirowski <gnthe...@poczta.onet.pl> napisał(a):

> profesor fir <f...@gazeta.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?
>
> Najlepiej na początk nazwy każdego pliku wstawić słowo "profesor".
>

a cos mądrzejszego? (dwa dni i juz zdarzylem zapomniec ze
niektorym tylko glupota w glowie, nie mam tyle czasu by wdawac
sie w takie gadki bo mam troche roboty do zrobienia)

[t.o.]

Użytkownik <f...@WYTNIJ.gazeta.pl> napisał w wiadomości
news:jq0odd$d3b$1...@inews.gazeta.pl...

> Grzegorz Niemirowski <gnthe...@poczta.onet.pl> napisał(a):
>
>> profesor fir <f...@gazeta.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?
>>
>> Najlepiej na początk nazwy każdego pliku wstawić słowo "profesor".
>>
>
> a cos mądrzejszego? (dwa dni i juz zdarzylem zapomniec ze
> niektorym tylko glupota w glowie, nie mam tyle czasu by wdawac
> sie w takie gadki bo mam troche roboty do zrobienia)
>
>

Ty nie masz żadnej roboty do zrobienia. Spokojnie można postawić taką tezę
po pytaniach, które zadajesz na grupie. To jest właśnie jedno z nich.
A ze jesteś porządnym trolem, więc czasami nawet przyjemnie się Ciebie
czyta, no może z wyjątkiem przynudzania o chorobach, które Ciebie trapią.


Pozdrawiam
tx

[f...@wytnij.gazeta.pl]

t.o. <rwrewerfd...@wp.pl> napisał(a):

przed chwila napisalem ze nie mam czasu wlasnie na tego
typu gadki-bezsensy,

co do roboty to zalezy jak rozumiec 'robote do zrobienia', -
mowienie o czyms z sensem (np o nazewnictwie plikow)
i przy okazji zglebianie tematu to dla mnie jest robienie
pewnej roboty (bo na tym mi zalezy dotyczy to programowania
i jest to rozwojowe w przeciwienstwie wlasnie do
gadek-bezsensow jw. ktore niestety marnuja moj czas)

[M.M.]

profesor fir <f...@gazeta.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?

[AK]

Użytkownik "Grzegorz Niemirowski" <gnthe...@poczta.onet.pl> napisał:

> Najlepiej na początk nazwy każdego pliku wstawić słowo "profesor".

Za długie.
Proponuję mz...

AK

[f...@wytnij.gazeta.pl]

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

[Artur M. Piwko]

In the darkest hour on Mon, 28 May 2012 22:32:10 +0200,
Grzegorz Niemirowski <gnthe...@poczta.onet.pl> screamed:

>> 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?
>
> Najlepiej na początk nazwy każdego pliku wstawić słowo "profesor".
>

Jest już nowsza, lepsza konwencja. Pliki pod względem czasu utworzenia
zapisujemy następująco:

" .c"
" .c"
" .c"
" .c"
itd.

--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:230B ]
[ 08:39:31 user up 13183 days, 20:34, 1 user, load average: 0.94, 0.04, 0.54 ]

I quit flying years ago. I don't want to die with tourists.

[f...@wytnij.gazeta.pl]

M.M. <mari...@WYTNIJ.gazeta.pl> napisał(a):

> profesor fir <f...@gazeta.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 )

[ifr]

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/

[Adam Wysocki]

ifr <f...@wytnij.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

[Adam Wysocki]

f...@wytnij.gazeta.pl wrote:

> co do roboty to zalezy jak rozumiec 'robote do zrobienia', -
> mowienie o czyms z sensem (np o nazewnictwie plikow)
> i przy okazji zglebianie tematu to dla mnie jest robienie
> pewnej roboty

Masz za dużo wolnego czasu. Pracujesz gdzieś zarobkowo?

--
Gof

[Adam Wysocki]

f...@wytnij.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

[Adam Wysocki]

Adam Wysocki <gophi.at.c...@nospam.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

[AK]

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

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

double.trouble.c-psikpsik

AK

[Sebastian Biały]

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.

[M.M.]

Sebastian Biały <he...@poczta.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

[Michoo]

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

[Sebastian Biały]

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.

[M.M.]

Sebastian Bia�y <he...@poczta.onet.pl> napisa�(a):

> 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.
[ciach]
> To ogromna wygoda. Zmieniasz spacjďż˝ w pliku x i make robi Ci update

> wszystkiego. Bajer. Witamy w latach 80-tych.

To jest wszystko racja, ale dlaczego mam si� stara� skr�ci� czas
kompilacji r�wny 30 sekund do 25 sekund? Cz�sto i tak potrzebuj�
2 minuty aby si� zastanowi� przed napisaniem kolejnego kawa�ka.
Tak na oko to uwiera�a mnie kompilacja dopiero w okolicach 2 minut i
dopiero wtedy zaczyna�em kombinowa�.

Pozdrawiam



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

[Sebastian Biały]

On 2012-05-31 00:39, M.M. wrote:
> To jest wszystko racja, ale dlaczego mam się starać skrócić czas
> kompilacji równy 30 sekund do 25 sekund?

Dlatego pytam o helloworldy. Tam sobie mozna psuc do woli.

> Często i tak potrzebuję
> 2 minuty aby się zastanowić przed napisaniem kolejnego kawałka.

Kompilacje wykonuje się żadko. Ale jak się wykonuje np. w celu
puszczenia unit-testów a ta cholera każe mi czekać 2 minuty to bym ubił.

> Tak na oko to uwierała mnie kompilacja dopiero w okolicach 2 minut i
> dopiero wtedy zaczynałem kombinować.

Kompilacja powinna trwać 0 sekund. Nieosiagalne, ale kilka, poprzez nie
uzywanie all.h, da sie osiągnąć w całkiem sporych projektach. Kwestia
higieny. Inkludowanie all.h do higienicznych nie należy.

Uzyskanie któtkich cykli zmiana-kompilacja-debug jest bardzo ważna dla
komfortu pracy. Te twoje 30 sekund jest zdecydowanie upierdliwe.

[M.M.]

Sebastian Biały <he...@poczta.onet.pl> napisał(a):

Jeśli hello worldy kompilują się 30 sekund to trzeba zacząć od zmiany
maszyny żeby poprawić komfort pracy :)

Mówię o czasie średnim. Gdy jestem na etapie definiowania interfejsów
to oszczędzam czas przez globalny inklud - nie uganiam się co chwilę po
30tu plikach po każdej zmianie. Gdy jestem na etapie implementowania
funkcjonalności to zwykle zmienia się plik źródłowy a nie nagłówkowy i
kompilacja dużo nie spowalnia z powodu globalnego inkludu.

Poza tym taki qtcreator właśnie w tej chwili i tak nie umiem automatycznie
wygenerować zależności i choć w obecnym projekcie nie mam globalnego
inkludu to muszę robić rebuild albo se ręcznie napisać make...

Pozdrawiam



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

[M.M.]

Sebastian Biały <he...@poczta.onet.pl> napisał(a):

Właśnie zmierzyłem.
Środowisko: linux/qtcreator/i3/jakiś-tani-dysk-2.5cala
Projekt: 44 pliki (h i cpp) łącznie 440kb kodu
Nagłówki biblioteczne: trochę z core qt
Czas rebuild-all z opcją -O3 7 sekund.

To co piszesz ma znaczenie przy projektach zdecydowanie powyżej 2MB kodu.

Pozdrawiam







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

[Sebastian Biały]

On 2012-05-31 01:13, M.M. wrote:
> To co piszesz ma znaczenie przy projektach zdecydowanie powyżej 2MB kodu.

Cały czas pytam o helloworldy. Dla nich nie ma znaczenia jak bardzo
spieprzysz.

[Michoo]

On 31.05.2012 01:13, M.M. wrote:
> Właśnie zmierzyłem.
> Środowisko: linux/qtcreator/i3/jakiś-tani-dysk-2.5cala
> Projekt: 44 pliki (h i cpp) łącznie 440kb kodu
> Nagłówki biblioteczne: trochę z core qt

Akurat QT ma całkiem sensownie rozbite nagłówki na forward deklaracje w
głównym i deklaracje dopiero w odpowiednim miejscu.

> Czas rebuild-all z opcją -O3 7 sekund.

Gratuluję. Ja się ostatnio cieszyłem jak na nowym core i5 projekt zaczął
się budować 5 minut zamiast 40.

>
> To co piszesz ma znaczenie przy projektach zdecydowanie powyżej 2MB kodu.
>

Poużywaj trochę bardziej zaawansowany boost ;)
--
Pozdrawiam
Michoo

[Sebastian Biały]

On 2012-05-31 01:01, M.M. wrote:
> Poza tym taki qtcreator właśnie w tej chwili i tak nie umiem automatycznie
> wygenerować zależności

qtcreator nie używa -MM czy czegoś podobnego do make?

> albo se ręcznie napisać make...

Jesli wiesz co robisz to zazwyczaj wychodzi to na zdrowie.

[M.M.]

Michoo <micho...@vp.pl> napisał(a):

> On 31.05.2012 01:13, M.M. wrote:
> > Właśnie zmierzyłem.
> > Środowisko: linux/qtcreator/i3/jakiś-tani-dysk-2.5cala
> > Projekt: 44 pliki (h i cpp) łącznie 440kb kodu
> > Nagłówki biblioteczne: trochę z core qt
> Akurat QT ma całkiem sensownie rozbite nagłówki na forward deklaracje w
> głównym i deklaracje dopiero w odpowiednim miejscu.
>
> > Czas rebuild-all z opcją -O3 7 sekund.
> Gratuluję. Ja się ostatnio cieszyłem jak na nowym core i5 projekt zaczął
> się budować 5 minut zamiast 40.

Hmmm
440KB / 7s = x / (40*60s)
440KB / 7s * 40 * 60s = x
x = 150MB

Jeśli kompilowałeś projekt o rozmiarze 150MB to cóż...

[M.M.]

Sebastian Biały <he...@poczta.onet.pl> napisał(a):

Po co więc używać określenia 'spieprzenie' skoro jak sam przyznajesz to
nie ma znaczenia? Poza tym program o rozmiarze 2MB, zwłaszcza gdy
jest porządnie zaprojektowany, to nie taki hello world, może już robić
coś całkiem pożytecznego.

[fir]

M.M. <mari...@WYTNIJ.gazeta.pl> napisał(a):

> Michoo <micho...@vp.pl> napisał(a):
>
> > On 31.05.2012 01:13, M.M. wrote:
> > > Właśnie zmierzyłem.
> > > Środowisko: linux/qtcreator/i3/jakiś-tani-dysk-2.5cala
> > > Projekt: 44 pliki (h i cpp) łącznie 440kb kodu
> > > Nagłówki biblioteczne: trochę z core qt
> > Akurat QT ma całkiem sensownie rozbite nagłówki na forward deklaracje w
> > głównym i deklaracje dopiero w odpowiednim miejscu.
> >
> > > Czas rebuild-all z opcją -O3 7 sekund.
> > Gratuluję. Ja się ostatnio cieszyłem jak na nowym core i5 projekt zaczął
> > się budować 5 minut zamiast 40.
>
> Hmmm
> 440KB / 7s = x / (40*60s)
> 440KB / 7s * 40 * 60s = x
> x = 150MB
>
> Jeśli kompilowałeś projekt o rozmiarze 150MB to cóż...
>

na warsztacie byla kiedys dyskusja o unity buildach, i raczej
tam przewazala opinia ze to powoduje przyspieszenie ;-)

cytat z jednej stronki:

So after all that, what kind of improvements should expect to find? Well let
me give you a few stats. When the UB was implemented at the game company I
worked for, the build time dropped from 55 minutes to just over 6 minutes.
When I implemented UB in a previous job the build time dropped from 10
minutes to less than 3 minutes. When I put them in place at home the build
times dropped on average by 60%.

ja mam 600k kodu 166 plikow .c i czas kompilacji okolo 2-3 s

aczkolwiek nazwa include.c mi sie nie podoba ja mam main.c


#include <windows.h>
#include <psapi.h> // dla proces memory info
#include <math.h>
#include <stdio.h>
#include <gl\gl.h>
#include <gl\glu.h>
#include <winsock.h>

#include ".lib.utils.tiny.c"
#include ".side.log.c"
#include ".side.qpc.c"
#include ".side.info.c"

#include ".side.rawinput.c"
#include ".side.winsock.server.c"
#include ".side.winsock.client.c"

#include ".side.audio.c"


#include ".draw.blit.c"
#include ".draw.prymitives.c"
#include ".draw.sprites.c"

/*
wiekszosc skipped
*/



#include ".loop.hud.c"
#include ".loop.tests.c"
#include ".loop.c"


#include ".wnd.events.c"
#include ".wnd.idle.c"
#include ".wnd.proc.c"
#include ".wnd.main.c"

to sa jedyen includy reszta projektu to czyste pliki .c
(nazewnictwo nie jest za dobre ale kropka na poczatku chcialem
odroznic pliki frameworka od samych plikow gry bez kropki

[f...@wytnij.gazeta.pl]

fir <f...@WYTNIJ.gazeta.pl> napisaďż˝(a):

> M.M. <mari...@WYTNIJ.gazeta.pl> napisaďż˝(a):
>
> > Michoo <micho...@vp.pl> napisaďż˝(a):

> >
> > > On 31.05.2012 01:13, M.M. wrote:

> > > > W�a�nie zmierzy�em.
> > > > �rodowisko: linux/qtcreator/i3/jaki�-tani-dysk-2.5cala
> > > > Projekt: 44 pliki (h i cpp) ��cznie 440kb kodu
> > > > Nag��wki biblioteczne: troch� z core qt
> > > Akurat QT ma ca�kiem sensownie rozbite nag��wki na forward deklaracje w
> > > g��wnym i deklaracje dopiero w odpowiednim miejscu.
> > >
> > > > Czas rebuild-all z opcjďż˝ -O3 7 sekund.
> > > Gratuluj�. Ja si� ostatnio cieszy�em jak na nowym core i5 projekt
zacz��
> > > siďż˝ budowaďż˝ 5 minut zamiast 40.

> >
> > Hmmm
> > 440KB / 7s = x / (40*60s)
> > 440KB / 7s * 40 * 60s = x
> > x = 150MB
> >

> > Je�li kompilowa�e� projekt o rozmiarze 150MB to c�...

chyba je przerobie (nazewnictwo plikow) ale na raqzie nie mam
pomyslu - jak ktos ma propozycje to moze podac jak wg niego
lepiej ponazywac pliki

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

[Edek Pienkowski]

Dnia Thu, 31 May 2012 00:03:50 +0000, M.M. napisal:

> Michoo <micho...@vp.pl> napisał(a):
>
>> On 31.05.2012 01:13, M.M. wrote:
>> > Właśnie zmierzyłem.
>> > Środowisko: linux/qtcreator/i3/jakiś-tani-dysk-2.5cala Projekt: 44
>> > pliki (h i cpp) łącznie 440kb kodu Nagłówki biblioteczne: trochę z
>> > core qt
>> Akurat QT ma całkiem sensownie rozbite nagłówki na forward deklaracje w
>> głównym i deklaracje dopiero w odpowiednim miejscu.
>>
>> > Czas rebuild-all z opcją -O3 7 sekund.
>> Gratuluję. Ja się ostatnio cieszyłem jak na nowym core i5 projekt
>> zaczął się budować 5 minut zamiast 40.
>
> Hmmm
> 440KB / 7s = x / (40*60s)
> 440KB / 7s * 40 * 60s = x
> x = 150MB
>
> Jeśli kompilowałeś projekt o rozmiarze 150MB to cóż...

Michoo już pisał o tym, że czas kompilacji zależy od kodu.
Mam drobną bibliotekę, która kompiluje się w mniej więcej 7s,
a ma w sumie tylko kilkaset linii na pewno nie kilkaset KB.
Za to wciąga sporo bibliotek w tym z boosta.

Edek

[fir]

>
> So after all that, what kind of improvements should expect to find? Well
let
> me give you a few stats. When the UB was implemented at the game company I
> worked for, the build time dropped from 55 minutes to just over 6 minutes.
> When I implemented UB in a previous job the build time dropped from 10
> minutes to less than 3 minutes. When I put them in place at home the build
> times dropped on average by 60%.
>

z tego jak rozumiem tamtejsze wytlumaczenie to brzmi ono mw
tak ze 'otwarc (otworzen) plikow jest tyle ile dyrektyw include' (?)
tj o ile mam 200 plikow i inkluduje je w postaci listy
to mam po prostu dwiescie otwarc plikow, natomiast jak robie z
tego 'rozgalez' (co do ktorego ja nie mam specjalnego
wyobrazenia) i mam sumarycznie 1000 dyrektyw inklude to mam
1000 otwarc plikow - aczkolwiek to jest chyba niespecjalnie
kompletne wytlumaczenie, trzebaby wiedziec dokladnie jak
dziala kompilator i co dokladnie sie tam dzieje

[Roman W]

On Wednesday, May 30, 2012 11:39:45 PM UTC+1, M.M. wrote:

> To jest wszystko racja, ale dlaczego mam si� stara� skr�ci� czas
> kompilacji r�wny 30 sekund do 25 sekund? Cz�sto i tak potrzebuj�
> 2 minuty aby si� zastanowi� przed napisaniem kolejnego kawa�ka.
> Tak na oko to uwiera�a mnie kompilacja dopiero w okolicach 2 minut i
> dopiero wtedy zaczyna�em kombinowa�.

Ale czasy kompilacji moga byc duzo wieksze. Moj projekt w pracy kompiluje sie ok. 10 minut, i to poprzez Incredibuild, rozdzielony na nascie build serwerow.

RW

[M.M.]

Edek Pienkowski <edek.pi...@gmail.com> napisał(a):

> Dnia Thu, 31 May 2012 00:03:50 +0000, M.M. napisal:
>

> > Michoo <micho...@vp.pl> napisaĹ (a):

> >
> >> On 31.05.2012 01:13, M.M. wrote:

> >> > WĹ aĹ nie zmierzyĹ em.
> >> > Ĺ rodowisko: linux/qtcreator/i3/jakiĹ -tani-dysk-2.5cala Projekt: 44
> >> > pliki (h i cpp) Ĺ Ä cznie 440kb kodu NagĹ Ăłwki biblioteczne: trochÄ z
> >> > core qt
> >> Akurat QT ma caĹ kiem sensownie rozbite nagĹ Ăłwki na forward deklaracje w
> >> gĹ Ăłwnym i deklaracje dopiero w odpowiednim miejscu.
> >>
> >> > Czas rebuild-all z opcjÄ -O3 7 sekund.
> >> GratulujÄ . Ja siÄ ostatnio cieszyĹ em jak na nowym core i5 projekt
> >> zaczÄ Ĺ siÄ budowaÄ 5 minut zamiast 40.

> >
> > Hmmm
> > 440KB / 7s = x / (40*60s)
> > 440KB / 7s * 40 * 60s = x
> > x = 150MB
> >

> > JeŠli kompilowaŠeŠprojekt o rozmiarze 150MB to cóş...
>
> Michoo juĹź pisaĹ o tym, Ĺźe czas kompilacji zaleĹźy od kodu.
> Mam drobnÄ bibliotekÄ , ktĂłra kompiluje siÄ w mniej wiÄ cej 7s,

> a ma w sumie tylko kilkaset linii na pewno nie kilkaset KB.

> Za to wciÄ ga sporo bibliotek w tym z boosta.
No wiadomo. Zawsze templates kompilowały się wolno.

[Remek]

Użytkownik "profesor fir" napisał:

> 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?

Jakim kodem? Bo mnie przychodzi na myśl pin kod. O to chodzi?

Remek

[Artur M. Piwko]

In the darkest hour on Thu, 31 May 2012 00:03:50 +0000 (UTC),
M.M. <mari...@WYTNIJ.gazeta.pl> screamed:

>> > Właśnie zmierzyłem.
>> > Środowisko: linux/qtcreator/i3/jakiś-tani-dysk-2.5cala
>> > Projekt: 44 pliki (h i cpp) łącznie 440kb kodu
>> > Nagłówki biblioteczne: trochę z core qt
>> Akurat QT ma całkiem sensownie rozbite nagłówki na forward deklaracje w
>> głównym i deklaracje dopiero w odpowiednim miejscu.
>>
>> > Czas rebuild-all z opcją -O3 7 sekund.
>> Gratuluję. Ja się ostatnio cieszyłem jak na nowym core i5 projekt zaczął
>> się budować 5 minut zamiast 40.
>
> Hmmm
> 440KB / 7s = x / (40*60s)
> 440KB / 7s * 40 * 60s = x
> x = 150MB
>
> Jeśli kompilowałeś projekt o rozmiarze 150MB to cóż...
>

Zakładasz, że każdy KB kodu, niezależnie od jego zawartości kompiluje
się tak samo długo. To tak jakby za pomocą wagi malucha w kg/cm³ przeliczać
wagę Hummera.

--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:232B ]
[ 13:27:53 user up 13185 days, 1:22, 1 user, load average: 0.99, 0.18, 0.35 ]

Money is just the poor man's credit card. -- Marshall McLuhan

[Michoo]

On 31.05.2012 02:03, M.M. wrote:
> Michoo<micho...@vp.pl> napisał(a):

>>> Czas rebuild-all z opcją -O3 7 sekund.
>> Gratuluję. Ja się ostatnio cieszyłem jak na nowym core i5 projekt zaczął
>> się budować 5 minut zamiast 40.
>
> Hmmm
> 440KB / 7s = x / (40*60s)
> 440KB / 7s * 40 * 60s = x
> x = 150MB
>
> Jeśli kompilowałeś projekt o rozmiarze 150MB to cóż...

22kloc, 651686 bajtów. Ale do tego dochodzi boost i inne biblioteki,
więc możliwe, że sumarycznie kompilator ma coś koło tego.

--
Pozdrawiam
Michoo

[Sebastian Biały]

On 2012-05-31 02:13, M.M. wrote:
>> On 2012-05-31 01:13, M.M. wrote:
>>> To co piszesz ma znaczenie przy projektach zdecydowanie powyżej 2MB kodu.
>> Cały czas pytam o helloworldy. Dla nich nie ma znaczenia jak bardzo
>> spieprzysz.
> Po co więc używać określenia 'spieprzenie' skoro jak sam przyznajesz to
> nie ma znaczenia?

Możesz spieprzyć bez skutków znaczacych. Ale to dalej spieprzenie. Nie
zachowanie higieny/dyscypliny w małym projekcie powoduje ze to lenistwo
rozpływa się na większe projekty. Wiem bo widzę.

> Poza tym program o rozmiarze 2MB, zwłaszcza gdy
> jest porządnie zaprojektowany, to nie taki hello world, może już robić
> coś całkiem pożytecznego.

To dalej maleństwo.

[M.M.]

Artur M. Piwko <milusi.p...@buziaczek.pl> napisał(a):

> Zakładasz, że każdy KB kodu, niezależnie od jego zawartości kompiluje

> się tak samo długo. To tak jakby za pomocą wagi malucha w kg/cm? przeliczać
> wagę Hummera.
To Ty zakładasz że ja coś takiego zakładam. Tymczasem moje założenie
było inne. Założyłem że próbka kodu jest reprezentatywna i wystarczy
do oszacowania.

[M.M.]

Sebastian Biały <he...@poczta.onet.pl> napisał(a):

> On 2012-05-31 02:13, M.M. wrote:
> >> On 2012-05-31 01:13, M.M. wrote:
> >>> To co piszesz ma znaczenie przy projektach zdecydowanie powyżej 2MB kodu.
> >> Cały czas pytam o helloworldy. Dla nich nie ma znaczenia jak bardzo
> >> spieprzysz.
> > Po co więc używać określenia 'spieprzenie' skoro jak sam przyznajesz to
> > nie ma znaczenia?
>
> Możesz spieprzyć bez skutków znaczacych. Ale to dalej spieprzenie. Nie
> zachowanie higieny/dyscypliny w małym projekcie powoduje ze to lenistwo
> rozpływa się na większe projekty. Wiem bo widzę.

E tam gadanie. Piszę tak jak w moim odczuciu jest najlepiej. Najlepiej oznacza
intuicyjnie osiągany kompromis pomiędzy szybkością działa programu,
szybkością tworzenia kodu, podatnością na konserwacją i czasem
kompilacji co się de facto zawiera w szybkości tworzenia. Jakbym czuł
że za długo czekam na kompilację to bym coś zrobił z tym fantem.

> > Poza tym program o rozmiarze 2MB, zwłaszcza gdy
> > jest porządnie zaprojektowany, to nie taki hello world, może już robić
> > coś całkiem pożytecznego.
> To dalej maleństwo.

Nie mówię że to nie jest maleństwo, tylko że to nie jest hello world a
tym bardziej spieprzenie. Jak się ktoś postara, to za procedurę o rozmiarze
5kb i nobla dostanie.

[f...@wytnij.gazeta.pl]

M.M. <mari...@WYTNIJ.gazeta.pl> napisał(a):

nie wiem na ile wogole kompilacje moze przyspieszyc uzywanie
ramdysku, kiedysm mialem jakis fajny ramdysk, mozna spokojnie
wykroic nawet spory kawal ramu na ramdysk - niestety po pierwszym
uzyciu gdzies mi sie zgubil i nawet nie pamietam czy bylo jakies
przyspieszenie

[M.M.]

<f...@WYTNIJ.gazeta.pl> napisał(a):

Trzeba sprawdzić co jest wąskim gardłem. Jeśli częste naprowadzanie
głowicy to ram dysk powinien znacznie przyspieszyć.
Pozdrawiam

[f...@wytnij.gazeta.pl]

M.M. <mari...@WYTNIJ.gazeta.pl> napisał(a):

wydaje sie ze tak, ale kiedys chyba costam uruchomilem z ramdysku
i jakby nie bylo szybciej, (slabo pamietam)
chyba trzeba by wrzucic i kompilator i zrodla na ten ramdysk
(a moze i jakied dll'ki?) tak zeby nic nie musial doczytywac
z dysku wtedy pwoinno byc naprawde szybko, ale wlasnie nie
wiem czy i tak jakies ddlki nie beda doczytywane z dysku
i czy cos takiego da sie zrobic

[f...@wytnij.gazeta.pl]

wyjrzałem przez trzecie oko - i wyskoczylem przez okno

w sumie to szkoda ze ramu nie da sie obejrzec w total komanderze
tak jak dyskow - to by nie bylo glupie - zorganizowanego na
podobienstwo systemu plikow i nawet z mozliwoscia pewnego
zarzadzania recznie - np wlasnie na podobienstwo ramdysku
i np tez systemu z cache - tak zebyy niekoniecznie wszystko
po uzyciu z tego ramu za kazdym razem wypadalo i musialobyc
wczytywane na nowo

[M.M.]

<f...@WYTNIJ.gazeta.pl> napisał(a):

> wydaje sie ze tak, ale kiedys chyba costam uruchomilem z ramdysku
> i jakby nie bylo szybciej, (slabo pamietam)
> chyba trzeba by wrzucic i kompilator i zrodla na ten ramdysk
> (a moze i jakied dll'ki?) tak zeby nic nie musial doczytywac
> z dysku wtedy pwoinno byc naprawde szybko, ale wlasnie nie
> wiem czy i tak jakies ddlki nie beda doczytywane z dysku
> i czy cos takiego da sie zrobic

Zależy jakie zadanie. Turniej szachowy gdzie jedna gra trwa 10 sekund
mocno obciąż dysk. Ciągle ładowanie programów do pamięci, odczyt
dużych książek debiutowych, zapis gier na dysk. Gdy odpaliłem na
ram dysku to też nie zaobserwowałem przyspieszenia. Może system
na tyle dobrze buforuje pliki?
Pozdrawiam

[M.M.]

<f...@WYTNIJ.gazeta.pl> napisał(a):

Pewnie się da, ale po co to oglądać? Są specjalistyczne
narzędzia, choćby debuger.
Pozdrawiam

[Artur M. Piwko]

In the darkest hour on Fri, 1 Jun 2012 17:18:07 +0000 (UTC),
M.M. <mari...@WYTNIJ.gazeta.pl> screamed:

>> Zakładasz, że każdy KB kodu, niezależnie od jego zawartości kompiluje
>> się tak samo długo. To tak jakby za pomocą wagi malucha w kg/cm? przeliczać
>> wagę Hummera.
> To Ty zakładasz że ja coś takiego zakładam. Tymczasem moje założenie
> było inne. Założyłem że próbka kodu jest reprezentatywna i wystarczy
> do oszacowania.
>

Moje założenia raczyłeś wyciąć w postaci swojego cytatu.
Próbka kodu może być reprezentatywna jedynie w obrębie tego samego kodu.

--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:237B ]
[ 03:02:07 user up 13187 days, 14:57, 1 user, load average: 0.90, 0.38, 0.19 ]

I'm such a good lover because I practice a lot on my own. -- Woody Allen

[f i r]

M.M. <mari...@WYTNIJ.gazeta.pl> napisał(a):

a dysk nie mielil i tak ? gdyby odciac program np
ja kompiluje z lini komand czyli przy kompilacji jak
rozumiem do ramu musi sie wczytac zarowno kompilator
z rozmaitymi dowiazaniami jak i wszystkie skladniki
zrodel, libi etc - gdyby to wszystko oddyskowic to mz
powinno chyba byc o wiele szybciej

[prof fir]

teraz nie jest tak, np alokowane kawalki nie maja swoich nazw
w ramie (np map, postaci_lable, costam_cahce) Pomysl jest
by to bylo robione na podobienstwo systemu plikow z
timestampem utworzenia, atrybutami, plikopodobna strukturą
wnetrza ramu, ew nawet mozliwoscia recznej ingerencji
przez totalkomandera.

[M.M.]

f i r <f...@WYTNIJ.gazeta.pl> napisał(a):

Nie wiem. Zwykle nie czekam tak długo na kompilację aby
skracać ten proces. Spróbuj i napisz jak wyszło. Może
skompiluj QT, to jest odpowiednich rozmiarów aby testować :)
Pozdrawiam

[M.M.]

Artur M. Piwko <milusi.p...@buziaczek.pl> napisał(a):

> In the darkest hour on Fri, 1 Jun 2012 17:18:07 +0000 (UTC),
> M.M. <mari...@WYTNIJ.gazeta.pl> screamed:

> >> ZakĹ adasz, Ĺźe kaĹźdy KB kodu, niezaleĹźnie od jego zawartoĹ ci kompiluje
> >> siÄ tak samo dĹ ugo. To tak jakby za pomocÄ wagi malucha w kg/cm? przelicz
> aÄ
> >> wagÄ Hummera.
> > To Ty zakĹ adasz Ĺźe ja coĹ takiego zakĹ adam. Tymczasem moje zaĹ oĹźenie
> > byĹ o inne. ZaĹ oĹźyĹ em Ĺźe prĂłbka kodu jest reprezentatywna i wystarczy
> > do oszacowania.
> >
>
> Moje zaĹ oĹźenia raczyĹ eĹ wyciÄ Ä w postaci swojego cytatu.
> PrĂłbka kodu moĹźe byÄ reprezentatywna jedynie w obrÄ bie tego samego kodu.
Do oszacowania wystarczy.

[f...@wytnij.gazeta.pl]

M.M. <mari...@WYTNIJ.gazeta.pl> napisał(a):

ja tez nie czekam, z tego co mowisz to kompilujesz 500kB
w 7s ja w ok 2s - ale jakby mialo byc .5s to wolalbym .5s
Nie mam teraz czasu testowac ramdyskow ale jest to ciekawy
temat i kiedys pobadam

[f i r]

jeszcze inna kwestia w moim wypadku to 'stripnąć' windows.h -
moj kod dla testow ma okolo 500k (drugi do ogla tez ok 500k)
a includy windy jak kiedys mowilem maja 3000k moze
zakomentowanie 99% vel wybiorcze inkludowanie tylo tego
czego uzywam z windows.h mogloby przyspieszyc (ale to troche
zabawy i tez nie mam teraz na to kwestii)

[f...@wytnij.gazeta.pl]

trzecia opcja to robic tak jak c przykazalo czyli opanowac jakies
make i kompilowac jednak kazdy plik.c odzielnie i na gorze pliku
wstawiac te deklaracje itp - ale tez mi sie nie che tego robic
- wiecej opcji poza tymi trzema poki co nie widze, czyli mam
trzy opcje, ramdysk, stripowanie windows.h i porzadny make

[Jacek]

Dnia Mon, 28 May 2012 19:17:14 +0000 (UTC), profesor fir 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?

A jak ma się Twoje nazewnictwo plików do nazewnictwa zmiennych, klas etc.?
Jak czyta się lepiej:
- For x = 1 To Len(FirstName),
- For x = 1 To Len(ImięUżytkownika),
- SELECT FirstName FROM Users,
- SELECT ImięUżytkownika FROM Użytkownicy i tak dalej.

Ja jestem starej daty i nie używam ogonków. Co do przedmiotu, to stosuje
polskie nazwy. Myślę, że nie ma sensu stosować angielskiego nazewnictwa,
tylko po to, żeby scalała sie cała treść kodu.
Mówię oczywiście o kodzie, który nie ma 'iść' za granicę.

[Sebastian Biały]

On 2012-06-02 14:58, Jacek wrote:
> stosuje
> polskie nazwy.

pseudokod:

for each osoba get imie.

Pfff...

> Mówię oczywiście o kodzie, który nie ma 'iść' za granicę.

Czasem zagranica przychodzi do kodu.

[f...@wytnij.gazeta.pl]

Jacek <a...@ola.pl> napisał(a):

ostatnio czuje sie jakos dziwnie staro; nazewnictwo to
w sumie calkiem duzy i 'odzielny' temat; przy tym warstwe
nazw plikow uwazam za raczej dosyc wazną;

co do angielskiego to ciekaw jestem jak slabym angielskim
ja piszę bo nie umiem ocenic swoich niepoprawnosci (jak to
smiesznie wypada po angielsku); (posty po angielsku pisze
w normalnym tempie, z tym ze prostym angielskim, jesli
czasem nie znam wyrazenia to pisze podobne w troche inny
sposob - w ostatnich dwu latach zaczalem szybciej czytac
po angielsku bo dwaniej czytalem raczej tez bez problemu
ale wyraznie wolniej, teraz czytam przypuszczam tylko
troche wolniej niz po polsku)

[Artur M. Piwko]

In the darkest hour on Sat, 2 Jun 2012 07:58:54 +0000 (UTC),
M.M. <mari...@WYTNIJ.gazeta.pl> screamed:
> Do oszacowania wystarczy.
>

Jeśli nie zważamy na dokładność, to tak.

--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:239B ]
[ 19:04:24 user up 13189 days, 6:59, 1 user, load average: 0.69, 0.61, 0.06 ]

Peace: In international affairs, a period of cheating between two countries.

[M.M.]

Artur M. Piwko <milusi.p...@buziaczek.pl> napisał(a):

> In the darkest hour on Sat, 2 Jun 2012 07:58:54 +0000 (UTC),
> M.M. <mari...@WYTNIJ.gazeta.pl> screamed:
> > Do oszacowania wystarczy.
> >
>

> JeĹ li nie zwaĹźamy na dokĹ adnoĹ Ä , to tak.
Hmmm A czy przypadkiem wąskim gardłem nie są dostępy dyskowe?
Zwykle kompilujemy na debug, czyli kompilator nie musi się
zbytnio wysilać przy generowaniu kodu. Może jednak nie ma
dużych różnic w czasach kompilacji, wykluczywszy takie dziwactwa
jak 20-krotnie zagnieżdżone makra albo templates.