Tag: philosophy

Entries for tag "philosophy", ordered from most recent. Entry count: 32.

Uwaga! Informacje na tej stronie mają ponad 5 lat. Nadal je udostępniam, ale prawdopodobnie nie odzwierciedlają one mojej aktualnej wiedzy ani przekonań.

Pages: > 1 2 3 4 >

# Nowa teoria filozoficzna

09:23
Sun
24
Jun 2007

Wymyśliłem wczoraj nową teorię filozoficzną :) Przypomniał mi się temat forum Jeśli nie kodzić... to co? i uświadomiłem sobie, że ludzi programujących można podzielić na 3 grupy zależnie od tego, kim byliby, gdyby nie było komputerów:

Może gdyby ludzie to rozumieli i każdy znał swoje miejsce na tym schemacie, skończyłyby się spory na temat tego, czym tak naprawdę jest informatyka i programowanie? :)

Comments | #philosophy #software engineering Share

# Game Programmer - Drzewko Umiejętności

14:52
Sun
10
Jun 2007

Zrobiłem coś śmiesznego, co jednak może mieć jakiś sens. Nazwałem to Game Programmer Skill Tree. Jest to dostępne online, stylizowane przedstawienie drogi nauki, którą moim zdaniem przebywa każdy kto uczy się programowania gier. Zwięźle i krótko prezentuje poszczególne umiejętności, a także najważniejszą literaturę przydatną do ich nauki.

Następnym razem, kiedy ktoś przyjdzie z pytaniem "od czego zacząć", "nauczyłem się C++ i co dalej" albo "z czego się uczyć", możecie go tam odesłać. Będę też wdzięczny za wszelkie komentarze na forum. W planach mam następne zakręcone rzeczy :)

Comments | #teaching #philosophy #warsztat Share

# int1, int2, int4, int8

12:41
Thu
31
May 2007

Ilekroć koledzy widzą mój kod, dziwią się, dlaczego swoje typedef-y nazwałem int1, int2, int4, int8, uint1 itd., zamiast int8, int16, int32, int64, uint8 itd. Ja wtedy pytam: Po co miałbym liczyć rozmiar w bitach, zamiast w bajtach? Wiem, że tak się najczęściej robi, ale to i tak są zawsze wielkrotności ósemki. Może w grach komputerowych za zebranie kryształka warto naliczyć graczowi całe 100 punktów zamiast jednego, bo to ma jakiś efekt psychologiczny, ale programiści powinni podchodzić do życia praktycznie. Dlatego dla mnie liczenie w bitach jest po prostu bez sensu. Operator sizeof też zwraca rozmiar w bajtach :P

Comments | #c++ #philosophy Share

# Signed czy unsigned

14:40
Fri
25
May 2007

Czy do zapisywania rozmiaru danych, liczby bajtów, liczby elementów albo indeksu lepiej stosować liczbę całkowitą ze znakiem, czy bez znaku? Liczby ze znakiem są standardem w Delphi i mają wielu zwolenników dzięki swoim zaletom: Indeksy ujemne, jako niepoprawne, można stosować do oznaczenia wartości specjalnej (np. -1). Nie ma też obawy o "przekręcenie" przy zliczaniu w dół.

Ja jestem jednak zwolennikiem podejścia obowiązującego w C++, czyli stosowania typu bez znaku tam gdzie to możliwe (np. pod nazwą: unsigned, size_t, DWORD czy mój własny uint4). Zaleta tego podejścia to m.in. dwa razy większy dostępny zakres. Nie trzeba też sprawdzać poprawności liczby od dołu - wystarczy od góry. Jako wartości specjalnej można używać 0xFFFFFFFF (taką wartość ma na przykład stała std::string::npos zwracana przez std::string::find kiedy nic nie znaleziono).

Co wtedy z przechodzeniem tablicy w dół? Sposobem na to jest tzw. Pętla Tarlandila (tak sobie ją nazywam, bo nauczył mnie jej Tarlandil):

for (size_t i = RozmiarTablicy; i--; )
{
  Tablica[i] = 0;
}

Jak chcesz to przeanalizuj dokładnie jak działa ta sprytna pętla, a jeśli nie, to uwierz na słowo że ona naprawdę przechodzi tablicę w dół od elementu ostatniego do pierwszego i nie straszne jej przekręcenie się liczby bez znaku poniżej zera :)

Comments | #c++ #philosophy #algorithms Share

# Konwencja nazywania identyfikatorów

