Programování v jazyce Vala - základní prvky jazyka (diskuse)

[weezy]

dalsi C like klon Delphi? clanok - pekny, jazyk - nuda

[JS]

Je to klon C#, jinak +1 - nuda.

[v.podzimek]

Já myslím, ze Vala statečně zaplňuje místo mezi C++ a Javou.Samozřejmě ne v této

C++ -- Vala -- Java

pozici, ale v této

       Vala
       /  \
      /    \
   C++    Java

pozici. ;) Teď vážně, myslím, že je to dobrý vysokoúrovňový jazyk, který ke svému rychlému běhu nepotřebuje žádný velký balast navíc.

[Jardík]

public abstract Task? get (int index);

Jenom int to může být, tralalala tralalala lala.

[v.podzimek]

public abstract Task? get (int index);

Jenom int to může být, tralalala tralalala lala.

Nevím, jestli jsem správně pochopil tento komentář, ale pokud jde o to, že by ve Vale mělo být možné indexovat ([]) pouze hodnotou typu int, tak to bych rád uvedl na pravou míru. Vala totiž umožňuje použití libovolného typu, stačí správně zadefinovat metodu get. Ostatně i TaskManager má tuto metodu definovánu jako

public new TaskCollection? get (string title)

Pokud šlo o cokoliv jiného, omlouvám se za "nemístnou" odpověď. :)

[smazáno]

int k indexovani pouzivaj jen 32bitovy smejdarny

[Luboš Doležel (Doli)]

To je náš Jardík. Ten akceptuje pouze 64bitové indexy

[Jardík]

No spíš než ne-64bit indexy mi vadí předpoklady:

sizeof vrací hodnotu typu int

výraz sizeof(cokoliv) * něco_typu_int_který_může_být_záporný_a_dostanu_tak_kravinu je naprosto vpořádku a nemůže se stát nic špatného

sizeof(int) <= sizeof(size_t)

chci spojit pole, je ok udělat malloc(něco_typu_int+něco_typu_int) i když to třeba přeteče a smaže pak pevný disk. Nebo mi to třeba dá malloc(-1) a po převodu na size_t mi to hodí třeba nějaký 0xFFFFFFFFFFFFFFFF.

using GLib;

namespace bla
{


class Bla
{
  static char[] join_array(char[] array1, char[] array2)
  {
    // TODO: copy elements
    int len = array1.length + array2.length;
    return new char[len];
  }
  
  public static void main(string[] args)
  {
    char[] array1 = new char[int.MAX];
    char[] array2 = new char[int.MAX];
    
    char[] array3 = join_array(array1, array2);
    
    stdout.printf("array1.length = %d, array2.length = %d, array3.length = %d\n",
      array1.length, array2.length, array3.length);
  }
}

}

Mi vyprskne:

(process:1800): GLib-ERROR **: gmem.c:195: failed to allocate 18446744073709551614 bytes

Určitě né proto, že na mé platformě 2G+2G je 4G, ale proto, že to jaksi přeteklo, náhodou to nesmazalo pevný disk, pak se to převedlo na size_t (resp. gsize, protože to alokuje přes g_new0 z glib) a vyprsklo to kravinu. Kdyby vala používala size_t, tak by se toto na mé platformě nestalo a program by běžel správně. Vala tak na mé platformě uměle omezuje velikost pole na INT_MAX, ǎckoli pak vygeneruje C kód a to mě omezuje SIZE_MAX. Výsledkem je omezení na MIN(INT_MAX, SIZE_MAX), na mé platformě je INT_MAX menší.

A když náhodou dám Vale hint, že array_length_type je size_t, tak si nepomůžu, stejně to přetypuje na int:

[CCode(array_length_type = "size_t")]
  static char[] join_array([CCode(array_length_type = "size_t")] char[] array1, [CCode(array_length_type = "size_t")] char[] array2)
  {
    return new char[array1.length + array2.length];
  }


// -->

static gchar* bla_bla_join_array (gchar* array1, size_t array1_length1, gchar* array2, size_t array2_length1, size_t* result_length1) {
	gchar* result = NULL;
	gchar* _tmp0_;
	gint _tmp0__length1;
	gchar* _tmp1_;
	gint _tmp1__length1;
	gchar* _tmp2_ = NULL;
	gchar* _tmp3_;
	gint _tmp3__length1;
	_tmp0_ = array1;
	_tmp0__length1 = (gint) array1_length1;
	_tmp1_ = array2;
	_tmp1__length1 = (gint) array2_length1;
	_tmp2_ = g_new0 (gchar, _tmp0__length1 + _tmp1__length1);
	_tmp3_ = _tmp2_;
	_tmp3__length1 = _tmp0__length1 + _tmp1__length1;
	if (result_length1) {
		*result_length1 = _tmp3__length1;
	}
	result = _tmp3_;
	return result;
}

[Jardík]

Né, mně jde o to, že vala pak generuje kraviny s intama místo se size_t, dementně si myslí, že sizeof() vrací hodnotu typu int, int násobí typem size_t, apod. vylomeniny. Pak z toho vyleze něco, co "náhodou funguje".

[Bystroushaak]

Pěkný článek. Vala mi z něj přijde dost podobná D.

[Jardík]

D alespoň používá size_t pro velikosti polí ^-^. (jardíkrejp).

[Jardík]

No ale když kouknu na standardní knihovnu jazyka D, tak asi ani vývojáři nevědí, proč tam ten size_t mají.

