Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: nemo1 17. 11. 2015, 15:28:14
-
Čím parsovat HTML v C++?
-
Parserem (http://lmgtfy.com/?q=c%2B%2B+html+parser)
-
Silou vůle. A nebo černou magií http://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags.
-
Čím parsovat HTML v C++?
Tak ja osobne bych na to pouzil html pareser urceny pro C++. Jinak opravdu to musi byt v C++?
Jinak pokud se lepe nezeptas tak ti tezko nekdo poradi. Chtelo by to vedet o jake HTML se jedna (verze). Co presne potrebujes aby to delalo, musi to byt OSS, ...
-
Přesně, lepší máš Javu.
-
Přesně, lepší máš Javu.
Nevíme nic o účelu - HTML parser se nachází téměř v každém jazyce. Když Java, tak klidně i Python nebo PHP.
Pokud to chce pro C++, tak je nejspíš masochistou, ale je to jeho volba.
-
Přesně, lepší máš Javu.
V čem je lepší ? Proč ne třeba Haskell?
-
Já na to mám jednoduchý procházeč XMLIterator , který jde použít i na HTML
https://github.com/ondra-novak/lightspeed/blob/master/src/lightspeed/utils/xmlparser.h
Je to jednoduchý SAX, který nevyžaduje definovat žádné callbacky. Naopak funguje jako java-like iterátor
XMLIterator xiter(...)
while (xiter.hasItems()) {
const XMLEntity &ent = xiter.getNext();
//do something with ent
}
Jediný problém je, že to je součástí tý knihovny a dost to využívá její vnitřnosti, takže budeš muset proniknout do taju tohoto obřího veledíla.
Chyby hlas prosím do issue trackeru.
:)
-
Přesně, lepší máš Javu.
V čem je lepší ? Proč ne třeba Haskell?
Java je prostě nejlepší! Proč myslíš, že je to nejpopulárnější jazyk...
Přesně, lepší máš Javu.
Nevíme nic o účelu - HTML parser se nachází téměř v každém jazyce. Když Java, tak klidně i Python nebo PHP.
PHP je paskvil, který vařil pejsek s kočičkou. Python je spíše tak na hraní, ale třeba by to ne moc dobře šlo také.
-
PHP je paskvil, který vařil pejsek s kočičkou. Python je spíše tak na hraní, ale třeba by to ne moc dobře šlo také.
Správní tvrďáci dělají s textem jedině v Perlu. :D
-
A za měsíc marně pátrají, co ten program asi tak dělá, protože tvrďáci komentáře nedělají :D
-
Přesně, lepší máš Javu.
V čem je lepší ? Proč ne třeba Haskell?
Protože není striktní. V Haskellu je těžké psát spolehlivý a efektivní kód - viz třeba Sometimes, the old ways are the best (http://www.serpentine.com/blog/2015/05/13/sometimes-the-old-ways-are-the-best/) (bug, který řešil Facebook):
decoding a mere megabyte of continuous backslashes took over a second, consumed over a gigabyte of memory, and killed concurrency by causing the runtime system to spend almost 90% of its time in the garbage collector.
Whatever was going on? If you look at the old implementation of aeson’s unescape function, it seems quite efficient and innocuous. It’s reasonably tightly optimized low-level Haskell.
Trouble is, unescape uses an API (a bytestring builder) that is intended for streaming a result incrementally. Unfortunately the unescape function can’t hand any data back to its caller until it has processed an entire string.
The result is as you’d expect: we build a huge chain of thunks. In this case, the thunks will eventually write data efficiently into buffers. Alas, the thunks have nobody demanding the evaluation of their contents. This chain consumes a lot (a lot!) of memory and incurs a huge amount of GC overhead (long chains of thunks are expensive).
Jinak řečeno v Haskellu nejde modulárně uvažovat o časové a paměťové složitosti.
-
A za měsíc marně pátrají, co ten program asi tak dělá, protože tvrďáci komentáře nedělají :D
Je docela uměním napsat komentáře, které dávají smysl. Když chci pochopit cizí program, tak z něj nejprve odstraním všechny komentáře a teprve pak začnu číst.
Komentáře jsou ve své podstatě zbytečné, neboť všechno důležité je zapsáno v kódu. Komentáře obvykle způsobují jen zmatky.
-
Přesně, lepší máš Javu.
V čem je lepší ? Proč ne třeba Haskell?
Java je prostě nejlepší! Proč myslíš, že je to nejpopulárnější jazyk...
Přesně, lepší máš Javu.
Nevíme nic o účelu - HTML parser se nachází téměř v každém jazyce. Když Java, tak klidně i Python nebo PHP.
PHP je paskvil, který vařil pejsek s kočičkou. Python je spíše tak na hraní, ale třeba by to ne moc dobře šlo také.
Proč by měl bejt python na hraní? Naopak se na tyhle věci náramně hodí, za pomoci beautifulsoup si s html můžu dělat co chci, na pár řádků si např vytvořím slovník inputů...
soup = BeautifulSoup(resp.content, "html.parser")
input_data = {}
for input in soup.find_all("input"):
input_data.update({input.get("name"): input.get("value")})
-
Java je prostě nejlepší! Proč myslíš, že je to nejpopulárnější jazyk...
Možná tak u firem, protože Javistů je jako s*aček. Na GitHubu s přehledem vede Ruby, Java je až šestá.
-
Přesně, lepší máš Javu.
V čem je lepší ? Proč ne třeba Haskell?
Java je prostě nejlepší! Proč myslíš, že je to nejpopulárnější jazyk...
Svého času byl nejpopulárnější VisualBasic. Takže v to je také nejlepší jazyk? :P
-
Na GitHubu s přehledem vede Ruby, Java je až šestá.
Máš poněkud neaktuální info (https://cloud.githubusercontent.com/assets/2623954/9098640/f15e22b4-3b7f-11e5-9496-12b6d811f0ea.jpg).
-
A za měsíc marně pátrají, co ten program asi tak dělá, protože tvrďáci komentáře nedělají :D
Je docela uměním napsat komentáře, které dávají smysl. Když chci pochopit cizí program, tak z něj nejprve odstraním všechny komentáře a teprve pak začnu číst.
Komentáře jsou ve své podstatě zbytečné, neboť všechno důležité je zapsáno v kódu. Komentáře obvykle způsobují jen zmatky.
To je ale hovadina. Zrejme jsi nedelal na zadnem kritickem kodu nikdy.
Casto je treba do kodu zabudovat ruzne optimalizace, ktere na prvni, ani na druhy pohled nejsou zjevne proc tam jsou. A tam jsou komentare veledulezite.
-
muzes pouzit regexpy (i kdyz je to blbost), libxml2 anebo webkit. Ono dost zalezi na tom co s tim HTML chces delat dal.
-
Na GitHubu s přehledem vede Ruby, Java je až šestá.
Máš poněkud neaktuální info (https://cloud.githubusercontent.com/assets/2623954/9098640/f15e22b4-3b7f-11e5-9496-12b6d811f0ea.jpg).
Jasně, a to vůbec nesouvisí s tím, že na Androidu se v ničem jinym defakto vyvíjet nedá, ten trend je takovej, protože je Java nejlepší!
-
Ale já přece nikde nic takového netvrdím. Dokonce Javu zrovna v lásce nemám :-D Jen jsem upozornil, že to info je neaktuální. Nebuď hned vztahovačný.
-
Ale já přece nikde nic takového netvrdím.
No ale já jo! Java je nejlepší, protože má garbage collector! Takže když v ní napíšeš garbage, tak tě zkolektivizuje.
-
https://wiki.qt.io/Handling_HTML - je to primarne o Qt, ale vacsina uvedeneho funguje pre C++ vseobecne, pokial dotycny C++ projekt Qt nepouziva.
-
Komentáře jsou ve své podstatě zbytečné, neboť všechno důležité je zapsáno v kódu. Komentáře obvykle způsobují jen zmatky.
To je ale hovadina. Zrejme jsi nedelal na zadnem kritickem kodu nikdy.
Casto je treba do kodu zabudovat ruzne optimalizace, ktere na prvni, ani na druhy pohled nejsou zjevne proc tam jsou. A tam jsou komentare veledulezite.
Nebavíme se o assembleru, kde jsou komentáře nutné, ale o běžně používaných programovacích jazycích.
-
Na GitHubu s přehledem vede Ruby, Java je až šestá.
Máš poněkud neaktuální info (https://cloud.githubusercontent.com/assets/2623954/9098640/f15e22b4-3b7f-11e5-9496-12b6d811f0ea.jpg).
Jasně, a to vůbec nesouvisí s tím, že na Androidu se v ničem jinym defakto vyvíjet nedá, ten trend je takovej, protože je Java nejlepší!
Java je nejlepší, protože funguje na všech platformách. A anální sex je taky nejlepší, protože funguje na všech pohlavích...
-
Komentáře jsou ve své podstatě zbytečné, neboť všechno důležité je zapsáno v kódu. Komentáře obvykle způsobují jen zmatky.
To je ale hovadina. Zrejme jsi nedelal na zadnem kritickem kodu nikdy.
Casto je treba do kodu zabudovat ruzne optimalizace, ktere na prvni, ani na druhy pohled nejsou zjevne proc tam jsou. A tam jsou komentare veledulezite.
Nebavíme se o assembleru, kde jsou komentáře nutné, ale o běžně používaných programovacích jazycích.
To je ve vsech jazycich stejne.
-
Komentáře jsou ve své podstatě zbytečné, neboť všechno důležité je zapsáno v kódu. Komentáře obvykle způsobují jen zmatky.
To je ale hovadina. Zrejme jsi nedelal na zadnem kritickem kodu nikdy.
Casto je treba do kodu zabudovat ruzne optimalizace, ktere na prvni, ani na druhy pohled nejsou zjevne proc tam jsou. A tam jsou komentare veledulezite.
Nebavíme se o assembleru, kde jsou komentáře nutné, ale o běžně používaných programovacích jazycích.
To je ve vsech jazycich stejne.
njn Kit a jeho uchylka nepsat komentáře a nepoužívat knihovny :-D Po něm musí bejt radost na něčem pracovat :-)
-
Komentáře jsou ve své podstatě zbytečné, neboť všechno důležité je zapsáno v kódu. Komentáře obvykle způsobují jen zmatky.
To je ale hovadina. Zrejme jsi nedelal na zadnem kritickem kodu nikdy.
Casto je treba do kodu zabudovat ruzne optimalizace, ktere na prvni, ani na druhy pohled nejsou zjevne proc tam jsou. A tam jsou komentare veledulezite.
Nebavíme se o assembleru, kde jsou komentáře nutné, ale o běžně používaných programovacích jazycích.
To je ve vsech jazycich stejne.
Správně zvolené názvy objektů|tříd|metod|rozhraní vydají za tucet komentářů. Když je někdo neumí pojmenovat, tak mu ani komentáře nepomohou.
-
Výstižně zvolené názvy by měly být standard. Komentáře ale patří tak nějak k "dobrému vychování", dalo by se říct. Osobně komentáře nepíšu jenom tam, kde se předpokládá, že se v tom kromě mě už nikdy nikdo hrabat nebude. Nekomentovat ovšem kódy, na kterých mám spolupracovat s dalšími lidmi, to bych si musel připadat s prominutím jako ko*ot.
Z kódu se samozřejmě dá pochopit, co dělá. Přečtení výstižného jednořádkového komentáře bude ale vždycky rychlejší, než luštění X řádků kódu.
Kromě toho(jak už tady zaznělo), někdy je potřeba řešit věci dost nestandardně, aniž by byla na první pohled zjevná příčina. To pak přijde takový Kit, "opraví" po mě tu "jasnou chybu" a aplikace v nejmíň vhodnou chvíli spadne.
-
Z kódu se samozřejmě dá pochopit, co dělá. Přečtení výstižného jednořádkového komentáře bude ale vždycky rychlejší, než luštění X řádků kódu.
Často je problém najít jednořádkové příkazy mezi X řádky komentářů. Takový program se fakt nedá číst.
Kromě toho(jak už tady zaznělo), někdy je potřeba řešit věci dost nestandardně, aniž by byla na první pohled zjevná příčina. To pak přijde takový Kit, "opraví" po mě tu "jasnou chybu" a aplikace v nejmíň vhodnou chvíli spadne.
Mé aplikace nepadají, nemají k tomu důvod. To sis musel s někým splést.
-
Jo tak. Já jsem si neuvědomil, že si píšu s neomylnou umělou inteligencí. Trochu jsem váhal, jestli třeba jenom netrolluješ, ale AI mě nenapadla. Tak to se pak omlouvám.
-
Jo tak. Já jsem si neuvědomil, že si píšu s neomylnou umělou inteligencí. Trochu jsem váhal, jestli třeba jenom netrolluješ, ale AI mě nenapadla. Tak to se pak omlouvám.
Obvykle stačí nepoužívat cízí neprověřené knihovny a frameworky. Když si takovou aplikaci řádně podložíš testy, nemá důvod k tomu, aby padala.
-
Kromě toho(jak už tady zaznělo), někdy je potřeba řešit věci dost nestandardně, aniž by byla na první pohled zjevná příčina. To pak přijde takový Kit, "opraví" po mě tu "jasnou chybu" a aplikace v nejmíň vhodnou chvíli spadne.
Mé aplikace nepadají, nemají k tomu důvod.
Ok, speciálně pro tebe to rozepíšu, máš evidentně problémy s pochopením psaného textu.
Příklad:
- Na nějaké platformě je bug.
- Nemůže se čekat, než se ho někdo za půl roku uráčí opravit.
- Sáhne se po nějakém nestandardním dočasném řešení.
- Přijde kit a smaže komentáře.
- Narazí na nestandardní řešení, u kterého si předtím smazal komentář.
- Řekne si, co to psalo za prase a domnělou "chybu" opraví.
- Aplikace díky tomu spadne, nejlíp při předváděčce klientovi(zákon schválnosti).
Jinak to, že píšeš naprosto bezchybné kódy ti fakt nežeru. Možná jde o to, o jak velkých kódech se bavíme - když jsem si kdysi psal prográmky o několika tisíci řádcích, tak se taky daly prohlásit víceméně za bezchybné.
-
Ok, speciálně pro tebe to rozepíšu, máš evidentně problémy s pochopením psaného textu.
Zabil :)
-
To je marný chlapče. Ty si žiješ v nějakým svojem programátorským tralalandu vzdáleným od reality a i když ti všichni tvrdí, že se pleteš, tak si stejně budeš mlet svojí. Není důvod drát si hubu. Dělej si to jak chceš, mám to na salámu.
-
To je marný chlapče. Ty si žiješ v nějakým svojem programátorským tralalandu vzdáleným od reality a i když ti všichni tvrdí, že se pleteš, tak si stejně budeš mlet svojí. Není důvod drát si hubu. Dělej si to jak chceš, mám to na salámu.
A ty si dál žij ve světě, ke chyba v jedné třídě/metodě/modulu způsobuje chyby v jiných částech aplikace.
-
Dojdi si na to oční a už mi s tím dej pokoj :-D
-
Ok, speciálně pro tebe to rozepíšu, máš evidentně problémy s pochopením psaného textu.
Prosim prectete si jeste jednou otazku a ujistete se jake se tema diskuze.
-
Výstižně zvolené názvy by měly být standard. Komentáře ale patří tak nějak k "dobrému vychování", dalo by se říct. Osobně komentáře nepíšu jenom tam, kde se předpokládá, že se v tom kromě mě už nikdy nikdo hrabat nebude. Nekomentovat ovšem kódy, na kterých mám spolupracovat s dalšími lidmi, to bych si musel připadat s prominutím jako ko*ot.
Z kódu se samozřejmě dá pochopit, co dělá. Přečtení výstižného jednořádkového komentáře bude ale vždycky rychlejší, než luštění X řádků kódu.
Kromě toho(jak už tady zaznělo), někdy je potřeba řešit věci dost nestandardně, aniž by byla na první pohled zjevná příčina. To pak přijde takový Kit, "opraví" po mě tu "jasnou chybu" a aplikace v nejmíň vhodnou chvíli spadne.
Komentare su dobre podla mna dobre na tie neobycajne riesenia a na vysvetlenie high-level konceptu.
Komentare sa dost casto naduzivaju a proti tomu som aj ja:
/** Increments given value by one
* this is only a stupid part of code, that gets an integer and adds one (1) to it
* floats and doubles are not supported, sorry
* int can be passed, but returned value will be long
* @param value to increment
* @return value after increment, or adding 1 to it
*/
public long incrementValueByOne(long valueToIncrement) {
// we will increment value here
// <3 ++C
return ++valueToIncrement;
// we could also use valueToIncrement + 1 and it should return the same value
}
pri poctivom citani komentov k funkcii vyssie zistite, ze tam este niekto zabudol nieco stare, davno neaktualne. To je druhy problem komentarov. Nazov funkcie by mal aspon v tomto pripade stacit (teda na to by ani nemusela byt funkcia).
-
Tak samozřejmě, pokud někdo k "1 + 1" napíše komentář "sečte jedna a jedna", pak to moc valný význam nemá. To je ale čistě opačný extrém k tomu, když někdo komentáře nepíše vůbec. Jinak když se třeba JavaDocy používají pro automatické generování dokumentace(samozřejmě ne takhle úmyslně zprzněné), pak má smysl mít je všude. Ale to je opravdu trochu offtopic, nechme to být.
-
Komentáře jsou ve své podstatě zbytečné, neboť všechno důležité je zapsáno v kódu. Komentáře obvykle způsobují jen zmatky.
Tak urcite, hodne stesti na projektu s delsi historii, kde treba komentare rikaji, ze to a to je kvuli bugu xy. Takovy regrese bys u nas zavlekl ze dve a sel bys ...
-
Komentáře jsou ve své podstatě zbytečné, neboť všechno důležité je zapsáno v kódu. Komentáře obvykle způsobují jen zmatky.
Tak urcite, hodne stesti na projektu s delsi historii, kde treba komentare rikaji, ze to a to je kvuli bugu xy. Takovy regrese bys u nas zavlekl ze dve a sel bys ...
Ukaž alespoň kousek kódu, který se bez komentáře neobejde.
Jinak si budu myslet, že u vás programují jen prasata, která se snaží svou neschopnost kompenzovat psaním komentářů.
-
Nakoukni třeba do linuxového jádra.
-
Nakoukni třeba do linuxového jádra.
Konkrétně kterou část máš na mysli?
-
Ukaž alespoň kousek kódu, který se bez komentáře neobejde.
methods.value = env->GetMethodID(annotationCls, "value", "()I");
᠁
/* Android bug 190058
* Annotation methods require one parameter on Android 6 eventough
* the method is declared without any. nullptr is a safe value. */
jvalue params[1];
params[0].l = nullptr;
env->CallIntMethodA(annotation, methods.value, params);
Bez komentáře nemáte šanci poznat, že posílání parametru metodě bez parametrů není chyba, ale workaround chyby.
-
Ukaž alespoň kousek kódu, který se bez komentáře neobejde.
methods.value = env->GetMethodID(annotationCls, "value", "()I");
᠁
/* Android bug 190058
* Annotation methods require one parameter on Android 6 eventough
* the method is declared without any. nullptr is a safe value. */
jvalue params[1];
params[0].l = nullptr;
env->CallIntMethodA(annotation, methods.value, params);
Bez komentáře nemáte šanci poznat, že posílání parametru metodě bez parametrů není chyba, ale workaround chyby.
Prave si ukazal jeden z mala pripadu kdy je opravdu komentar dulezitej. Bohuzel jsem zjistil ze se najdou i taci, kteri ho ignoruji a nemaji problem dany kod "opravit" :'(
-
Bez komentáře nemáte šanci poznat, že posílání parametru metodě bez parametrů není chyba, ale workaround chyby.
Proč by mělo být posílání parametru metodě chybou? I ze samotného zápisu vidím, že tam ten nullptr prostě potřebuje.
Co třeba ten zápis trochu pozměnit tak, aby tam ten komentář nebyl potřebný?
jvalue androidBug190058[1];
androidBug190058[0].l = nullptr;
env->CallIntMethodA(annotation, methods.value, androidBug190058);
Jinak ty názvy typů a objektů vypadají docela šíleně. To se nedivím, že k tomu někdo potřebuje komentáře. Například z názvu CallIntMethodA lze jen těžko rozluštit, zda "Int" je integer nebo internal a zda "A" znamená attribute nebo annotation. Z názvu "env" zase nepoznám, zda je to environment nebo třeba envelope.
-
Ukaž alespoň kousek kódu, který se bez komentáře neobejde.
methods.value = env->GetMethodID(annotationCls, "value", "()I");
᠁
/* Android bug 190058
* Annotation methods require one parameter on Android 6 eventough
* the method is declared without any. nullptr is a safe value. */
jvalue params[1];
params[0].l = nullptr;
env->CallIntMethodA(annotation, methods.value, params);
Bez komentáře nemáte šanci poznat, že posílání parametru metodě bez parametrů není chyba, ale workaround chyby.
Prave si ukazal jeden z mala pripadu kdy je opravdu komentar dulezitej. Bohuzel jsem zjistil ze se najdou i taci, kteri ho ignoruji a nemaji problem dany kod "opravit" :'(
Mi pripomelo situaci kdy jsem hledal v jednom souboru chybu a na konci souboru najdu toto:
// NEMAZAT!!!
// KDO TO SMAZE TOHO VLASTNORUCNE USKRTIM
// !!!POZOR!!! tento radek nesmite smazat jinak te nepojede
No a samozrejme pod timto komentarem nebylo nic, tak kouknu do historie gitu a vidim jak tam nekdo umazal radek a komentar v gitu ve stylu REF: smazam zbytecny nic nedelajici radek kodu
Takze se vracime k tomu ze komentare jsou vlastne zbytecne
-
Takze se vracime k tomu ze komentare jsou vlastne zbytecne
Hele, stat se to na mym projektu, pridu za korenem/koc a zeptam se proc to udelal a pak si vysvetlime, ze se ty komentare kolem fakt ctou ... udela to podruhy a uz to asi takto klidne neprojde. Prece to, ze delas s debilem neznamena, ze komentar nema smysl z principu. Cpat hinty do nazvu promenych etc je sice taky mozny, ale je treba dodrzovat jednotnej format, jinak se z toho clovek nevyhrabe.
-
Takze se vracime k tomu ze komentare jsou vlastne zbytecne
Hele, stat se to na mym projektu, pridu za korenem/koc a zeptam se proc to udelal a pak si vysvetlime, ze se ty komentare kolem fakt ctou ... udela to podruhy a uz to asi takto klidne neprojde. Prece to, ze delas s debilem neznamena, ze komentar nema smysl z principu. Cpat hinty do nazvu promenych etc je sice taky mozny, ale je treba dodrzovat jednotnej format, jinak se z toho clovek nevyhrabe.
Však to je jednotný formát. Přidám do názvu proměnné číslo bugu a je to. Alespoň to není jak ten nicneříkající název "params". To má být ten tvůj jednotný formát? Co je obsahem proměnné "params"? Nebo je to snad objekt? :)
-
Bez komentáře nemáte šanci poznat, že posílání parametru metodě bez parametrů není chyba, ale workaround chyby.
Proč by mělo být posílání parametru metodě chybou? I ze samotného zápisu vidím, že tam ten nullptr prostě potřebuje.
Protože ta metoda je deklarována int(), tedy vrací int a nemá žádné parametry.
Co třeba ten zápis trochu pozměnit tak, aby tam ten komentář nebyl potřebný?
jvalue androidBug190058[1];
androidBug190058[0].l = nullptr;
env->CallIntMethodA(annotation, methods.value, androidBug190058);
To je paráda, když musíte projít issue tracker Androidu, abyste u kódu zjistil, co vlastně znamená.
Jinak ty názvy typů a objektů vypadají docela šíleně. To se nedivím, že k tomu někdo potřebuje komentáře. Například z názvu CallIntMethodA lze jen těžko rozluštit, zda "Int" je integer nebo internal a zda "A" znamená attribute nebo annotation. Z názvu "env" zase nepoznám, zda je to environment nebo třeba envelope.
Int je návratová hodnota té metody. A znamená, že se tomu předává pole (array) parametrů. Je to standardní konvence JNI, kterou když znáte, tak k tomu právě žádné komentáře moc potřeba nejsou ;)
-
Proč by mělo být posílání parametru metodě chybou? I ze samotného zápisu vidím, že tam ten nullptr prostě potřebuje.
Protože ta metoda je deklarována int(), tedy vrací int a nemá žádné parametry.
Jaká metoda? Ta v methods.value? Proč je název té metody tak mizerný? "value"? Slovo "methods" mi říká, že by to mělo být nějaké pole či kolekce. Ejhle, není. Zase někdo zaspal.
jvalue androidBug190058[1];
androidBug190058[0].l = nullptr;
env->CallIntMethodA(annotation, methods.value, androidBug190058);
To je paráda, když musíte projít issue tracker Androidu, abyste u kódu zjistil, co vlastně znamená.
To jsem stejně musel, protože z toho komentáře to jasné nebylo.
Jinak ty názvy typů a objektů vypadají docela šíleně. To se nedivím, že k tomu někdo potřebuje komentáře. Například z názvu CallIntMethodA lze jen těžko rozluštit, zda "Int" je integer nebo internal a zda "A" znamená attribute nebo annotation. Z názvu "env" zase nepoznám, zda je to environment nebo třeba envelope.
Int je návratová hodnota té metody. A znamená, že se tomu předává pole (array) parametrů. Je to standardní konvence JNI, kterou když znáte, tak k tomu právě žádné komentáře moc potřeba nejsou ;)
"Int" a "A" vymysleli tvůrci JNI. S tím se nedá nic dělat. Ale to "env" jsi tam dal ty a mohl jsi to pojmenovat správně. Pokud se tedy tvému zaměstnanci nebudou líbit tvé hloupé názvy proměnných, tak ho vyhodíš? V tom případě si nedělám iluzi o kvalitách toho zbytku, který "šlape brázdu" a raději do toho nekecá.
-
Jaká metoda? Ta v methods.value? Proč je název té metody tak mizerný? "value"? Slovo "methods" mi říká, že by to mělo být nějaké pole či kolekce. Ejhle, není. Zase někdo zaspal.
Metoda se jmenuje „value“ (i v Javě) a její ukazatel je uložený ve struktuře „methods“, kde jsou ukazatele na metody pro danou třídu (protože resolvování ukazatelů metod se dělá při spuštění).
To jsem stejně musel, protože z toho komentáře to jasné nebylo.
Annotation methods require one parameter on Android 6 eventough the method is declared without any. nullptr is a safe value.
Co na tom není jasné?
"Int" a "A" vymysleli tvůrci JNI. S tím se nedá nic dělat. Ale to "env" jsi tam dal ty a mohl jsi to pojmenovat správně. Pokud se tedy tvému zaměstnanci nebudou líbit tvé hloupé názvy proměnných, tak ho vyhodíš? V tom případě si nedělám iluzi o kvalitách toho zbytku, který "šlape brázdu" a raději do toho nekecá.
env je konvence pro parametr obsahující ukazatel na JNIEnv. (https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/functions.html)
Můžete si samozřejmě vymyslet vlastní konvence, ale míchání různých konvencí je pěkná prasárna. Pokud máte problémy dodržovat konvence, nedělám si iluzi o kvalitě vašeho kódu.
-
Vyserte se už na to...
-
Jaká metoda? Ta v methods.value? Proč je název té metody tak mizerný? "value"? Slovo "methods" mi říká, že by to mělo být nějaké pole či kolekce. Ejhle, není. Zase někdo zaspal.
Metoda se jmenuje „value“ (i v Javě) a její ukazatel je uložený ve struktuře „methods“, kde jsou ukazatele na metody pro danou třídu (protože resolvování ukazatelů metod se dělá při spuštění).
Název "value" je pěkně blbý název pro metodu. Obvykle se metody pojmenovávají slovesem.
JNIEnv nepoužívám. Pokud je "env" uznávanou konvencí, tak musím konstatovat, že žádnou proměnnou dle tvé konvence nevidím. Pouze předvádíš cizí pírka, ale se svou kůží na trh nejdeš. Tím končím.
-
se svou kůží na trh nejdeš
srsly?
-
Název "value" je pěkně blbý název pro metodu. Obvykle se metody pojmenovávají slovesem.
Takhle se prostě jmenují metody anotací v Javě. Opět jde o konvenci, kterou jsem nevymyslel.
JNIEnv nepoužívám. Pokud je "env" uznávanou konvencí, tak musím konstatovat, že žádnou proměnnou dle tvé konvence nevidím. Pouze předvádíš cizí pírka, ale se svou kůží na trh nejdeš. Tím končím.
Proměnné dle mé konvence jsou třeba annotation, params nebo ta struktura methods. Navíc jsem reagoval na tvrzení, že v kódu nikdy není potřeba komentář, o nějaká konvence vůbec nešlo, tak co bych měl předvádět?
-
Kit: Ty seš fakt mimoň, až to bolí.
-
ja pouzivam dost dlho http://htmlcxx.sourceforge.net/
-
Přesně, lepší máš Javu.
Nevíme nic o účelu - HTML parser se nachází téměř v každém jazyce. Když Java, tak klidně i Python nebo PHP.
Pokud to chce pro C++, tak je nejspíš masochistou, ale je to jeho volba.
nedramatizujte, http://htmlcxx.sourceforge.net/ je jednoduche riesenie pre C++
-
Kit: Ty seš fakt mimoň, až to bolí.
Klid, Kit je tu známý troll, co programování moc nerozumí. Nejlepší ho ignorovat ;)
-
Pak se zase nezasměješ. To je jako schovat Babicu mimo televizi. Ty jeho hlody prostě nevymyslíš :D