abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
včera 23:55 | Komunita

Mozilla oznámila, že projekt Things byl přejmenován na WebThings. Nové jméno by mělo zdůraznit, že se nejedná pouze o projekt IoT (Internet věcí), ale o WoT (Web věcí). Současně byla vydána WebThings Gateway (GitHub) ve verzi 0.8 pro Raspberry Pi.

Ladislav Hagara | Komentářů: 0
včera 21:11 | Nová verze

Byl vydán balík KDE Aplikace ve verzi 19.04. Shrnuje práce za poslední čtyři měsíce: opravy chyb, mj. ve správci souborů Dolphin, prohlížeči dokumentů (nejen PDF) Okular nebo prohlížeči obrázků Gwenview – tyto dostaly např. lepší podporu dotykových obrazovek. Významného přepracování se dočkal editor videa Kdenlive.

Fluttershy, yay! | Komentářů: 0
včera 16:22 | Nová verze

Byla vydána verze 19.04 linuxové distribuce Ubuntu a oficiálních odnoží Ubuntu Budgie, Kubuntu, Lubuntu, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio a Xubuntu. Kódový název Ubuntu 19.04 je Disco Dingo. Přehled novinek a odkazy ke stažení v poznámkách k vydání. Ubuntu 19.04 bude podporováno 9 měsíců, tj. do ledna 2020.

Ladislav Hagara | Komentářů: 6
včera 09:55 | Nová verze

Byla vydána verze 8.0 sady aplikací pro SSH komunikaci OpenSSH. Řešena je bezpečnostní chyba CVE-2019-6111 v scp. Přidána byla experimentální podpora výměny klíčů, která je odolná vůči kvantovým počítačům (Streamlined NTRU Prime 4591^761 a X25519). Výchozí délka nově generovaných RSA klíčů je 3072 bitů.

Ladislav Hagara | Komentářů: 0
17.4. 22:44 | Komunita

Zend Framework, open source objektově orientovaný webový aplikační framework implementovaný v PHP, byl předán neziskovému technologickému konsorciu Linux Foundation. Framework se pod novým názvem Laminas v průběhu několika měsíců stane oficiálním projektem konsorcia.

Ladislav Hagara | Komentářů: 4
17.4. 22:00 | Komunita

Gentoo Foundation a společnost Nitrokey společně oznámily, že všichni vývojáři linuxové distribuce Gentoo budou vybaveni kryptografickým tokenem Nitrokey Pro 2 (pdf). Vývojáři se mají zaregistrovat s emailovou adresou @gentoo.org.

Ladislav Hagara | Komentářů: 0
17.4. 20:55 | Zajímavý software

Článek na PIXLS.US představuje svobodný program pro zpracování astronomických fotografií s názvem Siril (GitLab) a uvádí postup, jak v Siril vytvořit hezký snímek noční oblohy.

Ladislav Hagara | Komentářů: 0
17.4. 10:11 | Nová verze

Laboratoře CZ.NIC vydaly novou verzi 4.13.0 aplikace Datovka, tj. svobodné multiplatformní desktopové aplikace pro přístup k datovým schránkám a k trvalému uchovávání datových zpráv v lokální databázi. Nové vlastnosti: U existujícího účtu lze změnit přihlašovací jméno. Podmínkou je, že starým i novým jménem se přihlašuje do stejné datové schránky. Aplikace dovoluje volitelné automatické nahrávání nově stažených datových zpráv do

… více »
Ladislav Hagara | Komentářů: 36
17.4. 01:11 | Zajímavý software

Mozilla na svém blogu Mozilla Hacks věnovaném vývojářům představila projekty Iodide a Pyodide. Iodide umožňuje nejenom vědcům vytvářet interaktivní dokumenty pomocí webových technologií. Viz například Lorenzův atraktor. Rádi byste něco upravili? Stačí kliknout na tlačítko EXPLORE. Po úpravě na tlačítko REPORT. Pyodide přidává do Iodide podporu programovacího jazyka Python a souvisejících knihoven. Na straně klienta není nutné nic instalovat. K vyzkoušení je demo.

Ladislav Hagara | Komentářů: 2
16.4. 23:44 | IT novinky

ČVUT má nejvýkonnější superpočítač pro výzkum umělé inteligence v ČR. Fakulta elektrotechnická a Fakulta informačních technologií ČVUT v Praze spojily své síly a založily Výzkumné centrum informatiky (Research Center for Informatics – RCI). V rámci projektu byl vybudován nejvýkonnější počítačový klastr pro výzkum umělé inteligence v ČR v hodnotě 41,6 milionu korun. Toto jedinečné zařízení, které se svým výkonem řadí mezi superpočítače, se nachází v podzemí historické budovy Fakulty elektrotechnické ČVUT na Karlově náměstí.

Ladislav Hagara | Komentářů: 16
Používáte headset pro virtuální realitu?
 (1%)
 (2%)
 (1%)
 (20%)
 (0%)
 (75%)
Celkem 209 hlasů
 Komentářů: 12, poslední včera 01:19
Rozcestník

Dynamické pole (C)

31.3. 23:34 | Přečteno: 1792× | Programování | poslední úprava: 31.3. 23:27

Zápisek má charakter poznámek.

Pole funguje na základě pointerové aritmetiky a memcpy. Typ void* - ztráta kontroly při přetypování a nelze použít pointerovou aritmetiku.

Interface:

array.h
typedef struct Array Array;

extern Array *Array_new(int size);
extern void Array_push(Array *p, void *v);
extern void *Array_get(Array *p, int i);
extern int Array_len(Array *p);
extern void Array_free(Array **p);
array.c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include "array.h"

struct Array {
	int size;
	int cap;
	int len;	
	char *array;	
};

Array *Array_new(int size)
{
	Array *p;
	
	p = malloc(sizeof(Array));	
	p->size = size;
	p->cap = 0;
	p->len = 0;
	p->array = NULL;
	
	return p;
}

void Array_push(Array *p, void *v)
{
	char *newarray;
	
	if (p->array == NULL) {
		p->array = malloc(p->size);		
		p->cap = 1;		
	} else if (p->len >= p->cap) {
		p->cap *= 2;
		newarray = realloc(p->array, p->cap * p->size); 
		p->array = newarray;		
	}	
	memcpy(p->array + p->size * p->len, v, p->size);	
	p->len++;
}

void *Array_get(Array *p, int i)
{
	return p->array + p->size * i;
}

int Array_len(Array *p)
{
	return p->len;
}

void Array_free(Array **p)
{
	free((*p)->array);
	free(*p);
	*p = NULL;
}
Aby položky struktury byly privátní, vidí klient pouze neúplný typ. *A_ints je opaque pointer:
#include <stdio.h>
#include "array.h"

int main()
{
	Array *A_ints;
	
	A_ints = Array_new(sizeof(int));
	
	A_ints->len = 100;

	/*Preklad selhal.*/
Použití:
#include <stdio.h>
#include "array.h"

void fill_arrays(Array *a1, Array *a2);
void print_arrays(Array *a1, Array *a2);

int main()
{
	Array *A_ints, *A_floats;
	
	A_ints = Array_new(sizeof(int));
	A_floats = Array_new(sizeof(float));
	
	fill_arrays(A_ints, A_floats);
	print_arrays(A_ints, A_floats);

	Array_free(&A_ints);
	Array_free(&A_floats);	
	
	return 0;
}

void fill_arrays(Array *a1, Array *a2)
{
	int i;
	float f = 1.1;
	
	for(i = 0; i < 15; i++)
		Array_push(a1, &i);
	
	for(i = 0; i < 10; i++) {		
		Array_push(a2, &f);
		f += f;
	}	
}

void print_arrays(Array *a1, Array *a2)
{
	int i;
	
	for(i = 0; i < Array_len(a1); i++)
		printf("%d, ", *(int*)Array_get(a1, i));
	printf("\n\n");	
	for(i = 0; i < Array_len(a2); i++)
		printf("%.1f, ", *(float*)Array_get(a2, i));	
}


0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 

1.1, 2.2, 4.4, 8.8, 17.6, 35.2, 70.4, 140.8, 281.6, 563.2, 
Ošetřit návratové hodnoty u malloc. Array_get assert neplatný index. Velikosti typu size_t.        

Hodnocení: 50 %

        špatnédobré        

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

1.4. 02:41 Mrkva
Rozbalit Rozbalit vše Re: Dynamické pole (C)
A couple Treba zmin5 o jaký jazyk se jedná?
1.4. 02:51 debian+
Rozbalit Rozbalit vše Re: Dynamické pole (C)
Je to programovaci jazyk C.
1.4. 02:50 debian+
Rozbalit Rozbalit vše Re: Dynamické pole (C)
Osetrit navratnu hodnotu realloc.
Pri funkciach osetrit, ze parametrom moze byt NULL.
size_t len pouzit v strukture.
void * sa da pouzit pointerova aritmetika, ale tu nepotrebujes pouzit.
miesto p->cap *= 2; pouzi (mozes) p->cap << 1.
1.4. 08:52 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Dynamické pole (C)
miesto p->cap *= 2; pouzi (mozes) p->cap << 1
K tomu dvě poznámky: Jednak by to mělo p->cap <<= 1 a jednak bych to vůbec nedělal, nemá to IMHO moc smysl. Kompilátor to případně dokáže sám zoptimalizovat, pokud to má smysl.
1.4. 13:01 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: Dynamické pole (C)
jednak bych to vůbec nedělal, nemá to IMHO moc smysl.

Urcite bych to nedelal a je to velke zlo. Jednak to zastira skutecny zamer programatora, tj. ze chtel nasobit dvema, takze ten, kdo ten kod bude cist po nem, bude muset lustit, o co vlastne slo. A jednak mikrooptimalizace tohoto typu by mel delat vzdy prekladac, protoze ten vi nejlip, jak v danem kontextu a na danem procesoru nejlip/nejrychleji nasobit dvema (jen na x86 jsou k tomu tri instrukce ADD, SHL, LEA, pripadne MUL ;-]).

