пропозиції роботи
konto usunięte
Temat: C++0x - czyżbyśmy się doczekali?
Ponoć w tym roku C++0x ma zostać zatwiedzony jako stadard.Niektórzy nazywają go już C++09.
Czyżbyśmy się faktycznie mieli w końcu doczekać?
Będziecie szczęśliwi?
Pozdrawiam :)
Niektórzy nazywają go już C++09.
Czyżbyśmy się faktycznie mieli w końcu doczekać?
Będziecie szczęśliwi?
Pozdrawiam :)
Jakub L. Programista
Temat: C++0x - czyżbyśmy się doczekali?
Teraz trzeba poczekać na kompilatory.Potem aż te kompilatory się ustabilizują.
Potem aż przemysł zauważy ich istnienie...
... i stwierdzi, że jednak można tego używać.
Szymon
Kubisiak
Developer aplikacji
mobilnych Android
Temat: C++0x - czyżbyśmy się doczekali?
Zobaczymy na jakie niespodzianki mięso armatnie się natnie na linii frontu i wejdziemy jak oczyszczą przedpole : )
konto usunięte
Temat: C++0x - czyżbyśmy się doczekali?
Wiekszosc stuffu z T1 jest juz testowo zaimplementowana, mozna kodowac.W Visual C++ 2008 SP1 jest cos z TR1.
g++ rowniez sukcesywanie dodaje kolejne kawalki -> http://gcc.gnu.org/projects/cxx0x.html
konto usunięte
Temat: C++0x - czyżbyśmy się doczekali?
Przemysław O.:
Wiekszosc stuffu z T1 jest juz testowo zaimplementowana, mozna kodowac.
Według mojego rozeznania TR1 w CAŁOŚCI ma być zawarta w nowym standardzie.
Mogą tylko ulec zmianie niektóre nazwy.
konto usunięte
Temat: C++0x - czyżbyśmy się doczekali?
Przemysław O.:>
g++ rowniez sukcesywanie dodaje kolejne kawalkig++ 4.3 potrafi już właczyć TR1 w przestrzeń nazw std.
Aby się dowiedzieć jak to zrobić wystarczy wpisać do kodu np.:
#include < tuple >
a informacja od kompilatora wyjaśnia wszystko:
#error This file requires compiler and library support for the upcoming ISO C++ standard, C++0x. This support is currently experimental, and must be enabled with the -std=c++0x or -std=gnu++0x compiler options.Piotr P. edytował(a) ten post dnia 04.01.09 o godzinie 21:07
konto usunięte
Temat: C++0x - czyżbyśmy się doczekali?
Jakub L.:
Teraz trzeba poczekać na kompilatory.
Potem aż te kompilatory się ustabilizują.
Potem aż przemysł zauważy ich istnienie...
... i stwierdzi, że jednak można tego używać.
Hmmm....
Jeśli kompilatory sie "ustbilizują" to jaką rolę widzisz tu dla przemysłu?
Programista używa pewne mechanizmy lub nie.
Przemysł żąda chyba działającego programu.
Po co ma się wtrącać jak to jest wykonane?
(Tylko jeden "przemysł", wedle mojej wiedzy, ma w tym temacie konkretne wymagania, mianowicie embedded i real-time.)Piotr P. edytował(a) ten post dnia 04.01.09 o godzinie 21:20
Jakub L. Programista
Temat: C++0x - czyżbyśmy się doczekali?
Jeżeli przemysł ma ambicję napisać kod który pójdzie na róznych kompilatorach i na różnych platformach (no tutaj to rzeczywiście głownie embeded), to zejdzie do najniższego wspólnego mianownika.A i czasem przemysł ma swoje zachciewajstwa, i naprzykład następuje zakaz używania pewnie ch klas, na przykład całego STL, i w zamian jakiegoś czegoś Invented Here (jako objaw syndromu Not Invented Here).
konto usunięte
Temat: C++0x - czyżbyśmy się doczekali?
No coz, oczywiscie sa firmy ktore blokuja uzycie STLa nawet nie robiac embedded. Jak kto lubi. Ludzie ktorzy nie uzywaja jeszcze STLa raczej nie sa zainteresowani dalszym rozwojem jezyka bo zatrzymali sie ladnych kilka(nascie?) lat temu :) Na szczescie nie kazdy jest ograniczony co do tego jak i czym ma pisac. Lub pisze w domu...TR1 oczywiscie wchodzi w calosci, chodzilo mi o to, ze nie wszystko co wejdzie w nowym standardzie jest juz zaimplementowane. Ale robi sie. Czesc fajnych rzeczy jest tez w booscie wiec tak naprawde bardzo duzo bajerow jest juz dostepne.
Szymon
Kubisiak
Developer aplikacji
mobilnych Android
Temat: C++0x - czyżbyśmy się doczekali?
STL nie jest żadnym cudownym dzieckiem i na niektórych platformach są takie implementacje (np win multithreaded) że zakaz jest jedynym sensownym rozwiązaniem.Prawda jest taka, dopóki czegoś nie zrobisz samemu, nie masz żadnej gwarancji że działa jak powinno.
konto usunięte
Temat: C++0x - czyżbyśmy się doczekali?
Szymon Kubisiak:
STL nie jest żadnym cudownym dzieckiem i na niektórych platformach są takie implementacje (np win multithreaded) że zakaz jest jedynym sensownym rozwiązaniem.
Prawda jest taka, dopóki czegoś nie zrobisz samemu, nie masz żadnej gwarancji że działa jak powinno.
Oczywiscie szanujemy takich ludzi :)
konto usunięte
Temat: C++0x - czyżbyśmy się doczekali?
Przemysław O.:Prawda jest taka, dopóki czegoś nie zrobisz samemu, nie masz żadnej gwarancji że działa jak powinno.
Oczywiscie szanujemy takich ludzi :)
Are you sure?
Mamy sami wszystko pisać? Np. obsługę systemu plików też? Własne printf?
Może własną obsługę magistrali systemowej kompa? przecież dobrze wiedzieć co jest w środku i jak to działa. Takie rozumowanie można doprowadzić do absurdu.
Chyba pisanie średnio zaawansowanej aplikacji trwało by 3 do 5 lat. A i to nie wiadomo czy kiedykolwiek ujrzała byświatło dzienne.
konto usunięte
Temat: C++0x - czyżbyśmy się doczekali?
To lekka ironia miala byc, ja osobiscie nie uwazam, ze jestem lepszy od kolesi z Boosta. Tym bardziej, ze ich jest x, maja proces walidacji tych bibliotek, iles wydanych wersji + mase uzytkownikow ktorzy to testuja. To samo np z STLPort. Ja wole pisac soft na troche wyzszym poziomie i jednak ten STL to dla mnie minimum.
konto usunięte
Temat: C++0x - czyżbyśmy się doczekali?
Przemysław O.:
To lekka ironia miala byc, ja osobiscie nie uwazam, ze jestem lepszy od kolesi z Boosta. Tym bardziej, ze ich jest x, maja proces walidacji tych bibliotek, iles wydanych wersji + mase uzytkownikow ktorzy to testuja. To samo np z STLPort.
Dokładnie :)
konto usunięte
Temat: C++0x - czyżbyśmy się doczekali?
Przemysław O.:
Szymon Kubisiak:
STL nie jest żadnym cudownym dzieckiem i na niektórych platformach są takie implementacje (np win multithreaded) że zakaz jest jedynym sensownym rozwiązaniem.
Prawda jest taka, dopóki czegoś nie zrobisz samemu, nie masz żadnej gwarancji że działa jak powinno.
Oczywiscie szanujemy takich ludzi :)
STL też sam się nie napisał. Jeśli ktoś ma samozaparcie i jakiś cel (np. coś jak "Unicode STL") to dlaczego nie? Trzeba być wdzięcznym, że komuś się chce.
konto usunięte
Temat: C++0x - czyżbyśmy się doczekali?
Piotr Likus:Oczywiście masz rację. Na takiej zasadzie funkcjonuje Open Source.
STL też sam się nie napisał. Jeśli ktoś ma samozaparcie i jakiś cel (np. coś jak "Unicode STL") to dlaczego nie? Trzeba być wdzięcznym, że komuś się chce.
Niech ludzie piszą i niech to udostępniają innym żebyśmy nie wywalali otwartych drzwi przy pisaniu każdej kolejnej aplikacji.
konto usunięte
Temat: C++0x - czyżbyśmy się doczekali?
Szymon Kubisiak:
STL nie jest żadnym cudownym dzieckiem i na niektórych platformach są takie implementacje (np win multithreaded) że zakaz jest jedynym sensownym rozwiązaniem.
Prawda jest taka, dopóki czegoś nie zrobisz samemu, nie masz żadnej gwarancji że działa jak powinno.
Jeszcze nie zdazyło mi sie zeby jakis moj algorytm działał nie poprawnie przez to ze został skrocony STL'em. W STL'u moim zdaniem brakuje tylko jednej rzeczy bo te hashe da sie przegrysc, wiekszej kontroli nad drzewami czerwono-czarnymi. Bo w niektorych bardziej skomplikowanych przypadkach to nie ma innego wyjscia jak własna implementacja.
EDIT
Ciesze ze ze w STLU nie ma np. bfs'a, dfs'a, dijkstry lub silnie spojnych skladowych bo wtedy juz nie dało by rady tego kontrolowac ;-) STL zszedl by na psy bo nikt by tego juz przy srednio skomplikowanych algorytmach nie mogl wykorzystac. A tego nie chcemy ;-)Artur Pietrzyk edytował(a) ten post dnia 08.01.09 o godzinie 00:35
Jakub L. Programista
Temat: C++0x - czyżbyśmy się doczekali?
Ale dlaczego? Jak nie chcesz/nie potrzebjesz czegoś używać, to nie używasz, nikt by ci nie kazał używać tych rzeczy, z których cieszysz się, że nie ma w STLu, gdyby tam były.
konto usunięte
Temat: C++0x - czyżbyśmy się doczekali?
Jakub L.:
Ale dlaczego? Jak nie chcesz/nie potrzebjesz czegoś używać, to nie używasz, nikt by ci nie kazał używać tych rzeczy, z których cieszysz się, że nie ma w STLu, gdyby tam były.
Problem polega w tym, ze jezeli w stlu zaimplementowali by taki algorytm jak bfs lub dfs to nie dali by tego napisac w taki sposob ze osoba, ktorej jest to tak naprawde mogla by to wykorzystac juz w srednio-zawansowanych przypadkach poniewaz na dfs'ie robi sie bardzo wiele rzeczy i nie polega to przewaznie na tym ze na kazdej iteracji wywolujesz jakas funkcje.
Np. przy implementacji silnie spojnych skladowych wykorzystujesz 2 dfs'y nie wiem jak bys chcial zrobic strukture taka zeby mozna bylo nia kontorolowac az do takiego stopnia.
Dijksre jeszcze sobie wyobrazam bo to prosta implementacja na jednym dfie ale i tak bylo by trudno.
Jaka opinia by sie pojawila o STL'u w takim przypadku gdy znajowalo by sie w nim wiele algorytmow ale wiekszosc z nich nie dalo by sie wykorzystac w wiekszosci implementacji.
Wyobraz sobie ze jestes poczatkujacym programista, chcesz cos sobie napisac, znalazles informacje na stl sgi ze jest to wlasnie w tej bibliotece, wczesniej korzystales z vectorow, list z tej biblioteki, jest fajnie, gorzej jak siedzisz juz 2 dni nad ta biblioteka i nie potrafisz tego przerobic tak zeby spelnialo twoje oczekiwania, a samemu zrobilbys to w chwilke.
Logika stla jest taka ze programisci tej biblioteki nie przejmowali sie umiejetnosciami programisty. 1 element z vectora posiadajacy n ilosc elementow mozesz sobie usunac, ale kazdy powinien wiedziec ze odbywa sie to liniowo czyli usuwalac juz pare elementow z duzej tablicy osiagamy czas paru sekund, bo stl musi przesunac wszystko w lewo.
Moim zdaniem jedynym wyjsciem jest wlasna implementacja takich elementarnych algorytmow.
Przynamniej takie jest moje zdanie.
--------------------------------------------
Pozdrawiam,
Artur Pietrzyk
Jakub L. Programista
Temat: C++0x - czyżbyśmy się doczekali?
Artur Pietrzyk:
Jakub L.:
Ale dlaczego? Jak nie chcesz/nie potrzebjesz czegoś używać, to nie używasz, nikt by ci nie kazał używać tych rzeczy, z których cieszysz się, że nie ma w STLu, gdyby tam były.
Problem polega w tym, ze jezeli w stlu zaimplementowali by taki algorytm jak bfs lub dfs to nie dali by tego napisac w taki sposob
Sam też mógłbyś sobie to napisać.
Zresztą graf reprezentować w pamięci można na kilka sposobów,
i dla tych kilku sposobów trzeba by zrobić odpowiednie grafowe iteratory, żeby wszystko działało.
Tylko że graf nie jest takim prostym kontenerem.
ze osoba, ktorej jest to tak naprawde mogla by to wykorzystac juz w srednio-zawansowanych przypadkach poniewaz na dfs'ie robi sie bardzo wiele rzeczy i nie polega to przewaznie na tym ze na kazdej iteracji wywolujesz jakas funkcje.
Znaczy się co, masz pretensję, że w STLu nie ma algorytmów które i tak by skiepścili i trzeba pisać samemu?
Wyobraz sobie ze jestes poczatkujacym programista, chcesz cos sobie napisac, znalazles informacje na stl sgi ze jest to wlasnie w tej bibliotece, wczesniej korzystales z vectorow, list z tej biblioteki, jest fajnie, gorzej jak siedzisz juz 2 dni nad ta biblioteka i nie potrafisz tego przerobic tak zeby spelnialo twoje oczekiwania, a samemu zrobilbys to w chwilke.
No to sobie by to napisał, w pewnym momencie nadchodzi czas podjęcia decyzji o robieniu samemu, zależy to też od profilu pracy, niektórym STL wystarcza w zupełności, nastepnym poziomem jest boost.
http://www.boost.org/doc/libs/1_37_0/libs/graph/doc/ta...
Logika stla jest taka ze programisci tej biblioteki nie przejmowali sie umiejetnosciami programisty. 1 element z vectora posiadajacy n ilosc elementow mozesz sobie usunac, ale kazdy powinien wiedziec ze odbywa sie to liniowo czyli usuwalac juz pare
No tutaj niestety nie ma tego napisanego explicite, ale można sobie to wywnioskować z faktu inwalidacji iteratorów za usuwanym
elementem, ostatecznie sprawdzić w kodzie, jak to wygląda.
Ale są ludzie, którzy piszą for (int i = 0; i < vec.size(); i++){ .. } (i tutaj przestaje się podobać czas usuwania, zamieniają to na przykład na listę), więc postanowiłem się nie pochylać nad ich losem.
Moim zdaniem jedynym wyjsciem jest wlasna implementacja takich elementarnych algorytmow.
Albo znalezienie innych, które nam odpowiadają bardziej.
Własna implementacja może też prowadzić do syndromu NIH, który jest bardzo niefajnym syndromem.
Sam miałem przypadek, że w kodzie od kogoś miałem deque, i ten kod sypał się w programie wielowątkowym. Po zamianie deque na listę wszystko działało bardzo ładnie. Kwestia znania narzędzi.
Ja do STLa mam taki mały zarzut, że destruktory nie są wirtualne. Przynajmniej w implementacji, z której korzystałem.
STL to zestaw naprawdę prostych kontenerów i narzędzi do operowania na nich, i jako taki sprawdza się w miarę dobrze.
To że programiści znajdują się w koleinach, i jak mają mieć kolekcję, to tylko vector, niezależnie od języka i operacji które na nim wykonują, to problem tych programistów.
RTFM i nieco szersze znanie narzędzi rozwiązuje sprawę.Jakub L. edytował(a) ten post dnia 10.01.09 o godzinie 07:42
Podobne tematy
Następna dyskusja:
