Skocz do zawartości

reijoslav

Członkowie
  • Postów

    4
  • Dołączył

  • Ostatnio

    Nigdy

reijoslav's Achievements

Newbie

Newbie (1/14)

0

Reputacja

  1. Konstruktywne lenistwo. Bedąc tak leniwym, że trzba zmuszać komputer do zrobienia Twojej pracy poprzez programowanie serii skryptów, bardzo często się opłaca, ponieważ gdy już wszystko działa, nie trzeba robić zbyt wiele ;)
  2. Tak jak napisał bartek i environ, == porównuje same adresy, z kolei equals() porównuje treść. Należałoby jednak dodać, że wszyskie stałe o typie String użyte w programie (więc, w twoim przypadku -- stringi takie jak "T" lub "Chcesz kontynuować? (T/N):") są dodawane do wewnętrznej puli stringów maszyny wirtualnej jeszcze przed rozpoczęciem działania programu. Użycie metody intern() na typie String wymusza odszukanie wybranego ciągu znaków w tej puli i zwrócenie referencji do tego konkretnego wpisu w puli stringów, jeśli ten string w puli istnieje. Jeśli nie istnieje, jest do niej dodawany i zwrócona zostanie referencja do (już istniejącego) nowego wpisu w puli stringów. Jak zostało wspomniane wcześniej, stosując porównanie a == b, zakładając że a i b są zmiennymi o typie String, porównywane są ze sobą dwie referencje. Gdy przynajmniej jedna z nich jest dynamicznie alokowana, nie jest możliwe określenie równości treści danych znajdujących się w tych zmiennych (za pomocą operatora ==). Jednak wymuszając dodanie treści tych zmiennych do puli stringów za pomocą .intern() -- if(a.intern() == b.intern()), porównywane są ze sobą referencje obiektów puli stringów. Biorąc pod uwagę charakter działania metody intern() i to, że wymusza ona istnienie tylko jednego obiektu w puli o danej treści, w sytuacji, gdy a i b zawierają te same dane, metody intern() będą wskazywać na ten sam obiekt w puli stringów, spełniając zadanie porównania treści zmiennych :) Dlatego też kod: if(text.intern() == "T".intern()) { stop = true; } też powinien spełniać swoje zadanie (mimo, że oczywiście lepiej używać equals()).
  3. Przypominam sobie kilka rzeczy, których nie chciało mi się kiedyś zrobić, a które przydałyby mi się teraz i zastanawiam się: co będzie, jeśli rzecz, którą aktualnie robię, będzie mi potrzebna w przyszłości na tej samej zasadzie? Jeśli teraz nie chcę jej robić, z jakiegokolwiek powodu, to czy za kilka lat ten powód będzie tak samo uzasadniony jak uzasadniam to sobie teraz? Oprócz tego zdaję sobie sprawę z tego, że każda rzecz, którą zrobię dziś, ułatwi mi życie za kilka lat -- (np. ucząc się programować w podstawówce ułatwiłem sobie znalezienie pracy po podrośnięciu), więc jako prawdziwie leniwy człowiek, celujący w absolutne nic-nie-robienie, idę na kompromis robiąc teraz więcej, gdy mam jeszcze siłę, podczas gdy na starość nie będę musiał robić absolutnie nic ;)
  4. reijoslav

    Edytor dla C++

    Do większych projektów C++ raczej chyba tylko Eclipse, ewentualnie QtCreator. Ten drugi niestety nadal posiada irytujące błędy w interfejsie użytkownika, mimo że ogólnie to całkiem przyjemne IDE (przykładowy błąd to czasami zdarzające się duplikowanie otwartych plików podczas sesji debug -- rezultatem jest np. kilka otwartych plików main.cpp). W QtCreator jednym z najfajniejszych features'ów jest oczywiście indexer, semantyczne szukanie w editboxie przy dolnej krawędzi okna (locator - tutaj więcej info) oraz wsparcie dla refactoringu. Nie można też pominąć szybkości działania i integracji z genialnym frameworkiem Qt, np. przy debugowaniu gdb ;). Jeśli chodzi o Eclipse, to dość chaotycznie zaprojektowane IDE, zlepione prawdopodobnie przez kilka drużyn programistów. Ale jest w tej chwili najbardziej stabilne ;), z funkcjami typu Ctrl+Shift+R, Ctrl+G, Ctrl+O, F3 (implementującymi właściwie te same funkcje co Locator w QtCreator). Duża ilość pluginów typu Python Development Tools czy wsparcie dla Ruby niekoniecznie musi oznaczać o dużej jakości tych pluginów (dla pythona lepsze będzie prawdopodobnie PyCharm, dla Ruby -- RubyMine), jednak plugin z supportem dla C++ ("CDT") jest naprawdę bardzo dobry. Dla hejterów Linuxa i Javy mogę też dodać, że nowe Visual Studio na moich maszynach jest o wiele wolniejsze od Eclipse i tam czasami otwarcie projektu trwa kilka ładnych sekund. Z Eclipse tego problemu nie ma i czasami nie trzeba nawet go uruchamiać, żeby skompilować projekt :). Pisząc to zdaję sobie sprawę, że są miejsca, gdzie Eclipse robi pod górkę, a raczej nie robi niczego, aby ułatwić życie -- np. chcąc debugować program spod IDE należy właściwie nauczyć się obsługi gdb, aby np. móc skonfigurować wsparcie dla printerów kolekcji ze standardowej biblioteki C++ (std::vector, std::map -- pisze się to w Pythonie, ale są gotowce), oraz integracja z Qt może być bardzo podchwytliwa (np. ciężko wyświetlić zawartość QString na zwykłym, stockowym gdb, ponieważ dostanie się na wyjściu strukturę, która nie przestawia zawartości string'a). Oba IDE wymagają jednak nauki działania, aby wykorzystać np. własny system kompilacji typu CMake, Waf, przy czym z doświadczenia wiem, że w obu da się używać własnych systemów, trzeba tylko poznać tajniki działania indexer'ów i czasami stosować niemiłe hacki ;). Z tego też powodu, kto szuka rozwiązania out-of-the-box i works-everywhere, sugeruję jednak Visual Studio, aby zaoszczędzić sobie trochę czasu. Ci, którzy chcą dostosować build swojej aplikacji w najdrobniejszych szczegółach (np. przy Waf skrypt budujący program pisze się w Pythonie, tak jak w Scons), niech wybiorą raczej Eclipse lub QtCreator :)
×
×
  • Utwórz nowe...