Dalsi vec je, ze s tim clovek muze napachat vic skody nez uzitku. Napriklad znam cloveka, ktery i v C pouziva (X XOR X) k nastaveni hodnoty na 0. Nejspis protoze v davnych casech to byla rychlejsi (a myslim i kratsi) instrukce. Problem je, ze nektere novejsi procesory ten idiom nerozpoznaly, videly tam zavislost v kodu, coz jim zkomplikovalo register renaming a program nakonec jel pomaleji nez mohl.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
1.4. 11:44 debian+
Rozbalit Rozbalit vše Re: Dynamické pole (C)
typedef struct Array Array;
Mas 2 krat za sebou Array. To nie je az tak citatelne prehladne. Prave pre ten riadok ale aj vseobecne, za zvykne definovat datovy typ definovat so sufixom _t. A vtedy je jasne, ze v kode je to premenna/struktura a kedy len definovany typ. U strukt niekde najdes aj prefix st_.
1.4. 13:07 sad
Rozbalit Rozbalit vše Re: Dynamické pole (C)
Díky za rady a připomínky. Nevím, zda se ten suffix _t hodí zrovna k uživatelským rozhraním. Například FILE je také bez suffixu a uživatel jej používá, aniž by tušil, co se za ním skrývá. Na druhou stranu u size_t mi ten prefix dává docela smysl.
1.4. 18:19 debian+
Rozbalit Rozbalit vše Re: Dynamické pole (C)
Nevím, zda se ten suffix _t hodí zrovna k uživatelským rozhraním.
Tak to ries nasledovne:
typedef struct Array_t Array;
To je vec kodu. V GTK mas GtkWidget. Lenze tym sa furt pracuje, resp. to je take identicky pre GTK.

Napr. velkostne datove typy pre multiplatformove (vid) ma tiez.

FILE zas rozlisuje velkym, cize v kode to je prehladne.

Hm, prefix st_ sa nepouziva pre struktury. To sa pouziva v strukture stat. Aj ked nic ti nebrani pouzivat ten prefix inde.
Agent avatar 1.4. 15:42 Agent | HC city
Rozbalit Rozbalit vše Re: Dynamické pole (C)
Nejedná se o nějaký ftípek, když je toho Apríla..
Nevěděl zpočátku, co si počít, jak žít, co dělat, ale brzy se vpravil do role samotáře.
1.4. 18:34 debian+
Rozbalit Rozbalit vše Re: Dynamické pole (C)
V .h subore nemas osestrene voci viac-nasobnemu vkladani. Pri viacnasobnom vkladani nastava konflikt, ze definujes nieco, co je uz inde definovane. Robi sa to takto:
#ifndef NAZOV_SUBORU_H
#define NAZOV_SUBORU_H

/* obsah suboru */

#endif
V Array_new() a Array_push() neoverujes malloc().

Pred a po pouzity nuluj pamet. Cez bzero() alebe memset(). Kvoli bezpecnosti - citanie ineho obsahu programu. Ty mozes pred niekym (co ako ked vytvaras a la kniznicu, tak otvoras priestor tym, kt. to budu pouzivat), alebo niekto moze po tebe.

Preco ked prepisem cisla 15 a 10, vystup programov je vzdy rovnaky?

Pokial sa pocet prvkov nemeni, tak nepouzivaj vo for funkciu a la count(). Ale tu zavolaj pred a hodnotu si uloz do pamete. A nasledne vo for citaj z premennej. Inac musi pri kazdom cykle volat funkciu a la count(), ked vzdy vrati rovnaku hodnotu.

Pikoska:
p->cap = 0;
p->len = 0;
sa da zapisat (mozes sa s tym stretnut):
p->cap = p->len = 0;
1.4. 19:12 sad
Rozbalit Rozbalit vše Re: Dynamické pole (C)
To, že jsem zapomněl do hlavičkového souboru přidat #ifndef, jsem si uvědomil až ráno :-)

Jestliže přepíšeš 15 a 10, tak výstup stejný určitě nebude, protože v tom cyklu na výpis je právě ta funkce Array_len, a asi máš pravdu, že by se nemusela volat při každém průchodu, ačkoliv nedělá nic náročného, pouze vrací proměnou.

Vynulovat paměť před uvolněním memsetem - to je dobrá připomínka, to jsem nevěděl, dík.

1.4. 21:48 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: Dynamické pole (C)
Vynulovat paměť před uvolněním memsetem - to je dobrá připomínka, to jsem nevěděl, dík.
Ne, neni to dobra pripominka.

Drz se zasady, ze kazda funkce by mela delat jednu vec a delat ji poradne. V tomto pripade dela dve veci -- jednak uvolni pamet, jednak ji vynuluje (na kazdy potrebuje pamet mit vynulovanou).

Pricemz to nulovani pameti je uplne zbytecne. Jsou to zbytecne provedene operace a hlavne zasvinena cache. (Nulovanim se ti do cache dostanou data, se kterymi uz nebudes pracovat a odstranis ta pouzivana.)

Ke vsemu to z pohledu bezpecnosti vubec nic neresi, aby ses dostal k uvolnene pameti, musis bud pouzit jiz jednou uvolnenou pamet (coz je chyba), musis pouzit neinicializovanou pamet (coz je chyba), pristoupit k pameti, ke ktere bys nemel mit pristup (napr. prekrocit hranici pole, coz je opet chyba). Takze v kazdem pripade mas v programu vaznejsi chybu, kterou bys mel resit a kterou vynulovani urcite casti pameti vubec nevyresi.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
2.4. 08:41 Kate | skóre: 9
Rozbalit Rozbalit vše Re: Dynamické pole (C)
Nebo může místo #ifndef / #define použít #pragma once. Drtivá většina kompilerů to podporuje :)
2.4. 12:36 Semo | skóre: 44 | blog: Semo
Rozbalit Rozbalit vše Re: Dynamické pole (C)
V zasade nehovoris blbosti, ale zaspal si aspon 20 rokov dobu. Pis programy tak, aby sli dobre citat. Optimalizatory v dnesnych kompilatoroch su v optimalizovani lepsie ako 95% programatorov. Odvodit, ze return value Array_len() sa nemeni dokaze aj kadejaky podradny kompilator. Pokial sa treba ohanat autoritou, tak Knuth:
The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.
A to Knuth programoval v casoch, ked kompilatory zdaleka nedokazali optimalizovat tak dobre ako dnes.

Pri recyklovani pamate v ramci jedneho processu nulovat pamet pri free() je prasarna pre cache (to si tu uz vysvetlili). Pri malloc() maximalne v debug verzii pre deterministicke chovanie pri chybach prace s pamatou. Pri free() sa vtedy dava viac specificka hodnota, napr. 0xDEADBEEF.

A keby som chcel byt privacy-paranoik medzi procesmi tak si myslim, ze tych par supercitlivych bytov (kluce napr.) si moze uzivatel vynulovat explicitne.
If you hold a Unix shell up to your ear, you can you hear the C.
1.4. 18:44 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Dynamické pole (C)
Ještě poznámka: Kromě těch věcí, co už tu padly, při konvertování různých typů na syrové buffery a nazpátek lidi často zapomínaj na jednu zarovnání (alignment).

Z tohohle důvodu IMHO ta metoda void *Array_get() je špatná, respektive je špatné následné přetypování a dereference pointeru na konkrétní typ (kde slovem "špatný" mám na mysli undefined behaviour).

Správně bys měl buď zajistit korektní zarovnání toho interního bufferu, nebo případně použít memcpy() na čtení prvku místo přímého přetypování pointeru, ale to je docela nešikovné.

V tom případě s těmi integery to asi reálně nějaký závažný problém typu SIGBUS nevyvolá. Na nějaké jiné platformě nebo při použití složitější struktury nebo za nějakých jiných podmínek by to padat IMHO mohlo. Případně to může vést ke snížení výkonu.
1.4. 18:45 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Dynamické pole (C)
*zapomínají na zarovnání
1.4. 19:44 sad
Rozbalit Rozbalit vše Re: Dynamické pole (C)
No tak díky. Dobře, že to vím. Ale radost mi to neudělalo.
1.4. 20:09 sad
Rozbalit Rozbalit vše Re: Dynamické pole (C)
Takže použít aligned_alloc?
2.4. 08:19 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Dynamické pole (C)
Ne, malloc() zřejmě stačí, viz níže.
2.4. 05:07 kvr
Rozbalit Rozbalit vše Re: Dynamické pole (C)
Není. sizeof() bere v úvahu zarovnání největšího prvku. Například struct { int x; char a; } bude mít velikost 8 bytes (na běžných ILP32 a LP64), právě proto, aby malloc na n*sizeof fungoval korektně.
2.4. 08:19 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Dynamické pole (C)
sizeof() v tomhle nijak nepomůže, ale koukám teď, že malloc() to řeší tak, že prostě alokuje s maximálním zarovnáním pro všechny fundamentální typy (max_align_t), takže pokud člověk nemá specielní požadavky, malloc() stačí.
2.4. 15:00 sad
Rozbalit Rozbalit vše Re: Dynamické pole (C)
Zkusil tuto strukturu:
typedef struct large {
	struct point {
		int x[100];
		int y[100];
		int z;
	} s;
	float f;
	long l;
} Large;
Dle sizeof velikost 816 bytů. Alokoval jsem pole o milionu prvků a zjevně to funguje správně.
2.4. 15:15 sad
Rozbalit Rozbalit vše Re: Dynamické pole (C)
Zkusil jsem tuto...
2.4. 19:36 kvr
Rozbalit Rozbalit vše Re: Dynamické pole (C)
sizeof() je součást, předává správnou velikost struktury, v důsledku je třeba použít adekvátní alignment. Pokud si dobře pamatuju, minimální malloc alignment je na x86 8 bytes (obecně 2*sizeof(void *) ), ale pro větší struktury je třeba zajistit alignment 16 bytes - kvůli SSE mov-aligned instrukci.
2.4. 19:48 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Dynamické pole (C)
Nerozumim přesně, co chceš říct - v tom příkladu v blogu by ses spokojil s tím, co dělá malloc(), nebo zajistil větší zarovnání?
3.4. 04:02 kvr
Rozbalit Rozbalit vše Re: Dynamické pole (C)
Pardon, vypadla mi tam podstatná část. Funkce malloc je schopna detekovat podle parametru (který jde obvykle ze sizeof), že výsledek může vyžadovat větší alignment. Takže pro size < 16 bytes vrátí zarovnání klidně na 8 bytes, ale pro size >= 16 zarovná na 16 bytes, bo paměť může být potenciálně využita na SSE move-aligned instrukci. Ještě k původnímu - role sizeof() je samozřejmě důležitá i v tom, že i další elementy v poli budou správně zarovnány
3.4. 09:24 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: Dynamické pole (C)
Funkce malloc je schopna detekovat podle parametru (který jde obvykle ze sizeof), že výsledek může vyžadovat větší alignment. Takže pro size < 16 bytes vrátí zarovnání klidně na 8 bytes, ale pro size >= 16 zarovná na 16 bytes, bo paměť může být potenciálně využita na SSE move-aligned instrukci.

