>
> > 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.
Ok, just keep it in mind.
>
> > 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...
I disagree. Building a DLL is not hard, a DLL consists of X sources and X
lib's and that's it. There is really not more to it. The pain everytime is:
how do I compile my sources with a specific compiler and a specific platform
and how do I link the bunch together. A generic build system has to provide
this abstraction. It knows all the command switches to compile a C or CPP
source with Mingw32, Bcc, Visual Studio, Watcom, ...
These switches really don't change and are static. Maybe when compiling for
another platform some switches should be put different, but this is the
generic build system problem. The open source library only defines in a
default config file, these are the sources that should be compiled and this
is the library or dll that must contain these sources. The same goes for the
demo and test cases.
You can even bring this one level higher, the generic build system also
knows the difference between Python, Objective-C, Pascal, C and C++
compiling and linking.
Every make system at present has a really obfuscated language. Nobody wants
to know this language. I agree
>
> 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!
>
Yep, that's a really C++ problem, how to deal with them damn INT. But if one
project would just once generically tacle this problem, nobody has to
#define BYTE unsigned char OR #define BYTE char (because the
compiler can't handle unsigned char)
>
> 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...
>
At present it is, because the low level tools are missing and everybody is
writing his own low level tools.
>
> > 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.
No, it would be a GOOD thing if libraries are more open and want to talk to
each other. But I guess it's a human problem: "I do not want to talk to you,
because you are Linux minded and I'm Apple minded". (Replace Linux and Apple
with all sorts of things).
>
> > 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.
So there is a need for modern tools in older platforms.
>
>
> > 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.
Podofo has documentation and I must compliment Podofo because it just
takes 2 or three steps to compile Podofo IF all other libraries are already
in place. But what's lacking in almost every open source project is a
detailled document how to compile the other libraries and in the end the
whole. Mostly (if present at all) there is a reference to a library needed
and that's it. Good luck with it, find it out yourself (again).
>
>
> > 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.
Maven, or something else, I don't know all the build systems. Build a super
build system, outputting CMAKE, MAKE, MAVEN, YAM, or whatever scripts. And
this super build system has to work under ALL platforms, not just the SH
shell.
This is what I'm really missing, configure some settings press a button and
voila, done.
>
> > 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.
Yep I have done this and done it often. The job is no fun, but in the end
the dll/library can be used by many others. In the end it saves time. (I did
this for my job, not for open source).
>
>
> 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.
There is the MONO project. I agree Microsoft keeps expanding it's .NET util
libraries, but if you really look at what they are doing, it's just a new
coat around existing WIN32 technology.
>
>
> > 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.
The low level .NET framework is a international standard (I believe it's a
ISO standard). Though Microsoft is providing many own libraries the core of
.NET is standarized. The standard is portable, see the MONO project.
Regards,
Mirco
------------------------------------------------------------------------------
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
