A new cross platform c++ framework (another)

[XShadow]

Hi, I'm working on a new cross platform c++ framework, I principally
wrote it for fun in my spare time. The project becomes rather large so
I decided to make it available on the web in the hope that it can be
useful to someone. I'd like to have some feedback from you all, any
suggestion or criticism are welcome. The project is released under open
source license and everyone can contribute to it.

Cross platform toolkit library (xtklib)
http://xtklib.berlios.de

Thanks in advance,
with regards,
XShadow.

 

[gamehack]

Cool I'll check it out ASAP

 

[Guest]

Hi, I'm working on a new cross platform c++ framework, I principally
wrote it for fun in my spare time. The project becomes rather large so
I decided to make it available on the web in the hope that it can be
useful to someone. I'd like to have some feedback from you all, any
suggestion or criticism are welcome. The project is released under open
source license and everyone can contribute to it.

Cross platform toolkit library (xtklib)
http://xtklib.berlios.de

Interesting.
Why following is a a feature?

STL free - Does not use any STL facility since all its features are
implemented in our library following our programming techniques and
philosophy for a full intregration with other classes.

Cheers

 

[David]

Interesting.
Why following is a a feature?

STL free - Does not use any STL facility since all its features are
implemented in our library following our programming techniques and
philosophy for a full intregration with other classes.

Cheers

That sounds like a reasonable design decision. It would insulate them
from requiring their product to include a full STL for all supported
platforms. It may not be reasonable to assume that everyone has the
same STL installed. That would not prevent a developer from using the
STL in their own code base.

Please also understand that any given STL implementation (or toolset
in general) may not meet everyone's develpment needs. They made a
choice on how they want to control their source thus far and stated it.
Perhaps they have their own pre-STL tools or methods they choose to
rely on.

David

 

[peter koch]

David skrev:

That sounds like a reasonable design decision. It would insulate them
from requiring their product to include a full STL for all supported
platforms. It may not be reasonable to assume that everyone has the
same STL installed. That would not prevent a developer from using the
STL in their own code base.

This is just silly. All compilers today do support "STL" - at least if
it is used to denote the standard C++ library (e.g. std::vector and
stuff like that).

Please also understand that any given STL implementation (or toolset
in general) may not meet everyone's develpment needs.

I highly doubt that. Even in the unlikely situation where someone chose
to not use the standard library, why do you expect that they could use
the supplied library instead?

They made a
choice on how they want to control their source thus far and stated it.
Perhaps they have their own pre-STL tools or methods they choose to
rely on.

This just puts an enormous burden for the vast majority that chose to
use the standard library - requiring conversion to/from the standard
types. Do you believe that is an incentive to use the library? For me
this alone is reason enough for not looking further into the library.

David

/Peter

 

[XShadow]

That feature means that the library internally does not use STL for
various reasons:
1) Portability: STL implementations too often differs both in behaviour
and in interface. Sincerely, for this reason, I never like use STL
2) The library is Object based, that means that *all* classes need to
inherit xObject. STL classes does not.
3) STL lack some features needed in the library. For example the
std::string class does not support conversion from unicode to various
encodings, and this is fundamental for the library. Another example are
streams. Thake a look at STL streams and then look at xtklib streams
hieararchy, they are totally different!
In conclusion STL does not provide an adequate integration with the
rest of the library. Obviously, this not prevent you from using STL in
your application, although this is not recommended.

 

[Axter]

That feature means that the library internally does not use STL for
various reasons:
1) Portability: STL implementations too often differs both in behaviour
and in interface.

If you're using a C++ compliant STL library, then it should not differ
in interface. And any behavior differences should not be enough of a
justification not to use the library.
IMHO, your #1 reason is not justifiable.

2) The library is Object based, that means that *all* classes need to
inherit xObject. STL classes does not.

This is valid.

If the library is not using STL, does it use templates in general?

And do you have an interface for accepting std::string, or do users
have to convert std::string to your library supported string type?

If it doesn't, I would recommend that you at least add an interface to
your library so that it can accept or convert the std::string type to
your library supported string type.
Same recommendation for iostream.

 

[XShadow]

If you're using a C++ compliant STL library, then it should not differ
in interface.

This is partially true. For example, I can remember that some methods
(I dont remember which) does exist in mingw32 STL implementation and
does not in Visual C++. However ,this is not the key reason that
persuaded me about not using STL.

And do you have an interface for accepting std::string, or do users
have to convert std::string to your library supported string type?

Yes, this is an important issue that must be taken in consideration.

 

[Axter]

Hi, I'm working on a new cross platform c++ framework, I principally
wrote it for fun in my spare time. The project becomes rather large so
I decided to make it available on the web in the hope that it can be
useful to someone. I'd like to have some feedback from you all, any
suggestion or criticism are welcome. The project is released under open
source license and everyone can contribute to it.

Cross platform toolkit library (xtklib)
http://xtklib.berlios.de

Thanks in advance,
with regards,
XShadow

