Registrace nového uživatele     Návod     Kluby     Archív  Lopuchu     Lopuch.cz  

Tolik rozruchu
jen v Lopuchu

Lopuch.cz

Jméno:
Heslo:
Podpora LCD:
 
Klub C, C++ [ŽP: neomezená] (kategorie Programování) moderuje Šéf Lopuchu.
Archiv

Články

Jak bezpečně ukončit vlákno z DllMain
FastAllocPool - urychlení častých alokací a dealokací
Akce a zpráva jako objekt
Tuply v C++
Efektivní alokátor malých objektů a tady druhý a třetí díl
Šablony: Být vládce kvalifikátorů
Vracíme z funkce objekty
Základy komunikace mezi procesy (ve Windows)
Multiple Interface a Instance Factory
Multithreading v C++ (ve Win32)
  Nastavení klubu     Nastavení práv     Homepage     Anketa     Přítomní     Oblíbené     Lopuch     Kategorie  
autor: 
text: 
vyplnit a 
Help
 Titulek, text příspěvku  
Opište pozpátku následující text bez prostředního znaku: wavmmkm
[ 380 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  
huh huh 8.11.2007 15:45  704
Bredy [703]: nechápu, proč bych měl do STL zahrnovat streamy, to drtivá většina autorů nedělá, a hlavně -- není k tomu jediný důvod

bredy 8.11.2007 15:28  703
huhDobře, ale aby diskuze měla smysl. Nechytej lidi za slovíčka. V tuto chvíli bych prosil, aby se zkratkout STL označovala zejména ta část C++, která se všude označuje jako STL a představuje vektory, mapy, kontejnery obecne, streamy, string a vse, co vsichni oznacuji jako STL a je součástí normy C++. Cokoliv jiného se značkou STL ale nemající nic společného s normou C++ v tomhle klubu by mělo nést jiný, odlišitelný název. Jinak se člověk totiž nedomluví.

Děkuji.
huh huh 7.11.2007 19:59  702
Bredy [701]: Pokud vím, tak se STL nazývala STL ještě než se do standardu dostala; koneckonců norma C++ vůbec termín STL nepoužívá. Ale hlavně je to úplně jedno -- zjevně si mou větu pochopil.
bredy 7.11.2007 12:25  701
huhTo je právě ten terminologický rozpor, protože já STL jako Standard Template Library považuji zejména to co se dostalo do standardu C++, od toho taky slovo Standard. Jestli někdo ve vývoji STL pokračuje, tak proč ne, ale asi bych to nenazýval STL, dokud se to nedostane do standardu.
huh huh 6.11.2007 18:39  700
mach [696]: To je jednoduchy, zapominas na
#include <boost/serialization/map.hpp>

huh huh 6.11.2007 16:36  699
Bredy [694]: Jak jsem už psal, proudy nemaj s STL nic společnýho, ty vznikly tuším u AT&T, řetězce na poslední chvíli dostaly metody, aby šli používat s algoritmy, ale jinak s návrhem STL taky nemaj nic společnýho (v STL je implementace řetězců jménem rope, ta se ale do standardu C++ nedostala; případně vector<char>).
bredy 2.11.2007 15:24  698
machTo jsem nezkoušel, ale pokud to mají implementovaný nějak podobně jako já, tak buď mapa musí mít funkci serialize, nebo někde musí být funkce/třída, která pro zadaný typ objektu a archivu řeší serializaci. Zkus se podívat, co ti to hlásí za chybové hlášky, jdi po ceste (VS2005 je dost ukecané a je to dobře, protože chyba se nemusí nutně nacházet na prvním řádku, ale příčina může být až třeba na tom posledním).
mach 2.11.2007 14:25  697
Kompiluju to ve Visual Studiu 2005.
mach 2.11.2007 14:24  696
serializace v boostuNezkousel nekdo serializovat STL objekt pomoci boost::archive? Zkousel jsem serializovat neco jednoducheho:

ofstream f(...);
boost::archive::text_oarchive a(f);
map<int, int> x;
a << as_const(x);

Kde as_const je jenom konverze na konstantu. Nejde to a hlasi:

serialize is not member of std::map

Serializace STL objektu by ale mela byt v boost::archive pripravena. Zkousel jsem to jeste s:

#define BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP

Ale nic se nezmenilo.
bredy 2.11.2007 10:13  694
A máš pravdu v tom, že se jedná o realizace _určitého_ pohledu, protože někdo jiný může mít jiný pohled.

Doufám, že třeba std::iostream a celá navazující rodina streamů nebyla navrhována podle tohoto pohledu.... A doufám, že ani std::string nebyl takto navrhován a že dnešní STL pohled je někde jinde a "stl" se v C++ suší jen díky tomu, že povinný v normě...
huh huh 2.11.2007 07:25  693
Bredy [692]: Ano, přesně, STL je realizace určitého pohledu, jak se mají navrhovat knihovny.
bredy 2.11.2007 02:02  692
huhA já pořád dokolečka nechápu jak tvá jazykově nezávislá analýza a návrh souvisí s STL dle AS. STL je jazykově závislá ukázka již hotového řešení, což mne právě na tom mate. Asi nepřijímám na té správné vlně.

Jen podotýkám, že spor vznikl tím, že jsem právě STL kritizoval jak je špatně navržena (mluvím o knihovně). Jestli někdo při návrhu přemýšlí v duchu myšlenek použitých v STL (jestli to teda chápu tak správně), tak upřímně řešeno, nechť nás programátorský bůh ochraňuje!
huh huh 1.11.2007 18:25  691
Bredy [688]: No naopak, já spíš čekám, že mě převálcujou. Zatím jediná firma, o které vím, že GP dle AS používají je Adobe, z open source tak leda Anti-Grain Geometry.
Bredy [689]: Já tu sice dokolečka mluvím o jazykově nezávislé analýze a návrhu knihoven, ale pozoruji, že to je jako mluvit do zdi.
bredy 1.11.2007 11:19  690
A ješte tu mám jednu záležitost, která mi poslední dobou velice usnadňuje práci zejména při návrhu uživatelského prostředí (ale nejen tam)

Akce a Zpráva jako objekt v.2

Hlavní výhodou je bezespory fakt, že bez ohledu na to, co voláme a kolik to má parametrů, je samotné zavolání funke omezeno jen na vyvolání jedné metody objektu. To umožňuje volání funkce nebo metody delegovat. Volání připravíme, a pak jej delegujeme. Delegované volání může proběhnout jindy, než zrovna potřebujeme, může být naplánováno, může být rozesíláno. Může být připojeno k ovládacímu prvku v grafickém UI (např. tlačítko).

Zatím rozlišujeme dva druhy volání: Zprávu (Message) a Akci (Action).

Zpráva (Message)
Je jakousi skutečnou implementací představou zprávy zaslané objektu podle OOP. Jedná se o objekt, který obsahuje jméno metody a parametry, které se mají zavolat nad nějakým objektem. V UML si můžeme zprávu představit jako obdélníček doprovázející šipku představující zaslání zprávy.
Samotný obdélníček lze připojit k libovolné šipce, a stejně tak objekt Message neobsahuje cíl, neboli konkrétní specifikaci objektu, který bude zavolán. Tuto informaci musíme dodat až v okamžiku, kdy zprávu posíláme.
Použití objektu Message je vhodné zejména u distribučních delegátů, nebo delegátů, kteří mají informovat objekt, které v době vzniku zprávy ještě neexistuje, nebo který dodá sám delegát z jiného zdroje.
Akce (Action)
Objekt akce je jednoduší, protože ke svému provedení již nepotřebuje žádné další informace. Akci spustí delegát prostým zavoláním metody Run(). Akce může být vykonána zavoláním standardní (globální) funkce, nebo funkce patřící do některého prostoru jmeno (namespace). Akce může být také vykonána zavoláním metody na objektu, který je však již předem znám - a musí být samozřejmě znám i v době zavolání.
Použití objektu Action je vhodné zejména o delegátů sledující různé události. Může se jednat o plánovače - spuštění v zadaný čas, dále pak reakce například na činnost uživatele. V neposlední řadě jsou to akce přenesené do jiného vlákna a tam spuštěné.
bredy 1.11.2007 11:14  689
ještě ke genericeJeště bych zde rozlišil dva pohledy na generiku
-uživatel generiky = je přesne to co popisoval huh, programátoři, kteří využívají už navržených generických algoritmů takže dosazují typy do šablon a generují konkrétní instance těchto algoritmů.
-tvůrci generiky = jsou lidé, kteří navrhují nové generické třídy šablony, jsou to šamani, kteří umí čarovat se šablonami a umí napsat někdy často velice geniální algoritmy, kterým občas normální smrtelník nerozumí.

Pro první skupinu může být programování podle A.S. jistě zajímavým námětem. Té druhé skupině to však asi nic říkat nebude,protože aby někdo mohl být tém šamanem, musí mít všechny tyhle fígle dávno v malíčku (a musí být i něco víc).

[ 380 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  

(c) 2001-2011 Lopuch.cz   
Kontakt