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

Náš Lopuch Vám
vytře zrak

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: nnyicic
[ 380 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  
huh huh 7.11.2007 20: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 13: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 19:39  700
mach [696]: To je jednoduchy, zapominas na
#include <boost/serialization/map.hpp>

huh huh 6.11.2007 17: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 16: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 15:25  697
Kompiluju to ve Visual Studiu 2005.
mach 2.11.2007 15: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 11: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 08:25  693
Bredy [692]: Ano, přesně, STL je realizace určitého pohledu, jak se mají navrhovat knihovny.
bredy 2.11.2007 03: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 19: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 12: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 12: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).
bredy 31.10.2007 14:48  688
huhJsem trochu pesimista, když tvrdíš, že vývoj pujde dle AS
huh huh 30.10.2007 23:58  687
mpts [684]: Děkuji, potěšilo mě, že někdo pochopil, co se snažím říci.
Bredy [682]: Ale nejde o střeva, jde primárně o analýzu a návrh, ne o implementaci.
Bredy [685]: No je pravda, že já mám tendenci přesvědčovat, že pouze jedna větev toho, čemu se dnes říká GP by se tak měla nazývat, ale to je čistě terminologický detail, kde jsem ochoten ustoupit a říkat GP všemu (stejně mě vývoj převálcuje). Abych ale tu větev nějak odlišil, začal jsem jí říkat "GP dle AS", protože prostě lepší označení nemám.

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

(c) 2001-2011 Lopuch.cz   
Kontakt