Zadna takova detekce se nedeje. Pokud si nestanovis jinak, standardni malloc (ptmalloc) zarovnava na dvojnasobek slova (tj. na 64 bitech na 16 B) a minimalni mnozstvi alokovane pameti (bez rezie) je opet dvojnasobek slova (to je dane tim, jak se pracuje s uvolnenymi bloky).
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
3.4. 09:45 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Dynamické pole (C)
Funkce malloc je schopna detekovat podle parametru (který jde obvykle ze sizeof), že výsledek může vyžadovat větší alignment. Takže pro size < 16 bytes vrátí zarovnání klidně na 8 bytes, ale pro size >= 16 zarovná na 16 bytes
Aha, jo tak, díky za vysvětlení.
Ještě k původnímu - role sizeof() je samozřejmě důležitá i v tom, že i další elementy v poli budou správně zarovnány
Jasně, rozumim, co chceš říct, akorát jsem spíš jen rejpal v tom smyslu, že sizeof sám o sobě jen vrátí velikost, to správné zarovnání ve strukturách je dané paddingem (příp. správným řazením prvků).
3.4. 12:18 debian+
Rozbalit Rozbalit vše Re: Dynamické pole (C)
sizeof() je součást, předává správnou velikost struktury, v důsledku je třeba použít adekvátní alignment.
Pre tych ktory nehladali, mozne riesenie ako to pravit: https://en.wikipedia.org/wiki/Data_structure_alignment
2.4. 08:18 pc2005 | skóre: 37 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: Dynamické pole (C)
Když už se tu bavíme o strukturách a zarovnání, teďka řeším problém jaderného modulu, kde big endian CPU komunikuje s little endian řadičem. Jak byste napsali packované struktury pro komunikační protokol a MMIO registry tak, aby to nebyla prasárna ale zároveň, aby to byla co nejvíc sebepopisná definice?

Originální soft si definuje zapackovanou strukturu a před memcpy použije endian konverzní makra pro každou dvou a více bajtovou položku:
packet.u16Flag = cpu_to_le16(packet.u16Flag);
To mě přijde strašně náchylné na zapomenutí té konverze.
2.4. 12:18 Semo | skóre: 44 | blog: Semo
Rozbalit Rozbalit vše Re: Dynamické pole (C)
Tak si na vsetky druhy kopirovania napis wrappery, pouzivaj striktne len tie a optimalizator si uz poradi.

Na nezarovnanych packovanych strukturach na Solarise na SPARC T4 som si kedysi dobre nabil hubu a dlho mi trvalo, kym som pochopil v com je problem. Dovtedy (a ani odvtedy) som nikdy SIGBUS nevidel. Na Windows to fungovalo, na Linuxe (oboje x64) to fungovalo, na Solarise som sa s tym strasne sral.
If you hold a Unix shell up to your ear, you can you hear the C.
2.4. 13:18 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Dynamické pole (C)
Tak si na vsetky druhy kopirovania napis wrappery, pouzivaj striktne len tie a optimalizator si uz poradi.
Případně by asi šlo to nějak generovat.
3.4. 00:54 pc2005 | skóre: 37 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: Dynamické pole (C)
Dík oběma, nějaká forma wrapperu, generovaného třeba makrem mě taky napadla. Ono je blbý, že u toho hardware neexistuje popis použitého API.

Škoda, že Cčko neumožňuje definovat i typy pro jiné endianity a styly packování na jiných architekturách.
3.4. 15:14 debian+
Rozbalit Rozbalit vše Re: Dynamické pole (C)
Napis vyvojarom gcc, nech implementuju rozsirenie, ktore prida specifikuje endianove datove typy.
xkucf03 avatar 3.4. 18:12 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Kam psát hvězdičku u proměnných typu ukazatel?

Nechci vyvolávat flame, ale přijde mi lepší psát hvězdičku k typu než k názvu proměnné. Chápu, že i u toho názvu dává svým způsobem smysl, ale myslím si, že víc patří k typu (proměnná je typu ukazatel).

Někdo to pak řeší tak, že píše hvězdičku doprostřed (mezery na obou stranách). Schválně můžeš přidat anketu :-)

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Relational pipes
3.4. 18:21 JS1 | skóre: 2 | blog: intuition_pump
Rozbalit Rozbalit vše Re: Kam psát hvězdičku u proměnných typu ukazatel?
Ja to tedy vzdycky pisu k promenne, protoze kdyz chci napsat:

char *p1, *p2;

Tak to je neco jineho (aspon jak si pamatuji C) nez:

char* p1, p2;
Lidstvo má již jen 12 let, aby odvrátilo nejhorší důsledky klimatické katastrofy. Podpořte výzvu na proplanetu.cz!
xkucf03 avatar 3.4. 18:29 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: Kam psát hvězdičku u proměnných typu ukazatel?

Vím, tohle je pěkná záludnost, ale vzhledem k tomu, že to většinou rozepíšu tak, aby na každém řádku byla jen jedna proměnná, tak mě to až tolik netrápí.

BTW: teď jsem k tomu našel Is ``int* p;'' right or is ``int *p;'' right?:

The choice between ``int* p;'' and ``int *p;'' is not about right and wrong, but about style and emphasis. C emphasized expressions; declarations were often considered little more than a necessary evil. C++, on the other hand, has a heavy emphasis on types.

A ``typical C programmer'' writes ``int *p;'' and explains it ``*p is what is the int'' emphasizing syntax, and may point to the C (and C++) declaration grammar to argue for the correctness of the style. Indeed, the * binds to the name p in the grammar.

A ``typical C++ programmer'' writes ``int* p;'' and explains it ``p is a pointer to an int'' emphasizing type. Indeed the type of p is int*. I clearly prefer that emphasis and see it as important for using the more advanced parts of C++ well.

Podle toho bych měl být typický C++ programátor… a přitom jsem Javista :-D

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Relational pipes
4.4. 08:45 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Kam psát hvězdičku u proměnných typu ukazatel?
The choice between ``int* p;'' and ``int *p;'' is not about right and wrong, but about style and emphasis.
S tím úplně nesouhlasim. Tahle argumentace:
A ``typical C++ programmer'' writes ``int* p;'' and explains it ``p is a pointer to an int'' emphasizing type. Indeed the type of p is int*. I clearly prefer that emphasis and see it as important for using the more advanced parts of C++ well.
... IMHO nedává moc smysl, protože pak máš typ jako třeba char *foo[], kde ty závorky stejně nemůžeš nacpat na levou stranu. V C/C++ to není tak, že typ je nalevno a jméno napravo, nýbrž platí spirálové pravidlo (což je syntaktická šílenost, ale tak to prostě je, for better or worse).

Osobně mně ta syntaxe char *p dává větší smysl. Jediné místo, kde dávám * nebo & k typu je návratová hodnota funkce.
4.4. 09:58 sad
Rozbalit Rozbalit vše Re: Kam psát hvězdičku u proměnných typu ukazatel?
struct Link* first; 

for (char& ch : line) {

Polygon* s1[10];

void f(Shape* q, vector<Circle*>& s0)

Shape* p1 = new Rectangle{Point{0,0},10};

int* find(int* first, int* last, int v)
Tohle je styl Bjarna Stroustrupa, tvůrce jazyka C++. Takže kdybych něco psal v C++, tak bych jej asi dodržoval.
4.4. 10:11 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Kam psát hvězdičku u proměnných typu ukazatel?
Ta syntaxe je téměř komplet přebraná z C, čiliže tady mi autorita Bjarna, jakkoli ho jinak celkově docela uznávám, nepřijde až tak relevantní.
4.4. 11:07 JS1 | skóre: 2 | blog: intuition_pump
Rozbalit Rozbalit vše Re: Kam psát hvězdičku u proměnných typu ukazatel?
což je syntaktická šílenost, ale tak to prostě je
Bohuzel ano, typy v C jsou syntakticka (a asi i semanticka) silenost..

Ja osobne bych C nahradil Haskellem, kde by se misto IO vracel stavovy automat (neco jako ST?) nad urcitym typem. A kompilator by proste vytvoril ten stavovy automat a prelozil do assembleru.
Lidstvo má již jen 12 let, aby odvrátilo nejhorší důsledky klimatické katastrofy. Podpořte výzvu na proplanetu.cz!
4.4. 11:35 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: Kam psát hvězdičku u proměnných typu ukazatel?
Bohuzel ano, typy v C jsou syntakticka (a asi i semanticka) silenost..
Ano, je to des. Ale vzhledem k tomu, ze v dobe, kdy vzniklo C, se jeste tapalo v tom, jak vubec spravne udelat proceduralni programovani, nemel bych jim toto zase tak za zle. Na to, ze je C jenom velice mala abstrakce nad instrukcemi procesoru, dopadlo to jeste docela dobre. Treba znam cloveka, ktery si je schopen vystacit se tremi datovymi typy -- int, unsigned long, void *. Proto si dokazu dost dobre predstavit, ze C mohlo skoncit s podobnym typovym systemem.
Ja osobne bych C nahradil Haskellem, kde by se misto IO vracel stavovy automat (neco jako ST?) nad urcitym typem.

To je sen kazdeho systemoveho programatora.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
4.4. 12:01 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Kam psát hvězdičku u proměnných typu ukazatel?
Na to, ze je C jenom velice mala abstrakce nad instrukcemi procesoru, dopadlo to jeste docela dobre. Treba znam cloveka, ktery si je schopen vystacit se tremi datovymi typy -- int, unsigned long, void *. Proto si dokazu dost dobre predstavit, ze C mohlo skoncit s podobnym typovym systemem.
Tak ono koneckonců BCPL i B měly jen jeden typ - slovo.
4.4. 12:22 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Kam psát hvězdičku u proměnných typu ukazatel?
Ja osobne bych C nahradil Haskellem, kde by se misto IO vracel stavovy automat (neco jako ST?) nad urcitym typem.
Vim zhruba, co je IO monáda, ale úplně nerozumim, jak to myslíš. Můžeš to rozvést?
4.4. 13:20 JS1 | skóre: 2 | blog: intuition_pump
Rozbalit Rozbalit vše Re: Kam psát hvězdičku u proměnných typu ukazatel?
Vim zhruba, co je IO monáda, ale úplně nerozumim, jak to myslíš. Můžeš to rozvést?
No, ja taky presne nevim, jak to myslim. :-) Je to spis takovy nastrel napadu.. a ted jak jsi se zeptal, tak budu muset premyslet, nejak to promyslet, a stejne se tu najde nejaky idiot, ktery mi zacne vytykat, ze to mam cele spatne, a bude mit samozrejme pravdu, protoze mym cilem nebylo napsat hned vedeckou praci.. :-)

Ale dobre. Cele to vyslo z toho, ze semantika (treba) Haskellu je zalozena na lambda kalkulu, a tedy dost odlisna od semantiky treba zpracovani dat procesorem. Takze runtime Haskellu napriklad potrebuje GC a vubec je sam o sobe (bez optimalizaci) dost tezkopadny.

Tak jsem si rikal, jak by se asi dal reprezentovat (funkcionalne) jazyk, ktery ma opravdu blizko k hardware? Neco, co by se psalo podobne snadno (YMMV) jako treba Forth, ale typove bezpecne. No a napadla me moznost, ze program ve strojovem kodu lze v jistem smyslu chapat jako stavovy automat (i Turinguv stroj se tak da chapat), a tudiz by bylo mozne mit jazyk, ktery umoznuje ty stavove automaty sestavovat z mensich stavovych automatu a ruzne s nimi pracovat.

