Recent Features
| |||||||||||||
Sobotka: Why GIMP is inadequateSobotka: Why GIMP is inadequatePosted Jan 14, 2011 15:00 UTC (Fri) by HelloWorld (guest, #56129)In reply to: Sobotka: Why GIMP is inadequate by paulj Parent article: Sobotka: Why GIMP is inadequate
Re templates: I don't know enough about the history of C++, but that to me sounds like C++ settled for a bodged version of generics because of implementation compromises.They're not, and I already told you why: generics are less flexible and require a boxed data representation, at least in any implementation of generics I know of. And if templates were merely a sucky replacement for generics, why did the developers of the D language choose to implement templates as well? RAII: C doesn't explicitly have support for implicitly calling a custom per-object deallocator on free(),It's not about calling a custom deallocator on free but about implicitly doing something (like unlocking a mutex or decreasing a refcount) when an object leaves some scope. This needs some form of language support. <ramblings about caching>Well, if you think that qsort offers a better tradeoff than std::sort, you can still write an easier to use, type-safe wrapper.
template<typename T> int compare(const void *, const void *);
// implementation left as an exercise for the reader
template<typename T> void my_sort(T *base, size_t nmemb) {
return std::qsort(base, nmemb, sizeof(T), &compare<T>);
}
As for C#, Java, Vala, etc and rewriting the GIMP: this discussion about C v C++ started because people criticised GIMP for being in C and suggested C++ would be better. Where's the evidence for this claim? Even if we accept C++ has merits over C, exactly how does this make C++ the correct choice *today* for programming large, end-user applications? If the answer isn't C, then it surely isn't C++ either...I think that reasons were given for preferring C++ to C (templates, OOP, RAII, namespaces); of course, you're free to disagree with these. I also didn't claim C++ is the right choice for an application like the GIMP if it were written today, and it probably isn't, as a low level language like C++ is probably a poor choice for a graphical app today. It merely annoys me when people like cmccabe keep trolling against C++ and do as if C were the holy grail of systems programming languages.
(Log in to post comments)
Sobotka: Why GIMP is inadequate Posted Jan 14, 2011 16:29 UTC (Fri) by paulj (subscriber, #341) [Link]
Generics have a sound body of type theory behind them though. Boxing types - I don't see a problem with that for OOP. And from what you say, the error-message problem is actually somewhat fundamental to templates. I really hate templates I have to say.
Re implicit destructors for automatic variables. True, that requires language support. OTOH, C++ allowing automatic storage objects is one of those things that lead to subtle corner-cases, ISTR...
Anyway, our opinions clearly differ. ;)
Sobotka: Why GIMP is inadequate Posted Jan 14, 2011 18:32 UTC (Fri) by HelloWorld (guest, #56129) [Link] Generics have a sound body of type theory behind them though.C++ templates have been studied by type theorists too, see for example this paper. Boxing types - I don't see a problem with that for OOP.C++ is not only object-oriented, and in fact, containers are very often used for built-in types like int. Boxing these is ridiculously inefficient. Re implicit destructors for automatic variables. True, that requires language support. OTOH, C++ allowing automatic storage objects is one of those things that lead to subtle corner-cases, ISTR...Like what? I always found implicitly called destructors to be a boon. Much more so than, say, Java's finally blocks. Alas, YMMV and as you already said, we should probably just agree to disagree :).
Sobotka: Why GIMP is inadequate Posted Jan 14, 2011 20:34 UTC (Fri) by HelloWorld (guest, #56129) [Link]
> And from what you say, the error-message problem is actually somewhat fundamental to templates.
A similar problem applies to dynamically typed languages like python though. The interpreter can't possibly know whether the type of a function argument satisfies the requirements of the function it is passed to. The difference being that a C++ compiler will point that out at compile-time, while a dynamically typed language won't throw up until run-time, much less give you a sensible error message.
Poor implementations are also part of the problem. g++'s error messages are worse than they could be, for example it always talks about std::basic_string<char, std::char_traits<char>, std::allocator<char> > instead of plain std::string (the latter being a typedef for the former). Clang++ is supposed to be much better at this, though I haven't tried it yet.
Sobotka: Why GIMP is inadequate Posted Jan 18, 2011 20:06 UTC (Tue) by daniel (subscriber, #3181) [Link]
"I really hate templates I have to say."
For me it's a love hate relationship. I love the way I can generate efficient code from terse, readable source. I hate the way compile errors get weirder and weirder, the the latter may be as much an implementation issue as anything. Templates are really just a highly automated form of cut and paste that allows you to create *maintainable* cut and paste code, and package it for general use.
The extent to which cut and paste code abuses the processor cache says more about the programmer than the mechanism. I use partially specialized templates to create efficient variant forms of low level graphical operations. The initial pure C code base I developed to do the same thing grew tendrils and degenerated to to an unmaintainable state rapidly so that working on it slowed down and became deeply unappetizing. After being recast as an orthogonal set of C++ templates the source code shrank by a multiple and I was able to add the sophisticated new capabilities that seemed only a distantly obtainable hope with the original C code base. The actual generated code hardly changed, just my ability to develop it.
|
|||||||||||||