11:46
Mon
14
May 2007

Istnieje kilka różnych sposobów nadawania nazw funkcjom, zmiennym, poleceniom, znacznikom i wszelkim identyfikatorom. Można je podzielić na:

Który z nich jest najlepszy, tego nie można jednoznacznie powiedzieć. Zamiast tego spróbuj pomyśleć, który jest najgorszy ;)

Comments | #philosophy #software engineering Share

# Accidental Complexity, Essential Complexity

22:31
Thu
03
May 2007

Accidental Complexity i Essential Complexity to pojęcia, których użył Fred Brooks w swojej książce "Mityczny osobomiesiąc" oraz artykule "No Silver Bullet". Pisząc w skrócie, złożoność każdego programu jest sumą Accidental Complexity - nadmiernej złożoności, której da się uniknąć oraz Essential Complexity - złożoności która musi być, bo, jak mówią, jeśli program ma robić 30 rzeczy, to te 30 rzeczy trzeba zaprogramować.

Pomyślałem sobie dzisiaj, że tych dwóch pojęć, oprócz udowadniania dlaczego Srebrna Kula nie istnieje i nie może istnieć, możnaby też użyć do mierzenia jakości interfejsu API bibliotek (a może też podobnie interfejsu użytkownika programów?). Polegałoby to na tym, aby:

Comments | #philosophy #software engineering Share

# Singletony precz!

22:55
Tue
01
May 2007

W ramach porządków w kodzie pozbyłem się dzisiaj wszystkich singletonów zamieniając je na zwykłe, globalne zmienne wskaźnikowe. Tak, wiem co sobie teraz pomyślą wszyscy obrońcy programowania obiektowego... Ja nie mam nic do OOP ani nawet do wzorców projektowych, ale jednak krócej niż res::ResManager::GetInstance().Cośtam jest napisać res::g_ResManager->Cośtam. Poza tym to działa szybciej, bo mówcie co chcecie, ale sprawdzać czy obiekt już istnieje tysiące razy na klatkę to nie jest zerowy narzut czasu.

Przede wszystkim jednak mam teraz kontrolę nad tym, kiedy obiekt powstaje i kiedy jest niszczony, bo... robię to sam. Mogę więc powiedzieć dokładnie, czy w pewnej chwili to czy tamto jest utworzone, w jakiej kolejności jest alokowane i zwalniane oraz zagwarantować, że w danym momencie dany obiekt na pewno istnieje. Słowem - mam w pełni formalnie zdefiniowany czas życia obiektów. To rozwiązało problem, który miałem podczas finalizacji różnych modułów, a z którym nie sposób było inaczej sobie poradzić. Co za ulga! A już zaczynałem wierzyć, że singletony są OK...

Comments | #c++ #philosophy #software engineering Share

# Dobra dokumentacja na wagę złota

14:12
Fri
13
Apr 2007

Dokumentacja... Najbardziej znienawidzona część każdego programu. Prawie nikt nie lubi jej pisać, ale wszyscy wiedzą, że jest niezbędna. Dokumentacja jest tym, co najlepiej odróżnia prawdziwy, dopracowany program od eksperymentu/prototypu.

Dla odbiorcy danego programu (czy - przede wszystkim - biblioteki) dobra dokumentacja to nieoceniona pomoc. Zaawansowani tym się właśnie różnią od początkujących, że nie boją się do niej zaglądać, bo wiedzą, że znajdą tam systematyczny i szczegółowy opis każdej funkcji, jej działania i parametrów. Tylko czy na pewno kompletny?

MSDN zawsze pozostaje dla mnie pod tym względem wzorem. Ale już dokumentacji w DirectX SDK można co nieco zarzucić, szczególnie jej części poświęconej D3DX. Oprócz braku rozdziałów opisujących ogólnie sposób używania poszczególnych interfejsów doskwierają liczne drobiazgi. Na przykład:

D3DXMACRO Macros[MACRO_COUNT+1];
for (int i = 0; i < MACRO_COUNT; i++) {
  Macros[i].Name = // ...
  Macros[i].Definition = // ...
}
Macros[MACRO_COUNT].Name = NULL;
Macros[MACRO_COUNT].Definition = NULL;

Comments | #directx #philosophy #software engineering Share

Pages: > 1 2 3 4 >

STAT NO AD
[Stat] [STAT NO AD] [Download] [Dropbox] [pub] [Mirror]
Copyright © 2004-2017