No a ten jazyk, ktery sklada ty stavove automaty, by byl funkcionalni, jako treba Haskell. S monadami to pak souvisi tak, ze monady umoznuji oddelit popis neceho a interpretaci. Napr. pokud funkce vraci IO, tak de fakto vraci recept, ktery se interpretuje (Haskellovym runtime) pri spusteni programu. V tom mem jazyce by ovsem spustenim toho funkcionalniho programu byla kompilace toho automatu do strojoveho kodu. Formalne by tedy ten jazyk pracoval s monadou, ktera reprezentuje prave sestavovany stavovy automat.

Mozna uz neco takoveho je, ale jak (nerad priznavam, ze asi spravne) pise deda.jabko, systemovi programatori (Cckari) se do toho zrovna nehrnou.
Lidstvo má již jen 12 let, aby odvrátilo nejhorší důsledky klimatické katastrofy. Podpořte výzvu na proplanetu.cz!
xkucf03 avatar 4.4. 13:54 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Haskell, Graal, OS, vrstvy abstrakce, zacyklení

Tak teoreticky můžeš vzít GraalVM, poslat do něj nějaký vyšší/dynamický jazyk, nechat si ten kód optimalizovat a nakonec přeložit na nativní.

Ale nevím, jestli budou lidi chtít psát tímhle způsobem zrovna operační systémy – tam bych spíš věřil něčemu jako Rust.

Tady je taky trochu problém s cyklickými závislostmi abstrakcí :-) Klasicky se systém staví po vrstvách, od těch nejjednodušších, nejnižších, na kterých se pak budují vyšší. Takže teoreticky jsi schopný postavit počítač z nuly a ze zdrojáků. A teď vlastně přeskočíš několik vrstev abstrakce až k těm nejvyšším a pak to zpátky vracíš na ty nižší, abys z toho měl jádro systému v nativním kódu. Ono je to samozřejmě trochu zacyklené už teď – taky potřebuješ nějaký kompilátor ke zkompilování kompilátoru, kterým zkompiluješ jádro… ale pořád je ta infrastruktura potřebná k zavedení OS ještě relativně jednoduchá. Ale když do toho začneš tahat věci jako kompilování Haskellu (ať už přes Graal nebo jinak), tak se to zacyklení prohlubuje.

Nebo bys uměl napsat kompilátor Haskellu ručně v assembleru? Nevím, možná by to šlo… Tahle implementace by mohla být totálně neoptimalizovaná, protože tímhle kompilátorem bys mohl jen zkompilovat lepší kompilátor, který už by byl psaný ve vyšším programovacím jazyce a mohl by dělat ty potřebné optimalizace.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Relational pipes
5.4. 11:42 JS1 | skóre: 2 | blog: intuition_pump
Rozbalit Rozbalit vše Re: Haskell, Graal, OS, vrstvy abstrakce, zacyklení
Myslim, ze jsi to trochu nepochopil.. Nechci kompilovat Haskell, chci kompilovat jiny jazyk, ktery se pise podobne dobre (a typove bezpecne) jako Haskell, nicmene vysledny kod nepotrebuje runtime (coz je u Haskellu taky sveho druhu interpret).
Lidstvo má již jen 12 let, aby odvrátilo nejhorší důsledky klimatické katastrofy. Podpořte výzvu na proplanetu.cz!
xkucf03 avatar 5.4. 12:16 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: Haskell, Graal, OS, vrstvy abstrakce, zacyklení

Ano, tohle v tom Graalu právě můžeš dělat – kompilovat víceméně libovolný jazyk a ve výsledku z toho mít nativní kód, který nepotřebuje runtime/interpret.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Relational pipes
5.4. 12:50 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Haskell, Graal, OS, vrstvy abstrakce, zacyklení

Ano, tohle v tom Graalu právě můžeš dělat – kompilovat víceméně libovolný jazyk a ve výsledku z toho mít nativní kód, který nepotřebuje runtime/interpret.

Počkat. To AFAIK není pravda - jmenuje se to GraalVM, ne?
xkucf03 avatar 5.4. 13:28 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: Haskell, Graal, OS, vrstvy abstrakce, zacyklení

GraalVM se dá používat různými způsoby – buď jen jako takové lepší JVM, které umožňuje kombinovat různé jazyky v jednom programu a přidává různé optimalizace… nebo ho můžeš použít právě pro AOT kompilaci, a pak z toho vypadne nativní binárka, která tedy obsahuje něco, co se jmenuje Substrate VM, ale je to něco jiného než JVM nebo GraalVM a dá se na to IMHO dívat spíš jako na standardní knihovnu nebo nějakou sadu funkci. Když zkompiluješ nějaký program v céčku a přilinkuješ k němu staticky nějakou knihovnu, tak to pořád bereš jako nativní binárku, ne? I když ta knihovna bude řešit třeba správu paměti nebo vlákna (lépe než bys to dělal ručně v C).

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Relational pipes
5.4. 14:01 JS1 | skóre: 2 | blog: intuition_pump
Rozbalit Rozbalit vše Re: Haskell, Graal, OS, vrstvy abstrakce, zacyklení
z toho vypadne nativní binárka, která tedy obsahuje něco, co se jmenuje Substrate VM
No ale ja prave nechci VM.. ja chci pomoci funkcionalniho jazyka specifikovat neco, co pobezi primo na HW. Ja zcela explicitne nechci ten HW abstrahovat.

To je ostatne dnes smyslem jazyku jako C. Kdybychom umeli Haskell vzdy kompilovat tak, aby se vyrovnal nativnimu C kodu, tak bychom C nepotrebovali. Ale bohuzel to tak neni a tudiz C (nebo jiny nizkourovnovy jazyk) potrebujeme.
Lidstvo má již jen 12 let, aby odvrátilo nejhorší důsledky klimatické katastrofy. Podpořte výzvu na proplanetu.cz!
xkucf03 avatar 5.4. 14:43 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: Haskell, Graal, OS, vrstvy abstrakce, zacyklení

Nerad bych kecal, ale zkus si tu binárku dekompilovat – IMHO to nebude moc daleko od toho, co chceš.

BTW: našel jsem nějaký Haskell pro Arduino: frp-arduino – píší tam: „It compiles to C code“ – tak třeba by šlo něco podobného dělat i na počítači (jestli se to kompiluje do C nebo do nativního kódu/assembleru už je celkem detail).

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Relational pipes
5.4. 15:19 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Haskell, Graal, OS, vrstvy abstrakce, zacyklení
GraalVM se dá používat různými způsoby – buď jen jako takové lepší JVM, které umožňuje kombinovat různé jazyky v jednom programu a přidává různé optimalizace… nebo ho můžeš použít právě pro AOT kompilaci, a pak z toho vypadne nativní binárka, která tedy obsahuje něco, co se jmenuje Substrate VM
Ano, ale stále tam nutně přece musí být např. garbage collector a další věci. Jazyky jako Java obecně není možná zkopmilovat zcela bez runtimu z jejich podstaty. To by leda musel být nějaký subset/rozšíření, které by umožňovalo deterministickou správu paměti, mělo by žádnou nebo omezenější reflexi, atd.

Čiliže spíš ti z toho Graalu vypadne něco jako jsou binárky programů v Go - tj. nativní binárka, ale obsahující plný runtime vč. garbage collectoru.
xkucf03 avatar 5.4. 16:00 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: Haskell, Graal, OS, vrstvy abstrakce, zacyklení
Ano, ale stále tam nutně přece musí být např. garbage collector a další věci.

Ono chtít vyšší programovací jazyk a nechtít GC nebo jinou formu automatické správy paměti je trochu oxymóron. Protože ruční správa paměti z principu je nízkoúrovňový opruz.

To by leda musel být nějaký subset/rozšíření, které by umožňovalo deterministickou správu paměti, mělo by žádnou nebo omezenější reflexi, atd.

Tak to v zásadě je. Ne každý program v Javě (nebo jiném jazyce nad JVM/GraalVM) jde přeložit na nativní binárku.

Substrate VM has partial support for reflection and it needs to know ahead of time the reflectively accessed program elements.
Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Relational pipes
5.4. 16:25 Láďa má velkou hlavu
Rozbalit Rozbalit vše Re: Haskell, Graal, OS, vrstvy abstrakce, zacyklení
njn, pořád stejná písnička...
5.4. 17:02 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Haskell, Graal, OS, vrstvy abstrakce, zacyklení
Ono chtít vyšší programovací jazyk a nechtít GC nebo jinou formu automatické správy paměti je trochu oxymóron.
Dejme tomu, ale chtít vyšší programovací jazyk bez runtime není tak úplně oxymorón - věci jako deterministická správa paměti (Cyclone, Rust, Carp), refcounting (C++, Swift, Rust), QSBR nebo EBR nevyžadují runtime.
4.4. 15:58 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Kam psát hvězdičku u proměnných typu ukazatel?
Mozna uz neco takoveho je, ale jak (nerad priznavam, ze asi spravne) pise deda.jabko, systemovi programatori (Cckari) se do toho zrovna nehrnou.
No, tak svým způsobem něco takového v omezené míře dělá Rust. To, co dělá, bych rozdělil v kontextu vlákna na v podstatě dvě hlavní kategorie: verifikace stavového automatu a generování (korektního) stavového automatu. Verifikace, to je hlavně to, co dělá borrow checker, tzn. napíšeš si kód, který třeba pracuje s nějakým resourcem z jednoho místa a potom za jiných podmínek z jiného, což je v zásadě nějaký stavový automat. A ta verifikace zajišťuje některé invarianty, jako třeba že nepracuješ mutabilně s jedním resource z více míst nebo že s ním nepracuješ mimo dobu života. Generování pak hlavně dělají různé věci vytvořené nad typovým systémem, jako např. cell, Once a pak hlavně async věci (Future, Generator, ...). Ty Futures jsou v podstatě napsané s tou stejnou myšlenkou, jako máš ty, tj. aby to generovalo korektní stavový automat. Ale je to omezené na async věci, nemá to obecné zaměření.

Další, co mě napadá, jsou různé generátory parserů / parser frameworky pro různé jazyky. Typicky tam jde vždycky o to samé - generovat korektní stavový automat z reprezentace na vyšší úrovni. Na to by možná taky stálo za to se podívat.

Jinak Rust samozřejmě není pure FP jazyk jako Haskell, tj. neposkytuje ty záruky v podobně zajíštění funkcí bez side-effectu. Na druhou stranu ale tam, kde se side effecty dějou, poskytuje AFAIK lepší záruky než Haskell. Např. AFAIK Haskell je o dost náchylnější na race conditions v I/O.

