Příspěvky

211

Odkladiště / Re:Už praská bublina Bitcoin

« kdy: 07. 03. 2014, 20:01:51 »

puvodne jsem chtel na prispevek tadease reagovat obsirneji ale nebudu na tom plejtvat cas. To je zase nejaky trader teoretik, ktery nikdy nevlozil na burzu ani korunu. Mluvi o nederivatech a pritom o marginu (margin je vysadou derivatovych burz prave jako je futures, nebo CFD). Vyse marginu se vyviji od likvidity a je jasne ze na mene likvidnich burzach je margin vetsi. Nenapadlo vas, ze prave snadny pristup na burzu beznym investorum u BTC zvedl jeho popularitu ale i prinesl mnohe ztraty? Coz se dalo ocekavat. Pripad MtGox mi pripomina nedavno pripad KitDigital. Kde jsou ty organizace ktere maji podle vas chranit investory? Na KITu jsem ztratil 95% puvodni investice, protoze managment priznal, ze si vevyrocnich zpravach vymyslel. Zlaty BitCoin! Pokud se v nem nenajde nejaka zasadni chyba, tak nic takoveho nehrozi. A co se volitality tyce? CEZ behem minulych dvou let spadl z 900 na 450! A co takove akcie NVR? Pane investore, zkuste si udelat svuj prvni ucet aspon na Remosce (pres FIO) nez zacnete rozdavat moudra.

212

Odkladiště / Re:Už praská bublina Bitcoin

« kdy: 07. 03. 2014, 14:23:51 »

Jednoduchý dotaz: kolik procent likvidního majetku (tedy odmysleme nemovitosti, auta atp.) jste ochotni mít v Kč, kolik v USD, kolik v BTC?
Jestli někdo spoří v BTC a má v nich většinu svých peněz, má mou hlubokou poklonu.

Mně to totiž připadá jako hra puberťáků. Kdo vydělal na 1 BTC se bije v prsa, jak je za vodou. Sorry, ale to jsou prostě drobný.

Ja bych rad i odpovedel ale chtelo by to ujasnit si pojmy. Co je likvidni majetek a podobne... Jinak se mne ptate kolik procent stribra drzim ve svych zlatych rezervach.


V tuto chvili mam 1BTC coz neni malo, ale ani moc. Je to asi 1/5 me hrube mzdy plus minus. Ale meni se to, cile s tim obchoduju a zatim jsem ve vynosu radove 10% za mesic (rikam zatim)

213

Odkladiště / Re:Už praská bublina Bitcoin

« kdy: 07. 03. 2014, 13:39:27 »

Zeptám se jinak. Už praská bublina Dolar?

Já jen, že se vykrádají i dolarové banky. Jenom se o tom běžně v médiích nepíše

http://www.reuters.com/article/2014/03/02/us-citigroup-mexico-fraud-idUSBREA210QF20140302

214

Vývoj / Re:Počitadlo impulzů pro paralelní port

« kdy: 20. 02. 2014, 16:26:43 »

Odkaz je blbě: https://www.google.cz/search?q=74193 ale na to stejně příjdete sám

215

Vývoj / Re:Počitadlo impulzů pro paralelní port

« kdy: 20. 02. 2014, 16:19:52 »

