On Wed, 2009-07-15 at 09:18 +0200, Mirco Babin wrote:
> I'm sorry, it was a LOT of pain to compile podofo, because I also had > to compile the dependencies (freetype, jpeg, zlib). I'm not going to > compile this again with MS Visual Studio. Fair enough. I know just how awful developing in C/C++ on Windows is, and do it as little as possible. > The STL stream wchar_t* problem, I would introduce a #define in > PdfDefines that configures the availibility of wchar_t* streams. Here > you could try to detect if a platform supports this. If it can't be > detected you only have to disable this global #define. Yep. We can define that conditionally in CMake depending on the detected compiler/platform. I'd say "I'll get on to that" but right now, I don't know if I will. I'm pretty flat out with work. > I don't know JAVA, but I agree upon your vision c++ lacks lots of > tools. And it would be VERY nice if all open source projects would use > the same BUILD system (e.g. CMAKE of YAM). The problem is that they all suck. Some are less awful than others, but they're all awful. Nobody's going to agree on just one, ever: - Some are happy with what they have. For their needs, it works, and they know it. They're not going to change. - Some don't care about issues important to others. Lots of open source library developers couldn't care less if their lib can be built on Windows or not, for example, making it painful for those who depend on it. - Some libraries ( eg libjpeg ) haven't changed in years. - Some are constrained by policy (eg: GNU projects and autotools ). - Some find that others' "best" build system doesn't do things they need. Some Qt projects have real issues with some build systems, for example. Even Java has several different build systems - at least ant and maven. That for a language with one primary compiler/runtime, and one that's largely platform independent, shows how you're never going to satisfy everyone. The problem with C++ builds is hundreds of times more complex than in Java... > And it would be even nicer if all open source projects would support > Linux and Windows builds. This last problem should be handled by the > generic BUILD system. It's just not that simple. First, there's at least Linux, Mac OS X, Solaris and Windows to consider. Second, there are different versions of each, and each has at least a couple of different compilers, and different versions of those compilers. Off the top of my head: Windows/Borland [ia32] Windows/MSVC++6 [ia32] Windows/MSVC++7 [ia32] Windows/MSVC++8 [ia32, ia64, x86_64] Windows/MSVC++9 [ia32, ia64, x86_64] Windows/MinGW [ia32, x86_64?] Mac OS X/gcc [ia32, x86_64, ppc32, ppc64] Mac OS X/CodeWarrior [ ? ] Linux/gcc3 [ia32, ia64, x86_64, ppc32, ppc64, mips, ... ] Linux/gcc4.4 [ia32, ia64, x86_64, ppc32, ppc64, mips, ... ] Linux/icc [ia32, ia64, x86_64 ] ... of course that's rather oversimplified and doesn't consider dependency library versions or the like. Each of these have subtle differences in type availability and behaviour, type sizes, etc. Since every library lands up rolling their own type wrapper names and those tend to collide or be inconsistent on some platforms, that's yet another shrieking nightmare not covered by build systems. How hard can it be to say "get me whatever integer fits in 8 bits" ? Very hard, if you're using C++. Sure, you can use int8_t from c99's stdint.h, but that's not included in C++ officially, only provided by some newer compilers, etc. Define your own, and clobber someone else's definition. Argh! I'm increasingly convinced that trying to write portable, high level application software in C++ is an exercise in unnecessary self-torture. Frameworks like Qt make it a lot more bearable, but without them... > What is missing in the open source community is a lowlevel c / c++ > library containing an abstraction to the OS. No it's not. Which one do you want? The Apache portable runtime? The Netscape portable runtime? ... Now you have to make your various portable runtimes talk to each other instead. Problem: multiplied. > What I have seen is everybody writes his own stream class in C, > writes his own memory management, writes his own string class, > hopefully uses pthreads, uses #define's for some c runtime api, so it > can be changed, ... ... because the core language facilities provided by C and C++ are so hopelessly behind the needs of modern applications, and even if they weren't people would still insist on using f**ing MS Visual C++ 6 in 2025 so you couldn't use them. > And last but not least, there should be documentation how to compile a > open source project AND ALL OF IT'S DEPENCIES yourself. We have that, at least, in PoDoFo. Bad documentation, I suspect, but it's there. > If everybody would use the same BUILD system, this probably could be > automated. You just described Apache Maven, primarily used for collecting and building dependency trees for Java software. > Also every open source project should have a C style interface. This > really broadens the range of languages it can be used in. It also makes it awful to implement even some simple things. Ever tried applying C to a problem that's well-handled by object oriented programming? It's not fun. Ever tried writing a C wrapper for C++ interfaces? It's less fun. Personally, I think Microsoft has it right. The C linkage and runtime interface is obsolete. Throw it away, and introduce a much more capable and higher level standard like the .NET common language runtime. Unfortunately, it's never going to be as universal as C, not least because MS keep on adding to it and don't have any interest in keeping it portable. > I know you are going to say, what about Java. Well Java is just one > language that is very well build, .NET are many languages that can > talk to each other. If your favorite language is Delphi, just program > a Delphi dependency, give it to a C# programmer and he can use it, > without any problems. I tend to agree ... so long as you're running on Microsoft's platforms, and have the same version of the CLR. I'm really disappointed that MS released three versions of the CLR in short order, and that they've shown little interest in making it the new universal standard runtime across _all_ platforms. -- Craig Ringer ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Podofo-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/podofo-users