Z tohohle důvodu si myslim, že to není jen otázka správného překladu Haskellu, ale bylo by ho potřeba IMHO i rozšířit o chybějící koncepty v type systému, hlavně druhy přístupu v I/O. Alespoň do té míry, jako to má Rust, ideálně i s lepší granularitou.

Otázka je, jestli by to pak byl prakticky použitelný jazyk, to je na tom celým to nejtěžší. Rust není úplně vrchol ergonomie a Haskell už vůbec ne :-D
5.4. 11:39 JS1 | skóre: 2 | blog: intuition_pump
Rozbalit Rozbalit vše Re: Kam psát hvězdičku u proměnných typu ukazatel?
S tim Rustem mas asi dost pravdu.. Ja Rust neznam, chapu to jako urcity kompromis mezi eleganci a prakticnosti, a z toho mam ponekud obavy, podobne jako treba u Scaly.
Rust není úplně vrchol ergonomie a Haskell už vůbec ne
Tady asi trochu nesouhlasim. Na Haskellu je ergonomicke, ze se v nem dobre definuji DSL, podobne jako treba v ruznych Lispech a tak (navic typove bezpecne). Ma jednoduchou syntaxi.. takze jsem to psal spis jako reakci na hruzostrasnou (ale historicky pochopitelnou) syntaxi (a semantiku) jazyka C.

(Coz je ovsem v praxi vzdy dvojsecne. V principu nic nebrani Haskellistum programovat imperativne, a nebo Lisparum definovat typovou kontrolu, ale v praxi vsechny knihovny s takovym pristupem nepocitaji, takze oboji je pres ruku. Knihovny a vubec cela kultura programovani v danem jazyce je ve finale to, co urcuje ergonomii.)

Jestli ma tuhle vlastnost i Rust, nevim.
Lidstvo má již jen 12 let, aby odvrátilo nejhorší důsledky klimatické katastrofy. Podpořte výzvu na proplanetu.cz!
5.4. 15:11 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Kam psát hvězdičku u proměnných typu ukazatel?
S tim Rustem mas asi dost pravdu.. Ja Rust neznam, chapu to jako urcity kompromis mezi eleganci a prakticnosti, a z toho mam ponekud obavy, podobne jako treba u Scaly.
IMO ta situace je jiná než u Scaly. Scala je prostě mix OOP a FP a to je víceméně všechno. Resp. mají afaik vestavěnej Actor model, ale to je věc specifická pro určitý use-case.

Rust je na tom IMO lépe v tom, že přinesl (zpopularizoval, zpřístupnil v praxi, vylepšil) nápady, které do té doby existovaly jen v obskurních jazycích jako Cyclone apod. Z pohledu Rustu je naopak Haskell spíš kompromis, protože víceméně poskytuje pouze rozlišení "funkce má side effect" a "funkce nemá side effect", což nestačí. Rust sice neposkytuje tu úroveň "nemá side effect", ale poskytuje větší paletu v té oblasti "má side effect" - a o to typicky jde v systémovém programování. Snažim se vymyslet, na čem to ilustrovat. Nejjednodušší příklad, co mě napadá, je program, který ze dvou vláken vychrlí na STDOUT nějaké stringy tak, aby se (náhodně) zmatlaly dohromady. V Rustu takový program nepřeložíš, respektive musel bys použít unsafe kód, abys tohle mohl udělat. Moje znalost Haskellu je omezená, ale AFAIK tohle tam půjde bez problému (oprav mě, pokud se pletu).

Jinými slovy, monády jsou hezká věc, ale jejich užitečnost je závislá na typovém systému, nad kterým jsou postavené.
Tady asi trochu nesouhlasim. Na Haskellu je ergonomicke, ze se v nem dobre definuji DSL, podobne jako treba v ruznych Lispech (navic typove bezpecne)
Použil jsem špatný výraz - místo ergonomie jsem měl spíš napsat něco jako "učící křivka", která je u obou dost strmá.

Co se týče typové bezpečnosti, Rust mi pro systémové programování, kde se nelze vyhnout side effectům, přijde typově bezpečnější než Haskell, viz výše, ačkoli samozřejmě je to sporné a záleží, co kdo považuje za typovou bezpečnost.

Co se týče vytváření DSL, v tom budou Haskell a Lisp určitě lepší. Metaprogramování je v Rustu relativně omezené.

Jinak Rust určitě nemá v oblasti bezpečných systémových jazyků první ani poslední slovo. Například ta granularita druhů referencí by mohla být širší (a taky se příležitostně rozšiřuje). Například immutabilní reference obecně slouží ke skutečně immutabilnímu přístupu, ale v některých výjimkách slouží k 'bezpečnému' (non-racy) mutabilnímu přístupu, tzv. interior mutability (například atomické nebo jiné specielní typy) - z teoretického hlediska by bylo lepší, aby pro tohle existoval samostatný typ reference.

Možná by tě v tomhle kontextu mohl zajímat experimentální jazyk Carp - je to Lisp se statickými typy a s ownership trackingem jako má Rust. Nemá GC. Je napsaný v Haskellu, btw ;-)

Okčekával bych, že něco podobného by se dalo naimplementovat i pro Haskell (a možná by to i bylo vhodnější vzhledem ke statickému typování), případně bych se nedivil, kdyby v budoucnu vznikly další jazyky se statickým trackováním, které tuhle oblast posunou třeba dále.
5.4. 16:33 JS1 | skóre: 2 | blog: intuition_pump
Rozbalit Rozbalit vše Re: Kam psát hvězdičku u proměnných typu ukazatel?
Ah, diky za odpoved.
Lidstvo má již jen 12 let, aby odvrátilo nejhorší důsledky klimatické katastrofy. Podpořte výzvu na proplanetu.cz!
5.4. 22:19 random
Rozbalit Rozbalit vše Re: Kam psát hvězdičku u proměnných typu ukazatel?
Žádné spirálové pravidlo neexistuje, deklarace se parsují stejně jako výrazy. Když napíšu int **a[m][n];, tak jsem deklaroval pole polí pointerů na pointry na int. Nejdřív se přečtou obě hranatice a pak teprve obě hvězdičky.

Z toho důvodu taky nevidím žádnou syntaktickou šílenost, naopak vidím jasný důvod, proč psát hvězdičku k názvu proměnné a nikoliv k identifikátoru základového typu.
xkucf03 avatar 5.4. 22:49 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: Kam psát hvězdičku u proměnných typu ukazatel?
naopak vidím jasný důvod, proč psát hvězdičku k názvu proměnné

Moc nechápu, jak to vyplývá z toho, co jsi napsal.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Relational pipes
5.4. 23:43 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Kam psát hvězdičku u proměnných typu ukazatel?
Asi vnímá tu hvězdičku jako unární operátor podobně jako při dereferenci.

Btw. s tím spirálovým pravidlem jsem to nemyslel tak, že to je nějaká oficiální věc, je to prostě jen pomůcka pro čtení...
xkucf03 avatar 6.4. 00:32 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: Kam psát hvězdičku u proměnných typu ukazatel?
Asi vnímá tu hvězdičku jako unární operátor podobně jako při dereferenci.

To mi přijde spíš jako mnemotechnická pomůcka ve smyslu: „když napíšu int *x; a pak někde jinde *x, tak na tom místě dostanu int, což funguje obdobně, jako kdybych udělal int x; a pak psal x, tak pak mi to x dá taky int.“ Tzn. „Deklaruji xxx zzz; a pak v kódu píšu zzz a dostávám tam typ xxx (a jestli byla součástí zzz nějaká hvězdička mě nezajímá, píšu to i s ní, jako by to byla součást názvu proměnné).“

Mně to tam ale nesedí – jednak nevím, co bych tou hvězdičkou dereferencoval, na co bych ten unární operátor aplikoval, když to x v tu chvíli ještě neexistuje – teprve ho na tom řádku deklaruji. A jednak ukazatel vnímám jako datový typ – číslo, offset, adresu v paměti. To mi přijde jako zásadnější informace, než, typ, který by se na té adrese měl nacházet – ostatně ty ukazatele jdou přetypovat a ten kus paměti interpretovat jinak, než jak se používal původně – tzn. tohle se může změnit, ale ukazatel/offset/adresa je to pořád.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Relational pipes
6.4. 09:30 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Kam psát hvězdičku u proměnných typu ukazatel?
Mně to tam ale nesedí – jednak nevím, co bych tou hvězdičkou dereferencoval, na co bych ten unární operátor aplikoval, když to x v tu chvíli ještě neexistuje – teprve ho na tom řádku deklaruji. A jednak ukazatel vnímám jako datový typ – číslo, offset, adresu v paměti. To mi přijde jako zásadnější informace, než, typ, který by se na té adrese měl nacházet – ostatně ty ukazatele jdou přetypovat a ten kus paměti interpretovat jinak, než jak se používal původně – tzn. tohle se může změnit, ale ukazatel/offset/adresa je to pořád.
Což o to, přetypovat můžeš i ten ukazatel jako takovej (existují na to i typy - uintptr_t, ptrdiff_t, ...).

Jinak ale nepřijde mi, že by z té argumentace jakkoli plynulo, že by ta hvězdička měla být nalevo u dereferencovaného typu, i když ji bereš jako součást typu. Jak už jsem napsal, C/C++ není jako Pascal/Rust/Swift, kde máš striktně na jedné straně ident a na druhé typ. V C/C++ je ten typ všude možně okolo toho identu. A kolega 'random' má recht v tom, že se to vyhodnocuje jako výraz, byť fyzicky se v té chvíli dereference neděje...
6.4. 08:42 random
Rozbalit Rozbalit vše Re: Kam psát hvězdičku u proměnných typu ukazatel?
To není o vnímání, ona to je ta samá hvězdička. A ano, přesně tak, to je ten argument. Při dereferenci ji snad všichni píšou přiraženou k proměnné, takže při deklaraci mi připadá logické psát to stejně.

Pomůcky při čtení nejsou potřeba, stačí se naučit prioritu operátorů, deklarace pak jednoznačně vyplývají z ní. Jasně, ty priority jsou někdy trochu divné (ale nejsem si jistý, že by nějaké alternativní řešení bylo logičtější; v různých případech je prostě potřeba mít priority různé a takové ty a & b == c | d se prostě někdy budou muset závorkovat, podle toho, co chce autor napsat), ale fakt stačí naučit se je jednou. Spirálové pravidlo je matoucí a špatné.
6.4. 09:59 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Kam psát hvězdičku u proměnných typu ukazatel?
Spirálové pravidlo je matoucí a špatné.
No tak ho nepoužívej, když se ti nelíbí, já do toho nikoho nenutim... Já si tu prioritu operátorů chronicky pamatuju blbě (navíc v každým jazyce to je trochu jinak), takže mi to pomáhá...
4.4. 02:12 pc2005 | skóre: 37 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: Kam psát hvězdičku u proměnných typu ukazatel?
Taky. U typu píšu jenom když přetypovávám pointer (logicky).
4.4. 15:55 extremni lama | skóre: 14 | blog: e_lama
Rozbalit Rozbalit vše Re: Kam psát hvězdičku u proměnných typu ukazatel?
ale přijde mi lepší psát hvězdičku k typu než k názvu proměnné. Chápu, že i u toho názvu dává svým způsobem smysl, ale myslím si, že víc patří k typu (proměnná je typu ukazatel).