Příkladem budiž třeba std.stream, kde třeba v konstruktoru BufferedStream je jako velikost bufferu typ ulong místo size_t (ulong nedává smysl pro velikost bufferu, size_t ano), seek se zdá ok (když vynechám u seekSet absolutní nastavení pozice jako znaménkovou hodnotu (a pak to vrací neznaménkovou) a size a position jako ulong. U seekSet by spíš bylo dobré ulong, u relativních seeků bych klidně long nechal. Pak najednou u File je property "available" jako size_t a popisek "returns the difference of the size and position". Při position 0 a size nějakých max_hodnota_ulong by to mohlo vracet kraviny na některých platformách.

v std.thread nějak zapomínají na posix platformách volat pthread_attr_destroy po pthread_attr_init a vytvoření vlákna. Leaky!

[Bystroushaak]

Pošli patch, komunita je dost otevřená.

[Jardík]

tak patch na ten pthread_attr_destroy možná, jestli mě nebudou nutit registrovat se, ale patch pro ty věci ze std.stream ... by to rozbilo API, např. na x86-64 by to asi nevadilo, protože jsou stejně velký, ale na x86-32 by to vadit mohlo, 64bit ulong změnit na 32bit size_t ... a pak opačně u té available property.

[Jardík]

API, ABI, nebo oboje, to je jedno

[Ondra]

dobry den,

zajmalo by me, zda-li se Vala (nebo i Genie) hodi pro psani knihoven at uz vysokourovnovych ci nizkourovnovych, jako treba GStreamer?

nejsou nahodou v GNOME plany, ze by GStreamer a podobne do Valy prepsaly? prijde mi, ze jsou smutne zabugovany a takovej prepis do smysluplnejsiho jazyka by mohl pomoct

[pavlix]

Přepis do jiného jazyka nepomůže. Jinak „slušně zabugovaný“ znamená v případě GStreameru co? Já jsem si tuto otázku pokládal v souvislosti s NetworkManagerem v určitém ohledu by to mohlo být pohodlnější, ale...

Výměna jazyka C za jazyk, který se do C teprve přeloží může přispět sice přispět k pohodlí programátora, nicméně nevyřeší chyby, které programátor vytváří, ani podle mě nijak nezmenší jeho lenost přemýšlet, či nedej bože něco po sobě otestovat.

Nevím jak u GStreameru, ale u NetworkManageru je 100% nutná znalost jazyka C a použití jiného jazyka by vynucovalo znalost dvou jazyků. Naopak komplexita network managementu podle mě převyšuje žabomyší spory o jazycích, tudíž by opět změna zavedeného řádu neměla nejmenší šanci přinést významné zlepšení.

To, co dělá GStreamer je podle mě opět podstatně komplexnější než network management. Takže bych rozhodně neviděl překážku v potřebě znát jazyk C a umět v něm pracovat s GObjecty.

Celkově mi vychází, že u backendových aplikací jsou výhody marginální. Výhody se naopak projeví u frontendových aplikací, kde je potřeba vývoj a hlavně opravu chyb co nejvíce usnadnit.

[McBig]

Hezký článek, ale trochu mě to zarazilo s tím owned objektem. Vedle toho že sem byl doposud přesvědčen že je to obráceně, sem si to i ověřil na krátkém kódu:

public class Boo : GLib.Object {
    string val;
    public Boo (string val) {
        this.val = val;
    }
}

public class Foo {
    private Boo _boo;
    public Foo (string val){
        _boo = new Boo(val);
    }
    public Boo boo {
        get { return _boo; }
        set { _boo = value; }
    }
    public void debug () {
        stdout.printf ("_boo addr: %p\n", _boo);
    }
}

void main () {
    var foo = new Foo("I'm foo");
    var tmp = foo.boo;
    foo.debug();
    stdout.printf ("temporary boo addr: %p\n", tmp);
    stdout.printf ("refcount: %u\n", tmp.ref_count);
    foo = null;
    stdout.printf ("temporary boo addr: %p\n", tmp);
    stdout.printf ("refcount: %u\n", tmp.ref_count);
}

Výstup si může každý otestovat sám:

_boo addr: 0xd96e30
temporary boo addr: 0xd96e30
refcount: 2
temporary boo addr: 0xd96e30
refcount: 1

Tedy, implicitně se vždy vrací owned, a pokud to má být jinak, musí se to vynutit. Obecně ale platí, že právě v případě různých Gee kontejnerů si na to prostě musí člověk dávat pozor, a vše hezky kontrolovat proti dokumentaci :)

Pokud sem něco pochopil špatně, tak se omlouvám, ale z článku to takhle vyplývá.

[v.podzimek]

Tedy, implicitně se vždy vrací owned, a pokud to má být jinak, musí se to vynutit.

On to s tím "implicitně" asi nebude tak jednoduché. V případě TaskCollection.dump se vrací nově konstruovaný string, který bez použití owned prostě zanikne s tím, jak skončí get blok. Pokud se v tomto případě owned vynechá, kompilátor hlásí warning a program segfaultuje. Stejně tak i tutoriál Valy říká:

In contrast to normal methods, properties always have unowned return value.

a také

The keyword owned can be used to specifically ask a property to return a owned reference of the value, therefore causing the property value be reproduced in the object side.

Ne že by to souhlasilo s výsledky toho příkladu...

[spam]

I am hoping that you will continue writing this kind of blog. Thanks for sharing this information Click this

[spam]

Awesome! Learned alot thanks so much keep posting more. hairextensionsforthworth.com

[spam]

Well this is great site! Would definitely recommend this to my friends. Love the read boudoirphotographyspokane.com

[spam]

Well this is great site! Would definitely recommend this to my friends. Love the read life lesson