Hmm, does the name "GTK" mean "Gnu Tk"? I thought this was "Go Tk" for a moment when I read the title.
GIMP toolkit, as in the graphic package.
Gotk3: GTK3 the Go way
11–20 of 58 posts
Re: Gotk3: GTK3 the Go way
#12I was kinda meh on Go (reminded me of my days in the Ada code), but making native GTK Apps seem really interesting to me. Will have to check this out.
I'd say both Go and Ada are much nicer than C and C++ though :P
Re: Gotk3: GTK3 the Go way
#13Slightly off topic, but something I've been curious about. Go decided on garbage collection to manage memory. Why do so few languages offer something like C++'s RAII?[1]
In C++, when you define a class, you define the constructor(s) and the destructor. Then the destructor is called whenever the object goes out of scope. Easy. This is the gist of RAII. Furthermore, in C++, a default destructor is automatically generated for you, which will ensure all the objects members are destructed with your object,[2] so you can avoid even worrying about the destructor.
Yeah, it's not as simple as GC, but it seems like a great compromise between manual memory management and garbage collection.
[1]: http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initial...
[2]: Provided no members are dynamically allocated. If you allocate an array in your constructor, for example, you need to free it in the destructor. You need to define a destructor to free dynamically-allocated memory, or to do other cleanup.
Re: Gotk3: GTK3 the Go way
#14Slightly off topic, but something I've been curious about. Go decided on garbage collection to manage memory. Why do so few languages offer something like C++'s RAII?[1] In C++, when you define a class, you define the constructor(s) and the destructor. Then the destructor is called whenever the object goes out of scope. Easy. This is the gist of RAII. Furthermore, in C++, a default destructor is automatically generat…
Preferring RAII over garbage collection is the decision that Rust made.
Probably the reason that more languages don't use RAII for memory management is safety. C++, even with RAII, is not safe—you can violate memory safety with certain uses of references and iterators. Rust has to go to great lengths (lifetimes and the borrow check—things that have only been in the research landscape) to make this safe.
Re: Gotk3: GTK3 the Go way
#15Slightly off topic, but something I've been curious about. Go decided on garbage collection to manage memory. Why do so few languages offer something like C++'s RAII?[1] In C++, when you define a class, you define the constructor(s) and the destructor. Then the destructor is called whenever the object goes out of scope. Easy. This is the gist of RAII. Furthermore, in C++, a default destructor is automatically generat…
It's more error prone than GC and there aren't really enough advantages to RAII to make it worth it much of the time. Sometimes, sure, but GC is nicer and usually fits the bill.
Re: Gotk3: GTK3 the Go way
#16Slightly off topic, but something I've been curious about. Go decided on garbage collection to manage memory. Why do so few languages offer something like C++'s RAII?[1] In C++, when you define a class, you define the constructor(s) and the destructor. Then the destructor is called whenever the object goes out of scope. Easy. This is the gist of RAII. Furthermore, in C++, a default destructor is automatically generat…
It's more error prone than GC and there aren't really enough advantages to RAII to make it worth it much of the time. Sometimes, sure, but GC is nicer and usually fits the bill.
How is it more error prone than GC?
Re: Gotk3: GTK3 the Go way
#17Slightly off topic, but something I've been curious about. Go decided on garbage collection to manage memory. Why do so few languages offer something like C++'s RAII?[1] In C++, when you define a class, you define the constructor(s) and the destructor. Then the destructor is called whenever the object goes out of scope. Easy. This is the gist of RAII. Furthermore, in C++, a default destructor is automatically generat…
This approach starts getting brittle when you get into objects that aren't procedure-scoped; for instance, a global session table in a web application, or a request token tracker in an RPC system. These are also the kinds of object lifecycles that tend to be behind leaks and corruption in programs that don't use RAII.
People use shared pointers to mitigate that problem, but shared pointers are (a) a reference counting scheme with all the attendant problems and (b) not compatible with code that holds references but doesn't speak the same shared pointer scheme.
(It's been a bunch of years for me since I wrote C++ professionally; that may show here.)
Re: Gotk3: GTK3 the Go way
#18Earlier quoted context omitted.
It's more error prone than GC and there aren't really enough advantages to RAII to make it worth it much of the time. Sometimes, sure, but GC is nicer and usually fits the bill.
How is it more error prone than GC?
Are you asking what kinds of errors RAII-style C++ programs make that you can't make in Golang (an easy question), or what kinds of errors you can make in Rust that you can't make in Golang (harder)?
Re: Gotk3: GTK3 the Go way
#19Earlier quoted context omitted.
(That worked.)
If you want the latest Go version on Ubuntu : http://blog.labix.org/2013/06/15/in-flight-deb-packages-of-g...
You can also just build tip on your own locally. Go has virtually no hard dependencies other than gcc (and mercurial to get the repo, unless you pull the code some other way).
hg clone http://code.google.com/p/go
cd go/src
./make.bash
Same holds true even on Windows if you have a local gcc like MinGW (the only notable difference is you'll execute make.bat instead of make.bash if you're in a Windows cmd shell instead of bash).
Re: Gotk3: GTK3 the Go way
#20Earlier quoted context omitted.
How is it more error prone than GC?
Are you asking what kinds of errors RAII-style C++ programs make that you can't make in Golang (an easy question), or what kinds of errors you can make in Rust that you can't make in Golang (harder)?
I'm just questioning the assumption that RAII as a concept must be memory unsafe, specific language aside.
Edit: To be clear it's the latter question, but more general. C++'s implementation has many opportunities for errors, but I do not think the technique is inherently unsafe. (PL research has proven many similar systems based on unique types and borrowing to be type- and memory-safe.)