To je super ale v C a C++ to takhle nefunguje.

Deklarací:

int *p;

neříkám že p je typu ukazatel na int. Říkám tím že když někde v kódu použiju *p tak výsledek bude typu int... Což samozrejmě implikuje že p je ukazatel na int :-)

Když misto abych se to snažil otočit, radši správně pochopím jak to funguje tak pak dokážu pochopit i složitější deklarace. Např co je p pokud napíšu:

int (*p)[4];

Pokud někde v kódu použiju (*p)[0..3] tak musím dostat int, takže p je ukazatel na pole 4 intů :-)

Zatímco:

int *p[4];

je totéž jako:

int *(p[4]);

což je pole 4 ukazatelů na int.
The enemy of my enemy is still my enemy.
9.4. 15:57 debian+
Rozbalit Rozbalit vše Re: Kam psát hvězdičku u proměnných typu ukazatel?

Toto int *p[4]; je odkedy pole 4 ukazatelů na int.?
Spravne je: int *p[4]; je definicia pointer na pole 4 prvkov.

A ked uz tak, tak: char *p[] je rovne char **p. Cize p[] sa preklada za *p.

Ako spracuvavas parametre argv funkcie main?

9.4. 16:50 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Kam psát hvězdičku u proměnných typu ukazatel?
Spravne je: int *p[4]; je definicia pointer na pole 4 prvkov.
Ne, není. Předřečník to napsal správně. Viz též tady.
char *p[] je rovne char **p. Cize p[] sa preklada za *p.
Pouze v některých kontextech, ne ve všech (např. ne pro operátor sizeof). Viz příklad.
9.4. 17:43 debian+
Rozbalit Rozbalit vše Re: Kam psát hvězdičku u proměnných typu ukazatel?
Mas pravdu, ze nemam pravdu.

Aj tiez. int *p[4] zamenene podla [] na *, dostanem int **p.

A k ten nahrade plati furt. Ak sa divas k pohladu smerovania pointerov. To ze sizeof povie ze ma prvok*sizeof(JEDEN_PRVOK), neznamena, ze nemozem adresovat 5. Pri tej transormacii stracam pojem o velkosti. Vlastne stav pred tranformaciou je specialny pripad pred (zname velkost a zapiseme v definicii). Zas rozdiel v definicii je, ze ktora pamet programu je pouzita.
9.4. 18:18 extremni lama | skóre: 14 | blog: e_lama
Rozbalit Rozbalit vše Re: Kam psát hvězdičku u proměnných typu ukazatel?
Nahrada NEplati furt ani z pohledu smerovani ukazatelu :-)

Napr: int a[4][5]; je neco podstatne jineho nez: int **a;
The enemy of my enemy is still my enemy.
9.4. 22:06 debian+
Rozbalit Rozbalit vše Re: Kam psát hvězdičku u proměnných typu ukazatel?
Praveze nie.

int *p[4] a int *aa

Lebo co aky je rozdiel medzi polom a pointerom v C? Obidne su definovane pointerom, kt. ukazuje na zaciatok pola. Velkost je neznama. Samozrejme, velkost pozname, ak pozname nad-kontext.
9.4. 22:17 debian+
Rozbalit Rozbalit vše Re: Kam psát hvězdičku u proměnných typu ukazatel?
int a[4][5] - int **a; Obidve sa pouziva na 2-rozmerne pole. Ak si si alokoval dynamicky, vedel by si, ze by si pouzival 2-nasobny pointer.

Ak by si vedel asambler, tak by si vedel, ze aj ked je pointer adresa (tj. celociselne cislo). Ale, odlisuje sa, ze procesor pouziva ine instrukcie. A doteraz zvycajne, adresovanie v OS (napr. hlavna zbernica) pouziva vecsi rozsah (viac bitov), ako je int procesora.
xxx avatar 10.4. 10:58 xxx | skóre: 42 | blog: Na Kafíčko
Rozbalit Rozbalit vše Re: Kam psát hvězdičku u proměnných typu ukazatel?
Hele smir se s tim, ze jsou to dve ruzny veci.

int f(){ char *a = "AaaaaaaA"; char b[] = "Bleeeeeeeeeee"; }

gcc -O0 -S test.c

To ze "je to to samy" a muzes napsat a=b je spis takovy postrani efekt.
Please rise for the Futurama theme song.
10.4. 12:56 debian+
Rozbalit Rozbalit vše Re: Kam psát hvězdičku u proměnných typu ukazatel?
Ja tvrdim, ze je to skore resp. z isteho pohladu ano. [] sa vytvara pamet na zasobniku. *text="" sa vytvara v RO pamete programu.

Tu je vlastne rovnake:
#include <stdio.h>

void vypis_2_znak(char *text)
{
	if(text == NULL)
		return;
	if(*text != '\0')
		if(*(text+1) != '\0') // alebo if((text[1]) != '\0')
			putchar(*(text+1));
}

int main(void)
{
	char text[]="Jedne dva tri";
	char *meno="Dnes";
	
	vypis_2_znak(text);
	vypis_2_znak(meno);
	putchar('\n');

	return 0;
}
10.4. 14:09 extremni lama | skóre: 14 | blog: e_lama
Rozbalit Rozbalit vše Re: Kam psát hvězdičku u proměnných typu ukazatel?
int a[4][5] - int **a; Obidve sa pouziva na 2-rozmerne pole. Ak si si alokoval dynamicky, vedel by si, ze by si pouzival 2-nasobny pointer.
No sebevedomi ti evidentne nechybi. Ted jeste kdyby to bylo podlozene znalostma :-)

Pole a[4][5] je cele ulozene v jednom bloku pameti. To znamena ze mam pole o 4 prvcich, a kazdy prvek je, ne ukazatel, ale pole o 5 prvcich.

Kdyz budu pristupovat na index a[i][j], tak se vezme pocatecni adresa a a poskoci se o 5*i + j prvku.

Zatimco u **a se pri pristupu na index a[i][j] nejdriv nacte ukazatel z a[i], udela se dereference a tou se skoci na nejakou jinou adresu z ktere se nacte prvek j.

V C se pole a ukazatel da na spouste mist pouzivat stejnym zpusobem a tak si hodne lidi mysli ze je to totez ale neni. Preloz si to do asm a uvidis ze v jednom pripade je tam nasobeni a v druhem dereference ;-)
The enemy of my enemy is still my enemy.
10.4. 20:02 debian+
Rozbalit Rozbalit vše Re: Kam psát hvězdičku u proměnných typu ukazatel?
Striktne jednoznacne argumenty nenajdes, kedze C si preslo svojim vyvojom. A zalezi na implementacii, ako je spravene.

Rozdiel medzi polom [] a * je, ze prvy je robeny na zasobniku a druhy je v RO pamete programu alebo dynamicky alokovane.

Ta ako bude spracovane do ASM je jedno. V praxi, ked zamenis pristup [] za *, tak vo funkcnosti programu sa to mimo umiestnenia (pamet programu, zasobnik alebo halda/kopa), inac nie. A kolko implementacii C, tolko variacii.

Je jasne, ze prekladac, si implementuje podla toho kde mu to hodi.
10.4. 20:17 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Kam psát hvězdičku u proměnných typu ukazatel?
Sorry, ale ty tu píšeš do diskuse naprosté hovadiny. Je to přesně tak, jak píše `extremni lama` (tj. rozdíl jedno velké pole + aritmetika versus dvojtá indirekce). A není to žádná záležitost implementace kompilátoru, tohle vychází ze standardu, kde jsou tyhle mechanismy popsané, včetně toho, za jakých situací může nebo nemůže docházet k auto-konverzi pole na pointer.
7.4. 23:00 Jardík
Rozbalit Rozbalit vše Re: Dynamické pole (C)
Ošetřovat návrat malloc, jestli neni NULL nemá v dnešní době smysl. Dnešní OS rádi overcommitují, takže ti vrátí platný pointer, i když paměti dostatek není. No a pak ti program spadne na SIGSEGV, až do té paměti budeš zapisovat, protože se nepodaří alokovat stránku...

Nepoužívat int pro velikost něčeho v paměti. Použít size_t, popř. pokud určitě vím, Že položek nebude víc jak N bitů, a chci šetřit pamětí, použít typ uintN_t, pokud je menší, než size_t. Když se použije int, tak mi to říká "hele, nevím co dělám, tak se to sem snad vejde".

Neslouchej borce, co ti říkají, abys pojmenoval typ xxxxx_t. Takový název typu si POSIX rezervuje. Stejně, jako nesmíš používát název začínající podtržítkem a velkým písmenem, nebo názvy obsahující dvě podtržítka za sebou, nebo názvy, co mají všechna písmena velká a začínají na E (rezervováno pro kódy errno).

Radu použít věci jako bzero, či memset na vymazání paměti ignoruj. Stejně je tam pak race-condition mezi malloc a memset, takže je to k ničemu. Pokud bys psal nějaký citlivý sw, tak musíš použít funkci OS, co to udělá atomicky.

Programovat v C takovéto pole je hovadina. Prostě použij standardni pole a neschovávej jeho typ pod nějaký stupidní objekt, co je napodobeninou šablon z C++, ale bez typové informace. Pokud něco takového potřebuješ, tak používáš špatný jazyk.
8.4. 09:48 sad
Rozbalit Rozbalit vše Re: Dynamické pole (C)
Díky za reakci. Jen jsem si chtěl vyzkoušet, jestli je možné udělat si v c vlastní vector. Jak je vidět, tak to jde, ale asi bude lepší použít rovnou c++.
8.4. 12:50 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Dynamické pole (C)
Radu použít věci jako bzero, či memset na vymazání paměti ignoruj. Stejně je tam pak race-condition mezi malloc a memset, takže je to k ničemu. Pokud bys psal nějaký citlivý sw, tak musíš použít funkci OS, co to udělá atomicky.
Race condition mezi čím a čím? Ie. mezi alokujícím vláknem a jiným, nebo mezi procesy?

Pomůže calloc()?
Programovat v C takovéto pole je hovadina. Prostě použij standardni pole a neschovávej jeho typ pod nějaký stupidní objekt, co je napodobeninou šablon z C++, ale bez typové informace. Pokud něco takového potřebuješ, tak používáš špatný jazyk.
No nicméně větší codebases v C takovéhle všelijaké utility mívají. Linux má flex_array, kluci z matfyzu mají takové věci v té jejich libucw, v Solarisu blahé paměti jsme mívali něco podobného + typově bezpečný spojový seznam pomocí maker...
8.4. 13:32 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: Dynamické pole (C)
Race condition mezi čím a čím? Ie. mezi alokujícím vláknem a jiným, nebo mezi procesy?

