Autor Wątek: Zapraszam na http://polak17.republika.pl/  (Przeczytany 3218 razy)

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Wrzesień 28, 2009, 16:31:42
Jak ktoś lubi niezauważalnie większą wydajność i niewygodny interface to pewnie tak  ::)
Jak ktoś lubi krzaczki w kodzie (typu operator przesunięcia bitowego udający coś, czym być nie powinien) oraz dość ograniczone mozliwości/rozlazły kod (polecam próbę rekreacji działania typu printf(" 0x%02X %-20s 0x%08x\n")), to mozna i iostreamów używać. ;) Tak czy inaczej, wszystko jest kwestią gustu, niemniej jednak nazywanie streamów bardziej C++owymi tylko z tego względu, że mają przeciążone operatory jest już czysto OOP-owym zboczeniem (warto uzmysłowić sobie fakt, że C++ jest jezykiem wieloparadygmatowym, a nie tylko OOP). :)

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

wine

  • Gość
# Wrzesień 28, 2009, 16:59:52
warto uzmysłowić sobie fakt, że C++ jest jezykiem wieloparadygmatowym, a nie tylko OOP
Zasadniczo C++ jest językiem obiektowym tyle, że trzyma zgodność z C (można C skompilować w C++'osowym kompilatorze) i odziedziczył po nim proceduralny model programowania... :P co znaczy to samo... mhm... end of spam

Offline Aithne

  • Użytkownik

# Wrzesień 28, 2009, 17:20:41
Jako alternatywę masz juz jak najbardziej 100% C++owe <stdio>
Ale takiego nagłówka nie ma :(.

end of spam
Nie wierzę. Ty to napisałeś? Nie może być ;).

Offline vashpan

  • Użytkownik
    • Strona

# Wrzesień 28, 2009, 17:21:24
Zasadniczo dosc trudno bez zadnych zmian skompilowac kod C w trybie C++ , chociazby ze wzgledu na wieksza kontrole typow ;) Poza tym - uwazasz ze biblioteka C jest przestarzala, fajnie, bo praktycznie kazdy program ktorego uzywasz z niej korzysta ;) Posrednio ( np. o, niespodzianka - przez standardowa biblioteke C++, bedac maszyna wirtualna Javy czy CLR napisana w C, prawdopodobnie bedac nawet systemem operacyjnym twojej komorki ) lub calkiem bezposrednio, bez biblioteki C, nie mialbys nawet funkcji rand() ;p Z ktorej oczywiscie nie korzystasz tylko masz jakis obiektowy generator, no bo przeciez jest taka przestarzala ;) ( btw, C++ ma ponad 20 lat, wie chyba tez jest "przesatarzaly " troszke nieprawdaz ? ;) )

Nie warto popadac w paranoje i uzywac to co jest w danej chwili potrzebne.

A co do jezyka C. Warto mu sie bez pretensji przyjrzec i dojrzec ze jest to naprawde elegancki i prosty jezyk, ktory calkiem dobrze sprawdza sie w tym do czego go zaprojektowano - tworzeniu systemow operacyjnych i podstawowego oprogramowania do nich. Jednakze po prawie 40 latach programy sie rozrosly i o ile C jest w miare wygodny przy stosunkowo niewielkich programach, im wiecej kloc, tym utrzymywanie kodu w C staje sie trudniejsze, dlatego powstal C++ i inne obiektowe jezyki wczesniej i pozniej.
« Ostatnia zmiana: Wrzesień 28, 2009, 17:23:18 wysłana przez vashpan »

wine

  • Gość
# Wrzesień 28, 2009, 17:26:13
end of spam
Nie wierzę. Ty to napisałeś? Nie może być ;).
Zauważyłaś że nie jestem wine tylko Wine :P. A tak na serio: end of THIS spam

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Wrzesień 28, 2009, 17:29:09
Cytuj
Zasadniczo C++ jest językiem obiektowym
Nie jest. C++ jest językiem, który pozwala pisać obiektowo, w taki sam sposób w jaki pozwala pisać używając innych paradigmatów, według Wikipedii dokładnie trzech - programowania imperatywnego, uogólnionego i obiektowego, ale przy odrobinie gimnastyki z pewnymi ograniczeniami można także pewnie i pisać w innych paradygmatach (np. funkcjonalnym).

Cytuj
Zasadniczo dosc trudno bez zadnych zmian skompilowac kod C w trybie C++
Polecam kompilację w C++ dowolnego RPG lub MUDa w C. Połowa zmiennych nazywa się "class" (a druga połowa "new"). ;)

Cytuj
utrzymywanie kodu w C staje sie trudniejsze, dlatego powstal C++ i inne obiektowe jezyki wczesniej i pozniej
...w których to językach utrzymanie kodu z trudnego niekiedy staje się masakryczne. ;)

Offline Kos

  • Użytkownik
    • kos.gd