In the Abstract link, it states the following:
******************************************************************************************************
gcc and VC++ supports all modern features of C++ and gcc is available
virtually in every platform.
******************************************************************************************************
Neither the GNU compiler nor VC++ supports all modern features of C++.
The both don't support export.
I'm sure there are other non-compliance issues, since no compiler that
I'm aware of can claim to be fully C++ compliant.

It also states the following:
******************************************************************************************************
XTKLib tries to create a strongly object-oriented framework by using
all the power of modern C++
******************************************************************************************************
IMHO, that's not an accurate statement if you're not using STL.
You have a similar statement in the Features link.

Also, stating you're STL free, is not something that I would put on a
feature list.
IMHO, that's more of detraction, and not a bonus.
My interpretation of a library that claims to be STL free is that the
library author(s) hand coded, or created their version of the logic
normally found in the STL library. The results of which usually lead
to bugs, inefficiency, non-portability, and/or a higher maintenance
cost.
I'm not saying this is true of your library. I'm just saying this
would be my first impression/assumption. You might find many other
developers to have a similar impression.

I recommend removing this of your feature list.

I notice that the "Compile,install and link" document gives the
impression that it mainly support VC++ 7.1.
If VC++ 6.0 is not supported, then I would recommend you modify your
Abstract and Features links to specify which version of the compiler
you support.
I would also like to see a link that shows on which compilers the code
has been tested.

I like the way you did the web site, but if this is non-profit, why did
you not try to use a *.org instead of *.de?

 

[Gavin Deane]

This is partially true.

By definition, Axter's statement is entirely true.

For example, I can remember that some methods
(I dont remember which) does exist in mingw32 STL implementation and
does not in Visual C++.

Then one or the other is not compliant.

Gavin Deane

 

[XShadow]

Then one or the other is not compliant.

In short words: Yes , but this is not a point in favour for STL.

 

[XShadow]

Neither the GNU compiler nor VC++ supports all modern features of C++.

The both don't support export.
I'm sure there are other non-compliance issues, since no compiler that
I'm aware of can claim to be fully C++ compliant.

Yes, maybe I have used a wrong expression. I wanted to refer to
specific features like RTTI, exceptions and templates. Thanks for the
advice.

IMHO, that's not an accurate statement if you're not using STL.
You have a similar statement in the Features link.

Yes, the same as above

I recommend removing this of your feature list.

I will take this in consideration.

I notice that the "Compile,install and link" document gives the
impression that it mainly support VC++ 7.1.
If VC++ 6.0 is not supported, then I would recommend you modify your
Abstract and Features links to specify which version of the compiler
you support.
I would also like to see a link that shows on which compilers the code
has been tested.

Unfortunately I cannot test the library in every platform with every
compiler, for this task I need the help of the users (or someone
else). Until someone does not compile the library in VC++ 6.0 I cannot
say that it is compatible with this compiler neither it is not.

I like the way you did the web site

Thanks

, but if this is non-profit, why did you not try to use a *.org instead of *.de?

This is because the web space and domain is kindly offered by BerliOS
(an organization that give services similar to SourceForge.net)
take a look at http://developer.berlios.de/

 

[David]

Hello Peter,

I'll give a short response to the points that others have not addressed.

David skrev:


This is just silly. All compilers today do support "STL" - at least if
it is used to denote the standard C++ library (e.g. std::vector and
stuff like that).

So I'm only going to be able to use the library if I have a fully
compliant C++ compiler from 2005? I use four C++ compilers at home
for various tasks and each one is from roughly a different 5 year period.
One has STL support and another has four add on STL implementations that
were in the public domain at the time.

At work I have six C++ compilers that target various processors,
operating systems, and eras (C++ standards). Of those three have no
STL support, though they probably could use the public STL implementations
with a little tweeking. One two of the six C++ compilers target an OS
such as Windows or linux. The others don't have GUIs so some of the
library wouldn't be usedful... though one of those platforms does have
a small graphics screen and menu system that was written by us.

I've also been using templates since about 1990 with a compiler that
always supported templates of templates and very intracate concepts.
We had a rich set of ideas long before the STL came about and it
still surpasses the STL for our needs. [Think of algorithms specialized
for speed of certain operations.]

I highly doubt that. Even in the unlikely situation where someone chose
to not use the standard library, why do you expect that they could use
the supplied library instead?

So are you saying that if a developer needs a concept that is in the STL
that they should use the STL implementation without regard to deciding
if the STL actually meets their development tasks?

This just puts an enormous burden for the vast majority that chose to
use the standard library - requiring conversion to/from the standard
types. Do you believe that is an incentive to use the library? For me
this alone is reason enough for not looking further into the library.

I've had no trouble using old style calls with data from the STL
and vice versa. Developers always have the burden of deciding if
the tools they use (STL or xtklib) fit their needs. Perhaps wrapping
some of the interfaces would help you complete your goals... and that
might be helper functions on the STL side or xtklib or whatever.

/Peter

D Davidr