Pomůže calloc()?
IMHO je to nesmysl. Pokud mas jednovlaknovou aplikaci, tak ti race-condition z podstaty nehrozi. Pokud bys mel vicevlaknovou aplikaci, tak by se druhe vlakno muselo dostat k odkazu na onu nevynulovanou pamet. Bud to udelas vedome, pak je to tvoje chyba. Pokud to dokaze jine vlakno bez vedomi programatora, tak mas v programu vetsi chybu, ktera ti patrne umozni cist cokoliv, co mas v pameti, takze nema cenu to resit.

Calloc ti nepomuze, je to v user space. Jardikova rada pouzit volani jadra neni uplne stastny napad. Muzes treba udelat mmap(/dev/zero), ale tim ziskas pamet zarovnanou na jednotlive stranky, coz aplikacniho programatora opravdu potesi. Nemluve o rychlosti.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
8.4. 13:39 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Dynamické pole (C)
Calloc ti nepomuze, je to v user space.
Ok, dík, myslel jsem si to...
10.4. 16:23 Jardik
Rozbalit Rozbalit vše Re: Dynamické pole (C)
To neni pravda, race condition neni sice mezi vlakny te tvoji aplikace, ale pamet chces mit asi vynulovanou, aby ti nekdo necetl informace, treba stara data v pameti. No a pokud vymaz udelas az po alokaci, tak mezi temito operacemi ji muze utocnik precist, coz je ten race condition. Zminovany calloc nemusi byt atomicky a neslouzi k ochrane pred utocnikem, ale k tomu, abys treba mel inicializovany napr hodnoty ve strukture na nuly a nemusel to delat rucne.
10.4. 16:47 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: Dynamické pole (C)
To neni pravda, race condition neni sice mezi vlakny te tvoji aplikace, ale pamet chces mit asi vynulovanou,
Kdyz tam neni race-condition mezi vlakny toho jednoho procesu, tak mezi cim?
pamet chces mit asi vynulovanou, aby ti nekdo necetl informace, treba stara data v pameti.
Ke starym datum jineho procesu nemas prilezitost se dostat. Alokator muze bud pouzit sbrk nebo mmap+MAP_ANONYMOUSE nebo mmap+/dev/zero, aby ziskal pamet, kterou pak prerozdeli mallocem, ale vzdy je ta pamet vynulovana.

Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
10.4. 18:26 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Dynamické pole (C)
To jednak a pak když už člověk má v paměti nějaký citlivý data (klíče apod.), tak hlavně by neměl vůbec dopustit jejich dealokaci, měl by zajistit vynulování hned po použití + je potřeba použít mlock() nebo něco podobnýho, aby se ty data neodswapovaly na disk.

Třeba botan má na tohle specielní vector typ.
10.4. 19:14 Jardík
Rozbalit Rozbalit vše Re: Dynamické pole (C)
Kdyz tam neni race-condition mezi vlakny toho jednoho procesu, tak mezi cim?
Mezi tvoji aplikaci a jinou aplikaci, ktera muze mit pristup do pameti tve aplikace a mezi alokaci a vynulovanim ti ji muze precist.
Alokator muze bud pouzit sbrk nebo mmap+MAP_ANONYMOUSE...
To je mozne, ale alokator muze vyuzit nejakou "uvolnenou" pamet, kterou si nekde skladuje pro znovuvyuziti, a vubec o ni system nemusi zadat. Dale si nejsem jisty, jestli ti mmap nemuze vratit nejakou starou stranku, kdyz treba pred tim provedes unmap. Protoze se stale jedna o puvodni proces, system ji asi nemusi prepsat nulama. Nikde jsem to v manualovych strankach nevidel garantovano, ze opravdu je garantovano, ze pamet je vynulovana. (Pokud me na to odkazes, rad si to prectu a doplnim si znalosti). A jaka je situace na Windows, to take nevim. Obecne ale vymazavat pamet po alokaci nebo po pouziti mi prijde jako zbytecny pocit bezpecnosti, ktery tam neni, protoze je tam ta race-condition, kdy mezi tim se muze stat cokoliv (i kdyz ta doba ke zneuziti je treba mala).
10.4. 22:46 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: Dynamické pole (C)
Mezi tvoji aplikaci a jinou aplikaci, ktera muze mit pristup do pameti tve aplikace a mezi alokaci a vynulovanim ti ji muze precist.
To je nesmysl. Abys mel mezi dvema procesy sdilenou pamet, ktera je i v rezimu pro zapis (aby hrozil race condition), tak se musis docela snazit, minimalne natolik, aby sis vsiml, ze hrozi nejaky soubeh. Neni to vec, kterou udelas omylem pomoci malloc a free.
To je mozne, ale alokator muze vyuzit nejakou "uvolnenou" pamet, kterou si nekde skladuje pro znovuvyuziti, a vubec o ni system nemusi zadat.
Ano, to muze. Ale pak je to pamet/data, ktera patri tomu procesu, a pokud muzes ziskat pristup k teto pameti, je to jen v dusledku nejake dalsi hlubsi chyby v tom programu. (Uz jsem to rozebiral vys, nebo niz, ted nevim.)
Dale si nejsem jisty, jestli ti mmap nemuze vratit nejakou starou stranku
Pokud udelas mmap(/dev/zero), docela by me prekvapilo, kdyz by se do pameti dostalo i neco jineho.

Pokud udelas mmap(MAP_ANONYMOUS) mely by tam byt nuly. MAP_ANONYMOUS The mapping is not backed by any file; its contents are initialized to zero.
Nikde jsem to v manualovych strankach nevidel garantovano, ze opravdu je garantovano, ze pamet je vynulovana.
Ja bych toto videl jako vlastnost kazdeho pricetneho operacniho systemu, jinak by tu byly zastupy utoku typu heartbleed.
A jaka je situace na Windows, to take nevim.
Taky presne nevim, ale predpokladal bych to same. Uz jen z toho duvodu, ze "proces necinne procesy" (nebo jak se to jmenuje) ma prave za ukol nulovat stranky pro dalsi pouziti.
obecne ale vymazavat pamet po alokaci nebo po pouziti mi prijde jako zbytecny pocit bezpecnosti, ktery tam neni, protoze je tam ta race-condition, kdy mezi tim se muze stat cokoliv (i kdyz ta doba ke zneuziti je treba mala).
Spis to vidim, ze ztrasis bubakem, ktery neexistuje. Nebo zkus popsat, jak by ten race-condition mohl vzniknout.

Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
10.4. 17:02 JS1 | skóre: 2 | blog: intuition_pump
Rozbalit Rozbalit vše Re: Dynamické pole (C)
pamet chces mit asi vynulovanou, aby ti nekdo necetl informace, treba stara data v pameti
Tak u pameti co dostanes od OS by mel zaridit OS, aby neobsahovala data jinych procesu.

Jinak obecne - vi nekdo jak se v Jave (nebo jinych managed jazycich) resi citliva data? Ja jsem chtel kdysi davno v .NETu nejak zaridit, aby se heslo po pouziti vymazalo z pameti, ale jelikoz to slo pres nejaky UI dialog, bylo to prakticky nemozne dosahnout.
Lidstvo má již jen 12 let, aby odvrátilo nejhorší důsledky klimatické katastrofy. Podpořte výzvu na proplanetu.cz!
xkucf03 avatar 10.4. 17:10 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: Dynamické pole (C)

V Javě se běžně místo Stringu např. pro hesla používá char[], který si po použití vynuluješ. Případně jsou nějaké knihovny na práci s bezpečnou pamětí… nebo jsem viděl i aplikaci, která přes nativní API komunikovala s klíčenkou v KDE.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Relational pipes
10.4. 18:09 JS1 | skóre: 2 | blog: intuition_pump
Rozbalit Rozbalit vše Re: Dynamické pole (C)
To je dost obezlicka, ale hlavne, pokud se v tom angazuji jine knihovny (treba GUI), tak nikdy nemas jistotu, ze se to nekde po ceste nezkopirovalo (a tudiz nezustalo v managed pameti). Ale je to spis teoreticka otazka, nijak zasadne me to netrapi.
Lidstvo má již jen 12 let, aby odvrátilo nejhorší důsledky klimatické katastrofy. Podpořte výzvu na proplanetu.cz!
10.4. 18:29 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: Dynamické pole (C)
To je dost obezlicka, ale hlavne, pokud se v tom angazuji jine knihovny (treba GUI), tak nikdy nemas jistotu, ze se to nekde po ceste nezkopirovalo
To nemas nikdy.
(a tudiz nezustalo v managed pameti)
To je spis teoreticky problem, protoze pristup k managed pameti mas docela dobre kontrolovany a nenapad me zpusob, jak by mohla data uniknout (nejak bokem). Horsi je, kdyz ti data zustanou v unmanaged pameti, tam je prostor pro chyby a potencialni uniky mnohem vetsi.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
xkucf03 avatar 10.4. 19:16 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Bezpečná paměť

Proto i ten GUI prvek JPasswordField má metodu public char[] getPassword() s popisem:

Returns the text contained in this TextComponent. If the underlying document is null, will give a NullPointerException. For stronger security, it is recommended that the returned character array be cleared after use by setting each character to zero.

Je tam snaha, aby se to rozkopírovalo na co nejméně míst a aby se to co nejdřív promazalo. Nicméně vždycky tam bude alespoň na chvíli nějaké místo, ze které by šlo ten citlivý údaj ve vhodnou chvíli ukrást. Něco jde řešit přes TPM, ale pokud tam má být nějaká interakce s uživatelem nebo se má třeba to heslo použít pro přihlášení někam na server, tak přes tu „nebezpečnou“ paměť stejně musí projít.