# Wrzesień 28, 2009, 17:49:55
Cytuj
utrzymywanie kodu w C staje sie trudniejsze, dlatego powstal C++ i inne obiektowe jezyki wczesniej i pozniej
...w których to językach utrzymanie kodu z trudnego niekiedy staje się masakryczne. ;)
Oj tam. Kod masakryczny do utrzymania da się zrobić w każdym języku :P

Offline spax

  • Użytkownik

# Wrzesień 28, 2009, 18:28:46
Niech przemówią wasze projekty (w C od KK, C++ od wine).

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Wrzesień 28, 2009, 18:31:06
Niech przemówią wasze projekty (w C od KK, C++ od wine).
Zacznijmy od tego, że nie piszę w C. ;)

Offline dwd

  • Użytkownik

# Wrzesień 28, 2009, 20:17:40
Naprawde serdecznie zapraszam na http://polak17.republika.pl/
Cytat: republika.pl

Przykro nam, strona o podanym adresie nie istnieje.

Sprawdź, czy wpisałeś poprawny adres strony, lub skorzystaj z katalogu lub wyszukiwarki.
Długo kolego nie pociągnąłeś, ta strona przetrwała raptem 10 godzin...

Offline bies

  • Użytkownik

# Wrzesień 28, 2009, 21:11:06
Cytuj
Najbardziej poprawnym jest użycie iostreams
Równie poprawnym, co std::printf. :)
Jak ktoś lubi niezauważalnie większą wydajność i niewygodny interface to pewnie tak  ::)
Zauważalnie, patrz np. [1] albo [2]

Jak ktoś lubi niezauważalnie większą wydajność i niewygodny interface to pewnie tak  ::)
Jak ktoś lubi krzaczki w kodzie (typu operator przesunięcia bitowego udający coś, czym być nie powinien) oraz dość ograniczone mozliwości/rozlazły kod (polecam próbę rekreacji działania typu printf(" 0x%02X %-20s 0x%08x\n")), to mozna i iostreamów używać. ;) Tak czy inaczej, wszystko jest kwestią gustu, niemniej jednak nazywanie streamów bardziej C++owymi tylko z tego względu, że mają przeciążone operatory (...)
Nie. IOStreams jest bardziej C++-owy dlatego, że jest statycznie typowany i operują na klasach użytkownika. Zauważ, że to co przyniósł C++ do C to głównie typy (deklaracje funkcji, klasy, szablony -- to wszystko typy).

Ogólnie nie polecam ani jednego, ani drugiego (poza wprawkami i miejscami gdzie brak wydajności IOStreams jest pomijalnie mała -- bo i tak czekamy np. na bazę albo inne I/O). Do formatowania Boost.Format (szybkie i statycznie typowane), FastFormat [1] (jeszcze szybsze) albo FASTreams [2] (szybkie, formatowanie częściowo zgodne z printf).

[1] http://www.fastformat.org/
[2] http://www.msobczak.com/prog/fastreams/
« Ostatnia zmiana: Wrzesień 28, 2009, 21:16:10 wysłana przez bies »

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Wrzesień 28, 2009, 21:18:01
Cytuj
Do formatowania Boost.Format (szybkie i statycznie typowane), FastFormat [1] (jeszcze szybsze) albo FASTreams [2] (szybkie, formatowanie częściowo zgodne z printf).
Wszystkie trzy wymagają dodatkowego zachodu w postaci dodatkowej biblioteki. Zwykle nie potrzebuję na tyle szybkości w wypisywaniu, żeby printf był złym rozwiązaniem.

Offline bies

  • Użytkownik

# Wrzesień 28, 2009, 21:23:40
Cytuj
Do formatowania Boost.Format (szybkie i statycznie typowane), FastFormat [1] (jeszcze szybsze) albo FASTreams [2] (szybkie, formatowanie częściowo zgodne z printf).
Wszystkie trzy wymagają dodatkowego zachodu w postaci dodatkowej biblioteki. Zwykle nie potrzebuję na tyle szybkości w wypisywaniu, żeby printf był złym rozwiązaniem.
Ja mam Boosta zawsze (to właściwie już część std dla mnie). Ale DGCC. Z tym, że niepotrzebnie omijasz kwestię typów -- funkcje ze zmienną liczbą argumentów mogą pogryźć. ;D

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Wrzesień 28, 2009, 21:32:43
Cytuj
Ja mam Boosta zawsze (to właściwie już część std dla mnie). Ale DGCC. Z tym, że niepotrzebnie omijasz kwestię typów -- funkcje ze zmienną liczbą argumentów mogą pogryźć. ;D
Czasami gryzą, ale nie jest to większym problemem. Co do bibliotek, to dość często korzystam z własnej bazowej, w której między innymi można znaleźć base::format w postaci "string format(const char *fmt,...)". ;)