Wypowiedzi
-
Co dokładnie po co?
-
Rzeczywisty rozmiar możesz uzyskać powiększając obraz do:
100% * (DPI_MONITORA/96)
Innym rozwiązaniem jest zmiana DPI w systemie. Z jednej strony nie musisz się już martwić o skalę w żadnym programie, z drugiej... cały system operacyjny wygląda jak crap. Dotyczy to Windows, Linux jeszcze jakoś daje radę, nie wiem jednak co z Mac OS X.
PS. Jeżeli nie znasz DPI monitora, z tym też mogę pomóc.
Pozdrawiam :) -
Maciej Siniło:
Jezeli program normalnie kompiluje sie 20 minut, to jest slabo zaplanowany :)
Albo naprawdę duży. :) -
Żadnego artykułu naukowego nie na ten temat nie znam.
Zazwyczaj formułuje się odwrotne tezy, takie jak "jakie są zalety kodu zarządzanego nad natywnym". Naturalnie natychmiast zachodzi zależność prędkość <-> stabilność, jak to zauważył mój przedmówca.
Zalety kodu natywnego nad zarządzanym? Przychodzą mi namyśl dwa przykłady:
- kod jest nieco szybszy, jednak ryzyko popełnienia błędu wzrasta
- nie wymaga środowiska uruchomieniowego ponad system operacyjny
Z ów prędkością różnie bywa i zależy to w głównej mierze co staramy się osiągnąć. Dla przykładu przetwarzanie obrazów w języku zarządzanym działa do kilku razy wolniej. Opracowując jednak aplikację biurową różnica jest praktycznie niezauważalna.
Jeśli prędkość jest czynnikiem krytycznym, wybierany jest język kompilowany do kodu natywnego. -
Dołożę moje trzy grosze.
Programowałem w Delphi 6, Delphi 7 i późniejszych. Różnice jakie zazwyczaj dało się zauważyć to kosmetyczne poprawki w interfejsie użytkownika. Niewielkie zmiany w komponentach, parę dodatków, trochę porządków. Na zewnątrz naprawdę faktycznie niewiele ulega zmianie. W zasadzie wydłuża się jedynie czas ładowania IDE.
W zasadzie od kiedy prace nad projektem zostały zawieszone nie korzystam już z tego języka. Trzeba zaznaczyć, że jako taki ma swoje zalety. Parę cech, które czynią go wygodniejszym, a nad którymi nie będę teraz dyskutował. Niemniej jednak w tej chwili moje subiektywne odczucie jest takie: Delphi umiera. Od dłuższego pozostaje alternatywą, ponieważ nie oferuje nic, czego brakuje konkurencji. Moja wiedza na ten temat jest niekompletna, ponieważ nie śledzę aktualności na ten temat.
Chętnie się dowiem, gdzie aktualnie wykorzystuje się Delphi. Szczególnie ciekawią mnie sytuacje, kiedy to z analizy projektu wyniknie wypływa wniosek: Delphi jest najlepszym narzędziem pracy do wykonania tego zadania. Chodzi mi głównie o nowe projekty, do których realizacji można wybierać środowisko pracy, nie powiązane zależnościami rodzaju "nasz komponent odpowiedzialny za XXX jest w Delphi, dlatego nie skorzystamy z rozwiązania YYY".
Do Panów Piotra i Macieja: Kubeł zimnej wody, żeby dyskusja dyskusją pozostała. :) -
Singularity również nie jest w 100% w C# :)
-
Trudno mi zrozumieć to całe narzekanie na wskaźniki. Jeszcze dziwniejsze są stwierdzenia, że programiści się ich boją. Ich idea jest prosta aż do bólu. Tak, trzeba mieć głowę na karku i nie pisać po kilku piwach, a wszystko trzyma się kupy. :)
Z C korzysta się, kiedy trzeba.
Bdw. co to są 'hardwarowe łańcuchy'? Nie umiem tego odnieść do C. Chyba, że to było 'przesadnie o łańcuchach'. -
Piotr Likus:
Co do spacji przed czy po gwiazdce to chyba bardziej trywialnego tematu nie było w historii programowania. A dyskutuje nad tym masa ludzi...
// 1
int* ptr1;
int *ptr2;
// 2
int* ptr3, *ptr4;
int *ptr5, *ptr6;
Każdy widzi różnice? Nie ma innej niż stylistyczna, to której używamy zależy od tego, czy chcemy mieć dobrze wyglądający kod. To z kolei zależy od ogólnej konwencji formatowania. W tym miejscu nie ma powinności. :) -
Bywa
-
Pozostaje mieć nadzieję, że nie jest taka rozproszona :)
-
Jeśli mnie pamięć nie myli rozproszone macierze tworzy się nieco inaczej niż alokując całą, bądź wskaźniki na jej elementy. :)
-
Różnica na każdy obiekt to co najmniej cztery bajty. Na 10 milionach obiektów tracisz 40MB.
-
Jacek Stanisław Kutyła:
pytanie czy zajetosc bedzie proporcjonalna do ilosc obiektow danej klasy/struktury?
W przypadku struktury:
TComplex = record packed
Real: Single;
Img: Single;
end;
Atrybut 'packed' jest zbędny, ponieważ struktura zamyka się w ośmiu bajtach. Domyślnie w projektach Delphi wyrównywanie ustawione jest na osiem bajtów, czyli mieścimy się idealnie. W moich projektach zazwyczaj ustawiam wyrównanie do czterech bajtów.
Pojedyncza struktura będzie zajmować osiem bajtów, rozmiar tablicy jest oczywiście proporcjonalny.
Jacek Stanisław Kutyła:
domyslam sie, ze dostep do spakowanego rekordu bedzie wydluzony?
Spakowany, nie znaczy skompresowany. Ten atrybut mówi o opakowaniu tego w pamięci. -
Definiując klasę zajętość pamięci będzie większa, co jest spowodowane obecnością RTTI. Struktura natomiast zajmie żądaną ilość bajtów. Dodatkowo można skorzystać z atrybutu 'packed'.
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy OpenGL
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy OpenGL
-
Szymon Kubisiak:
Bo się nie nadaje. Chyba tylko o tyle że nadaje się do wszystkiego. Aczkolwiek to sztuka dla sztuki by wynajdywać koło za każdym razem gdy chce się coś przewieźć.
Po prostu jest mnóstwo fajnych języków gdzie takie rzeczy są już wbudowane, nie trzeba ich samemu pisać oraz walczyć z debuggerem brnąc przez dziesiątki funkcji i obiektów tylko po to by zobaczyć skąd się bierze 1 zmienna.
Demonizujesz C++ :)
Ludzie, kiedy mają za dużo swobody po prostu się gubią.
Wynalezienie na nowo koła jest całkiem dobrym pomysłem, jeśli ktoś ma się nauczyć jak coś działa. Później będzie używał gotowych kół.
Szymon Kubisiak:
Jest taka reguła, KISS. Stupiętrowe drzewo templatów jest jej wbrew.
Dlatego lepiej takiego nie tworzyć. C++ nie oznacza automatycznie tworzenia miliona szablonów i zbijania wszystkiego rosyjską metodą. Niestety tego nigdzie nie uczą. -
Szymon Kubisiak:
dżizas - automatyczne tablice, typy wariantowe...
Owszem, da się to zrealizować w C++, ale nie lepiej użyć języka wyższego poziomu który został zaprojektowany z myślą o takich rzeczach?
Piszesz, jak by C++ się do tego nie nadawał. Dlaczego? -
Niestety, próbowałeś pastą do czyszczenia butów wymyć okna.
Szlachetna indencja, jednak wektor może być tylko konkretnego typu. Ten z kolei wybierany jest na etapie kompilacji. Znaczy to tyle, że nie możesz określić jego typu podczas działania programu.
Z pomocą może Ci przyjść biblioteka Boost.Variant.
Wtedy Twój kod mógłby wyglądać tak:
typedef boost::variant<
bool,
char,
short,
int,
std::string,
time_t> multitype_t;
std::vector<multitype_t>* tableValues[LENGTH];
// lub lepiej:
std::vector<std::vector<multitype_t> > tableValues2;
tableValues2.resize(5);
tableValues2[0].resize(4);
tableValues2[0][0] = "This";
tableValues2[0][1] = "is";
tableValues2[0][2] = "Sparta";
tableValues2[0][3] = "!";
tableValues2[1].resize(4);
tableValues2[1][0] = true;
tableValues2[1][1] = false;
tableValues2[1][2] = true;
tableValues2[1][3] = true;
Pobierać wartości możesz następująco:
std::string my_string = boost::get<std::string>(tableValues2[0][0]);
bool my_flag = boost::get<bool>(tableValues2[0][0]);
Istnieją inne sposoby, aby dostać się do przechowywanej zmiennej. Wszystko znajdziesz w opisie biblioteki, dokładniej w tutorialu.
Inny sposób to opakowanie każdego typu w klasę. Jeszcze inny to stworzenie unii. Sądzę, że najlepiej skorzystać z gotowego (i przetestowanego) rozwiązania (czyli Boost.Variant).
Pozdrawiam. -
Pożyjemy, zobaczymy. :)