Jak se to řeší jinde? Taky promažeš pole, ne? Maximálně ho umístíš do nějaké bezpečné části paměti, která se neodswapuje na disku (nicméně kompletně šifrovaný disk je lepší mít tak jako tak).

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Relational pipes
8.4. 13:36 Soustruh
Rozbalit Rozbalit vše Re: Dynamické pole (C)
No nicméně větší codebases v C takovéhle všelijaké utility mívají. Linux má flex_array, kluci z matfyzu mají takové věci v té jejich libucw, v Solarisu blahé paměti jsme mívali něco podobného + typově bezpečný spojový seznam pomocí maker...
Aneb, kdo nepochopil C++, je odsouzen si znovu-vynalézt vlastní.
8.4. 13:19 JS1 | skóre: 2 | blog: intuition_pump
Rozbalit Rozbalit vše Re: Dynamické pole (C)
A je nejaka dobra konvence (v C) jak pojmenovavat typy? (Treba jako v Haskellu, typy zacinaji velkym, hodnoty jsou malym.)
Lidstvo má již jen 12 let, aby odvrátilo nejhorší důsledky klimatické katastrofy. Podpořte výzvu na proplanetu.cz!
8.4. 13:40 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: Dynamické pole (C)
Treba jako v Haskellu, typy zacinaji velkym, hodnoty jsou malym
Tak to ma i Java a cte se to docela dobre.
A je nejaka dobra konvence (v C) jak pojmenovavat typy?
Rekl bych, ze nejaka univerzalni konvence neexistuje. Pamatuju si, ze uz v davnych devadesatych letech se pascalisti posmivali ceckarum, ze nemaji jednotnou konvenci pro pojmenovani typu a kazdy si to masti, jak se mu zlibi.

Pro ty pozdeji narozene, v Pascalu se pouzivala konvence TData (pro oznaceni typu) a PData (pro ukazatel na hodnotu typu TData).
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
xkucf03 avatar 8.4. 13:50 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: Dynamické pole (C)

Maďarská notace? :-) Ale v mnoha jazycích není potřeba, protože čím víc ti toho kontroluje kompilátor (a např. napovídá IDE), tím méně toho potřebuješ nacpat do názvu proměnné.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Relational pipes
8.4. 14:07 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Dynamické pole (C)
Osobně maďarskou notaci fakt nesnášim... V BCPL to mělo smysl, pak už IMO ne...
8.4. 14:16 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: Dynamické pole (C)
Maďarská notace? :-) Ale v mnoha jazycích není potřeba, protože čím víc ti toho kontroluje kompilátor (a např. napovídá IDE), tím méně toho potřebuješ nacpat do názvu proměnné.
Madarske notace je neco trochu jineho.

Tady resime, jak v kodu odlisit jednotlive elementy jazyka, typ, hodnota, procedura.

Madarska notace resi, jak pojmenovavat promenne (a pripadne typy). A to jeste ve dvojim smyslu.

Puvodni Simonyiova myslenka byla, ze se u jednotlivych promennych bude uvedeny prefix indikujici jaky "typ" hodnoty v promenne je. Napr. cntItems (pocet polozek), rwIndex (index radku), atp. Coz dava smysl, protoze to programatora navede, co v te promenne/argumentu muze cekat.

Jenomze ostatni v Microsoftu si vyznam slova typ vylozili, ze ten prefix ma indikovat "datovy typ", a totalne se to zvrhlo do uplnych zverstev, ktere bezhlave kopirovali dalsi lidi.

Jednak programator v podstate supluje praci prekladace, kdy uvadi nejenom typ promenne, ale jeste to kopiruje do jejiho nazvu. Tato informace je pro programatora stejne k nicemu, ale navic ti typy prestanou fungovat jako abstrakce. V momente, kdy se rozhodnes zmenit typ hodnoty treba z HWND na LP, musis menit vsude i nazvy promennych, misto toho, abys jen zmenil strukturu toho typu.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
8.4. 14:54 JS1 | skóre: 2 | blog: intuition_pump
Rozbalit Rozbalit vše Re: Dynamické pole (C)
Tak me treba prijde ta konvence *_t jako docela pekna, ale bohuzel, jak pise Jardik, POSIX si to zabral pro sebe.

Ale je pravda, ze Javova konvence by se vlastne v C dala dobre pouzit, a zhruba odpovida te Haskellovske.. Nikdy me to nenapadlo, ale dava to perfektni smysl (az tedy na ten POSIX..).
Lidstvo má již jen 12 let, aby odvrátilo nejhorší důsledky klimatické katastrofy. Podpořte výzvu na proplanetu.cz!
8.4. 15:37 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Dynamické pole (C)
Tak me treba prijde ta konvence *_t jako docela pekna, ale bohuzel, jak pise Jardik, POSIX si to zabral pro sebe.
To si sice zabral, nicméně lidi to celkem často používaj. Správně to striktně vzato není, nicméně dokud si daný název POSIX fakt pro něco nealokuje, tak to v zásadě v praxi nevadí. Což když třeba má člověk v tom typu svoje věci, není ani moc pravděpodobné.
Ale je pravda, ze Javova konvence by se vlastne v C dala dobre pouzit, a zhruba odpovida te Haskellovske.. Nikdy me to nenapadlo, ale dava to perfektni smysl (az tedy na ten POSIX..).
No, třeba ten Rust používá zásadně konvenci PascalCase pro typy (a enum varianty), snake_case pro funkce, proměnné atp. a UPPER_SNAKE_CASE pro globály a globální konstanty.

Některé C/C++ codebases používají tenhle style taky, například IIRC GTK.
xkucf03 avatar 8.4. 15:59 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše snake, camel, pascal -case
No, třeba ten Rust používá zásadně konvenci PascalCase pro typy (a enum varianty), snake_case pro funkce, proměnné atp. a UPPER_SNAKE_CASE pro globály a globální konstanty.

Je nějaký racionální důvod pro ten „snake_case pro funkce“? Zvažoval se při návrhu jazyka/konvencí camelCase? Schválně by mě zajímalo, jaké byly argumenty pro a proti…

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Relational pipes
8.4. 16:22 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: snake, camel, pascal -case
Ty důvody budou nejspíš historické. Rust vychází (mimo jiné) z OCamlu, první verze byly v OCamlu napsané. Některé syntaktické věci jsou z něj přebrané, snake case pro funkce je jedna z nich AFAIK.

Nevim, jestli se zvažoval camelCase, spíš ne. A nenapadají mě ani žádné racionální důvody pro nebo proti, IMO je to čistě stylistická záležitost.
xkucf03 avatar 8.4. 16:37 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: snake, camel, pascal -case

Mě na tom přijde zvláštní, že používají (k vyznačení hranice slov) jak podtržítko tak změnu velikosti písmen. Jinde si většinou vybrali buď jedno nebo druhé. Podtržítka jsou typičtější pro jazyky, které nerozlišují velikost písmen a kde by se ty hranice ztrácely (i kdybys napsal MojeProměnná, tak by se to nakonec převedlo na mojeproměnná, takže místo toho radši píšeš moje_proměnná). To je případ třeba SQL (kde bys to sice mohl obejít pomocí "MojeProměnná", ale komu se chce psát všude uvozovky, že? To už je lepší tam dávat podtržítka). A pokud se někde kombinuje oboje, tak k tomu bývá právě nějaký důvod – jako např. u konstant v Javě, které se píší velkými písmeny, takže u nich jsou podtržítka nutnost, i když zbytek jazyka používá camelCase/PascalCase.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Relational pipes
8.4. 16:55 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: snake, camel, pascal -case
Nechápu otázku, vždyť to je stejný princip jako v té Javě. Prostě se pro každý ten případ použije jiný case, aby to bylo v textu odlišené. Jediný rozdíl u toho Rustu/OCamlu/atd. oproti té Javě je, že ten case pro funkce/proměnné je víc jiný...
xkucf03 avatar 8.4. 17:04 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: snake, camel, pascal -case

Rozdíl je v tom, že v Javě se konstanty píší VELKÝMIPÍSMENY, proto má opodstatnění narušit tu jednotnost (všude jinde je camelCase/PascalCase resp. nejsou tam podtržítka) a dát do nich podtržítka → VELKÝMI_PÍSMENY. Zatímco u těch názvů funkcí v Rustu mi ten důvod jaksi chybí, protože místo moje_funkce() mohlo klidně být mojeFunkce(), ne?

Nebo bylo cílem to odlišit od proměnných? Mohlo by se to někdy plést?

(jinak je to tedy celkem nepodstatná blbost, jen mě to zaujalo :-)

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Relational pipes
8.4. 17:10 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: snake, camel, pascal -case
proto má opodstatnění narušit tu jednotnost
No tak jak to chápu já tak ta jednodnost je narušená právě proto, aby to bylo poznat, v tom vidím celý smysl toho mít jinej case pro různý věci... Ale možná za tím je něco hlubšího, nevim ¯\_(ツ)_/¯
Nebo bylo cílem to odlišit od proměnných? Mohlo by se to někdy plést?
Ne, proměnné a funkce jsou oboje snake_case ...
8.4. 16:48 JS1 | skóre: 2 | blog: intuition_pump
Rozbalit Rozbalit vše Re: snake, camel, pascal -case
Ja mam treba radsi snakecase nez camelcase (a pascalcase je mezi), ale uplne nejradsi mam Lispovou konvenci (kterou bohuzel nejde jinde pouzit).
Lidstvo má již jen 12 let, aby odvrátilo nejhorší důsledky klimatické katastrofy. Podpořte výzvu na proplanetu.cz!
xkucf03 avatar 8.4. 17:06 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: snake, camel, pascal -case
kterou bohuzel nejde jinde pouzit

Třeba v XML to lze :-) a i se to používá (jestli myslíš pomlčky).

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Relational pipes
9.4. 11:41 JS1 | skóre: 2 | blog: intuition_pump
Rozbalit Rozbalit vše Re: snake, camel, pascal -case
Vlastne, kdyz nad tim premyslim, asi nejvic v oblibe mam osobni konvenci - vezmi z kazdeho slova prvni pismeno, spoj je dohromady a pokud takovych identifikatoru potrebujes vic, ocisluj je (od jednicky, ten prvni bez cisla je nulty). Pouzivaji to radi matematici.. :-P
Lidstvo má již jen 12 let, aby odvrátilo nejhorší důsledky klimatické katastrofy. Podpořte výzvu na proplanetu.cz!
xkucf03 avatar 9.4. 13:46 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: snake, camel, pascal -case
vezmi z kazdeho slova prvni pismeno, spoj je dohromady a pokud takovych identifikatoru potrebujes vic, ocisluj je

To už tam rovnou můžeš dávat prvních pár bajtů z SHA hashe v HEX – vyjde to zhruba nastejno – taky je to jednosměrná funkce, které zpátky nikdo jen tak nedekóduje :-)

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Relational pipes
9.4. 23:36 JS1 | skóre: 2 | blog: intuition_pump
Rozbalit Rozbalit vše Re: snake, camel, pascal -case
To nemuzu, protoze to by nebyl vzdy validni identifikator. ;-)
Lidstvo má již jen 12 let, aby odvrátilo nejhorší důsledky klimatické katastrofy. Podpořte výzvu na proplanetu.cz!
9.4. 11:32 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: snake, camel, pascal -case
Zvažoval se při návrhu jazyka/konvencí camelCase
U Ruby třeba psali, že se camelCase nedoporučuje, protože lidem, co nejsou kovaní v používání latinky (hlavní vývojáři jsou Japonci), se to blbě čte.
Quando omni flunkus moritati

Založit nové vláknoNahoru

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.