Připojte obvod 74193 (https://www.google.cz/search?q=7419) ke zdroji impulsů a jeho výstupy (4bity) na vstupní piny paralelního portu. Pokud použijete nějaké cmosy, mělo by to fungovat i z napájení logické úrovně H některého z výstupů.

Na paralelním portu lze pak opakovanými dotazy kontrolovat aktuální hodnotu bez nebezpečí, že vám nějaký impuls uteče, když se náhodou k portu nedostanete. Tedy pokud vám neuteče 16 impulzů, kdy dojde k přetečení.

Jakékoliv náročnější řešení by asi vyžadovalo nějaký jednočip, já bych to bez potíží zvládl na arduinu.

216

Vývoj / Re:Čtení dat RS232 v C++

« kdy: 15. 02. 2014, 09:51:26 »

Záleží, jaký je to řízení.

V synchronním řízení nejdřív zapíšu a pak přečtu a dokud znova nezapíšu, nepotřebuju číst... třeba jako kdyby to byl http request, tak podobně... pak je to snadné, stačí jen volat WriteFile, ReadFile.

V asynchronním řízení, tedy pokud potřebuju trvale monitorovat port čtením a zároveň občas do něj i zapsat, pak doporučuju jednoznačně

• Otevřít to s příznakem OVERLAPPED a číst tímto způsobem
• a zároveň číst to v jiném vlákně

Protože při volání ReadFile se zamyká nějaký zámek na tom handle, nedá se volat WriteFile, když jiné vlákno visí v ReadFile. Proto je nutné mít OVERLAPPED, který způsobí, že vlákno nečeká v systémovém volání, ale na nějakém eventu.

Ono to sice jde číst v UI, ale z hlediska návrhu aplikace to není zrovna čisté řešení. Už jen proto, že musíte modifikovat smyčku pro čtení zpráv, což je zásah mající globální dopad na řízení běhu aplikace

Další možností je použít APC a v obsluze APC si poslat do okna zprávu pomocí PostMessage, která vydráždí UI vlákno k tomu, aby si načetla přijatá data.

217

Vývoj / Re:C++ a výjimka v destruktoru

« kdy: 14. 02. 2014, 23:04:56 »

Předpokládám, že

Kód: [Vybrat]

if (std::uncaught_exception()) return;

je chyba, ano? Takhle by ten catch block spolkl výjimku vždycky a ten test by tam vůbec nemusel být.

Není to chyba:
http://stackoverflow.com/questions/5952837/try-catch-block-substituted-for-a-method-block-in-a-destructor

due to ISO/IEC 14882:2003 15.3 [except.handle] / 16:

    The exception being handled is rethrown if control reaches the end of a handler of the function-try-block of a constructor or destructor. [...]

However it is legal to have a parameterless return in the handler of a function try block for a destructor - it is only forbidden in a function try block for a constructor - and this will supress the rethrow of the exception. So either of these alternatives would prevent the exception from leaving the destructor

Opět ne všechny překladače to umí

218

Vývoj / Re:C++ a výjimka v destruktoru

« kdy: 14. 02. 2014, 15:24:38 »

Taková perlička pro Stena a milovníky MSVC (2010)

Kód: [Vybrat]

ParallelExecutor2::~ParallelExecutor2() try {
	stopAll();
} catch (...) {
	if (std::uncaught_exception()) return;
}

class ParallelExecutor2::Worker {   //error C2911: 'LightSpeed::ParallelExecutor2::Worker' : cannot be declared or defined in the current scope
	public:
....
};

Ovšem po úpravě předchozího try catch bloku v destruktoru...

Kód: [Vybrat]

ParallelExecutor2::~ParallelExecutor2() { try {
	stopAll();
} catch (...) {
	if (!std::uncaught_exception()) throw;
} }

class ParallelExecutor2::Worker {
	public:
....
};

se to přeloží bez chyby

Evidentně MSVC parser C++ rozhodí zápis s try před tělem funkce. Gcc a v Clangu se to přeloží obojí

219

Vývoj / Re:C++ a výjimka v destruktoru

« kdy: 13. 02. 2014, 16:21:18 »

Volající musí přesně vědět, co se uvnitř děje. Pokud netuší, jaké výjimky může v tom zřetězení dostat, tak si s nima moc neporadí. Může leda tak vypsat uživateli what() a doufat že ten bude vědět, co s tím. Mimochodem, what je pro běžného uživatele programu užitečný jen hodně omezeně. Už jen lokalizovat se to dá fakt blbě. Pořádně se to dá akorát zalogovat a poslat vývojáři.

Běžně se to dělá tak, že se známé výjimky převedou na chybové hlášky.

Kód: [Vybrat]

void openDocument(const char *fname) {
 try {
    .....
 } catch (FileNotFoundException &e) {
      MessageBox(FormatMessage(IDS_SOUBORNEBYLNALEZEN, e.getFilename());
 } catch (AccessDeniedException &e) {
      MessageBox(FormatMessage(IDS_NEMATEPRISTUPKSOUBORU, e.getFilename());
 } catch (DocumentParseError &e) {
      MessageBox(FormatMessage(IDS_SOUBORNEBYLROZPOZNAN, e.getFilename());
 } catch (std::exeption &e) {
      LogError(e);
      MessageBox("Neznama chyba, kontaktujte vývojáře");
 }

}

220

Vývoj / Re:C++ a výjimka v destruktoru

« kdy: 13. 02. 2014, 16:09:26 »

Tím, že volající musí vědět co se uvnitř děje tak efektivně padá veškerá abstrakce.
...
Díky těm zřetězeným výjimkám musí každá úroveň programu do které ty výjimky můžou probublat vědět, co přesně se děje níž. Pokud to neví, tak vlastně nemá cenu ty výjimky ani házet.

To přece není pravda. To je jen tvrzení, které funguje na principu ode zdi ke zdi. Buď mám absolutní abstrakci a nemohu použít výjimky (a to si úplně nejsem jist pravdivostí tohoto tvrzení), nebo se musím vzdát abstrakce úplně. Nic mezi tím nevidíte.

Definice výčtu výjimek patří k definici rozhraní - malá poznámka pod čarou: jako rozhraní si můžete představit plně abstraktní třídu, nebo interface v javě. Každé rozhraní by mělo mít tzv. referenční implementaci, která ukazuje, jak se co má implementovat a mělo by 100% dodržovat pravidla rozhraní. Referenční implementace samozřejmě bude házet jen výjimky z výčtu, žádné jiné. To je ta abstrakce.

Bohužel nebo bohudík, rozhraní vznikají proto, aby skryly implementační detaily, nicméně to stejně nejde, protože už v implementaci nějakého rozhraní můžeme najít výrazné odlišnosti, úlevy a zkratky. Například rozhraní IPes má metodu VrtětOcasem(), tato metoda bude u objektu Buldok prázdná (buldok praktický nemá ocas). A to je ten lepší případ (čekali byste ze metoda IStream::closeOutput způsobí odeslání HTTP requestu pokud je tam HttpStream? No ale logiku to má, i když u TCPStreamu se spíš používá k uzavření spojení - příklad z knihovny LightSpeed).

To samé je to s výjimkami. Každý objekt by měl dodržovat rozhraní i na úrovni výjimek. Ale implementace se může začít potýkat s problémem, který na rozhraní definovaný není. Strojí před problémem. Má to vyhodit jako výjimku, která není na rozhraní definovaná? Nebo to má zabalit do jiné výjimky z nějaké existující, ke které to připojí Reason?

Opět příklad. HttpStream může vyhodit HttpStatusException. Ta ale na rozhraní IStream není definovaná. Tam je definovaná výjimka IOException. (zadání)

 Má se tato výjimka vyhazovat jako IOException a jako reason vložit HttpStatusException?

Opět záleží, jak předpokládáte, že se to bude používat. Předpokládám tuto hierarchii

Kód: [Vybrat]

 
 + - (1) otevírám HttpStream, chci si něco stáhnout
   + - (2) čtu soubor přes IStream (třeba to je parser JSONu, který pracuje nad obecným streamem)
     + - (3) při čtení obdržím status 500 Internal Server Error

Co chci? Chci na úrovni (2) odchytit IOException? Co s tím na té urovni budu dělat? Pokud je tam JSON parser, tak asi nic, ten to hodí dál. Může to také vyřešit tak, že z toho vybalí reason a ten hodí. Jenže JSON parser nemůže vědět, zda nad ním náhodou není někdo, komu by se třeba hodilo, aby to bylo IOException

Takže asi budu chtít na úrovni (1) odchytávat HttpStatusException.

V tomto případě bych asi pro HttpStream výjimku nebalil a i když není na úrovni rozhraní IStream definovaná. Nicméně mohu předpokládá, že ten, kdo si objednal čtení přes HTTP protokol, bude nejspíš vědět, jak s výjimkou HttpStatusException naložít, spíš než s chybou IOException.


Jak já to dělám? HttpStatusException dědí IOException. Ne vždy to ale takhle jde řešit.

221

Vývoj / Re:C++ a výjimka v destruktoru

« kdy: 12. 02. 2014, 22:17:01 »

To "zastaralé technologie"
Řešiče soustavy lineárních rovnic (MSC/Nastran, Boeing) se dodnes píší ve Fortranu...

opakuju:
Tím neříkám, že by C mělo být zatraceno úplně. V určitých situacích má své opodstatnění (stejně tak jako ten mechanický psací stroj)....

Konec flame.

222

Vývoj / Re:C++ a výjimka

« kdy: 12. 02. 2014, 21:38:53 »

Protoze ja mluvim celou dobu o osetrovani chyb pomoci errorkodu v C. VC. Chapu ze ve Vasi snaze me argumety ignorovat jste to pochopil tak, ze za cely zivot jsem se ucastnil 3 projektu vseho vsudy. PROTO jsem psal "v C".
Cela pointa toho odstavce byla ukazat Vam, ze nevite jak delat spolehlive a velke projekty v C.

Celé je to o tom, že se snažíte mne (a vlastně i sobě) dokázat, že umět čisté C je leet, je to něco co stojí za pozornost. Zatímco já si myslím, že umět jenom C je oslavovat zastaralé technologie a bát se těch nových. Takže v mých očích jste n00b i kdyby jste se naučil v C třeba silanizovat. Je to asi to samé, jako být spisovatel a vyžívat se v tom, jak umíte rychle a bezchybně psát na stroji a díky tomu se můžete řadit mezi elitu... zatímco ostatní píší dávno na počítačích a maximálně se vám vysmějou.

Tím neříkám, že by C mělo být zatraceno úplně. V určitých situacích má své opodstatnění (stejně tak jako ten mechanický psací stroj)....

(Představte si, že dokonce i jednočipy se programují v C++)

Jinak pokud Vim, iPhone pouziva ObjC, ne C.

To je sice možný, ale to jsem já nedělal, nehledě na tom, že celý projekt byl v Marmeládě, nicméně já jsem pracoval s originálními zdrojáky, které jsou v C a upravoval jsem je na konverzi (tu jsem ovšem nedělal).

223

Vývoj / Re:C++ a výjimka

« kdy: 12. 02. 2014, 17:28:05 »

Ano, jen 3. Projekt se navrhne, napise, odladi, spusti a udrzuje. Klicove slovicko, ktere jste zjevne zamerne ignoroval je "netrivialni". Napiste mi prosim, na kolika netrivialnich projektech (rekneme nad 50 000 radek), v C (ne C++) jste se podilel Vy.

Proč jenom v C? V C jsem napsal asi dva až tři velké projekty, když jsem zjistil, že takhle to dál nejde, a komplet jsem přesedlal na C++, kde mám spoustu projektů. Prostě nebudu se vracet ke starým technologiím, dokud vyloženě nemusím (naposledy při portování Skeldalu na iPhone, naštěstí jsem jen vypomáhal)

224

Vývoj / Re:C++ a výjimka

« kdy: 12. 02. 2014, 17:25:33 »

Ano, jen 3. Projekt se navrhne, napise, odladi, spusti a udrzuje. Klicove slovicko, ktere jste zjevne zamerne ignoroval je "netrivialni". Napiste mi prosim, na kolika netrivialnich projektech (rekneme nad 50 000 radek), v C (ne C++) jste se podilel Vy.

Nevím, nepočítal jsem to, budou to desítky. Když vezmu jen rok 1996-2000, tak ty tři hravě překonám (těch 50tis řádek beru jako rozhodující míru)

225

Vývoj / Re:C++ a výjimka

« kdy: 12. 02. 2014, 17:19:02 »

Výhodou výjimek je to, že fungují stejně třeba i ve Windows, kde není glib a ani GError

Prosim, budte tak laskav a neco si o glib zjistete. Jedna z hlavnich vyhod pro glib (a proc ji pouzivame), je to, ze je EXTREMNE dobre prenositelna mezi platformami - tj. na windows bezi uplne stejne dobre jako na linuxu. Je to normalni C knihovna. Dokonce nepotrebuje ani gcc.
Tj. nemate pravdu, glib s GErrorem je VSUDE, kde je C kompilator.

Prosím oddělme dvě věci. Jednou je Windows svět (se svým WinAPI, GDI, MFC, COM+ a jinými 3,14covinami), a podruhé je linuxový svět přeportovaný do Windows. To druhé vypadá jak pěst na voko, sorry.

Já už nebudu natahovat diskuzi na téma výjimky, nikam to nevede. Každý máme svou pravdu. Já bych se k systému bez výjimek nevracel ani omylem. Dokud tedy nemusím. Následující dva kódy ukazují, proč tomu tak je. Jedná se o program "hello world" napsaný pod mým systémem WebGUI (časem to bude openSource, možná na to bude článek - ale to je v celku jedno). První je v C++, kde se chyby ošetřují výjimkou. Druhý je napsaný v C, s patřičným ošetřením všech chyb.

Kód: [Vybrat]

#include <stdlib.h>
#include <memory>
#include <string.h>
#include "webgui/IClient.h"


static const char *hellotext = "Hello World";



int main(int argc, char **argv) {

	const char *webguiaddr = getenv("WEBGUI");
	if (webguiaddr == 0) {
		fprintf(stderr, "WEBGUI env variable is not defined\n");
		return 1;
	}

	try {
		std::auto_ptr<webgui::IClient> client(webgui::createClient());
		client->connect(webguiaddr);
		client->createWindow(client->getBaseUrl());
		std::auto_ptr<webgui::IRequest> r(client->getRequest(30000));
		if (r.get() == 0) {
			fprintf(stderr,"Timeout waiting on request\n");
		} else {
			r->setHeader("Content-Type","text/plain");
			r->write(hellotext,strlen(hellotext));
			r->closeOutput();
		}

	} catch (std::exception &e) {
		fprintf(stderr, "%s\n", e.what());
	}



}

Kód: [Vybrat]

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include "webgui/webgui_c.h"


static const char *hellotext = "Hello World";

static int showError() {
	fprintf(stderr,"Exception: %s\n",webgui_getLastErrorStr());
	webgui_clearError();
	return 100;
}


int main(int argc, char **argv) {

	WEBGUI_STR baseUrl;
	WEBGUI_CLIENT client;
	WEBGUI_REQUEST r;
	int err = 0;
	const char *webguiaddr = getenv("WEBGUI");
	//if doesnt exist, report error
	if (webguiaddr == 0) {
		fprintf(stderr, "WEBGUI env variable is not defined\n");
		return 1;
	}

	client = webgui_client_create();
	do {
		if (!webgui_connect(client,webguiaddr)) break;
		if (!webgui_getBaseUrl(client,&baseUrl)) break;
		if (!webgui_createWindow(client,&baseUrl)) break;
		r = webgui_getRequest(client,30000);
		if (r == 0) {
		   fprintf(stderr,"Timeout waiting on request\n");
		} else {
			do {
				if (!webgui_setHeader(r,"Conten-Type","text/plain")) break;
				if (!webgui_write(r,hellotext,strlen(hellotext))) break;
				if (!webgui_closeOutput(r))  break;
			} while (0);
			if (webgui_getLastErrorStr() != 0) {
				err = showError();
			}
			webgui_closeRequest(r);
		}
	} while (0);

	if (webgui_getLastErrorStr() != 0)
		err = showError();

	webgui_client_destroy(client);
	return err;



}

Pár poznámek k tomu co není vidět. C rozhraní je samozřejmě wraperem původního C++. Výjimky se tedy tady maskují ve funkci webgui_getLastErrorStr(). což je asi jediný rozumný způsob, jak přistupovat k chybě. Je pochopitelné, že proměnná, která drží chybu musí být vnitřně deklarovaná přes __thread (kdyby více vláken). Nemám tu chybové kódy, protože v celké knihovně není jediný (ale mám tam webgui_getLastErrorType(), která vrací řetězec identifikující typ chyby.

Já nevím, osobně mě to přijde jako hádat se, zda v HTML používat nebo nepoužívat tabulkový design.