DC++

STLPort, its necessity and its downsides

Asked by Adrian Moș

I wish to know why is STLPort a necessity in DC++ (apart from it being part of the distribution since the dawn of DC++).

I'm asking this honestly, because I have a very negative opinion on it. It seems to me that it has some issues that should not be there for something that claims to be "the industrial standard for multi-platform development", like:
- no proper support for 64-bit - my compiler(s) report a big ammount of possible compatibility issues even without running advanced in-depth code analysis
- no proper support for multi-core computers - running that advanced in-depth code analysis has actually suggested that STLPort wasn't fit for multi-threaded multi-processed applications (so go figure...)
- no basic builds - they only give out the source code, whereas they could maintain, perhaps, 2-3 basic builds
- compiling problems - yes, it works just fine compiling on Windows XP SP2 32-bit with Visual Studio 2003, but I have yet to find a way to actually compile it on Vista SP1 64-bit with Visual Studio 2008 (that if I ask for a 32-bit build, because the 64-bit build doesn't even go past the first file, and I really don't have the time to watch what compiler symbols are missing or where the functions used have become obsolete)
- sometimes uselessly bloats the source code (and they say it on their website as well)
- DC++ used a modified version of it at a certain point

Now I'm certain that an experienced STLPort coder will be able to go past these problems (apart for the first two, I think), but for most people it's prohibitive.

Is there no way to eliminate the dependency and make DC++ source code cleaner and more efficient?

Question information

Language:
English Edit question
Status:
Solved
For:
DC++ Edit question
Assignee:
No assignee Edit question
Solved by:
MikeJJ
Solved:
Last query:
Last reply:
Revision history for this message
Pietry (pietry) said : 		#1

STLPort is a nice implementation of the STL for C++. Why would anyone want to rewrite everything that stlport does from scratch ? We live in modern ages and we don't want to reinvent the wheel all over again.
1) your compilers ? If you want to use another compiler than the one recommended for DC++ then you're going on shaky grounds and you'll have to manage yourself. 64-bit is not yet possible since there is no 64 bit mingw port. Perhaps in the future the stlport devs will make some version...
2) multicore computers are still quite new, perhaps newer versions will attend this feature ..
3) the library is mostly for people who include only parts of the source code in their projects or make a custom build, that would better fit their needs. Having 2-3 basic builds wouldn't help anyone since everybody wants it differently. I don't see any point in having binaries distributed for a library because if you use it, you probably have the competence of compiling it and your program.
4) Again, you're using another compiler. stlport compiles nice with vs2005 iirc, but anyway, compiling under certain os and with certain compiler isn't really such an issue. You aren't really looking to compile it with every single compiler aren't you ?

And, stlport comes "as it is" with no warranty. Overall, I think it does more good than bad.

Revision history for this message
Best MikeJJ (mrmikejj) said : 		#2

Also a few more comments, STLPort is only necessary for Visual Studio now. When using mingw, it's not needed.
To fix compiling problems with Visual Studio 2008, use the svn version of STLPort not the last release.
Sure the "modified version" was just 2 or 3 changes to the Config file. The file which is meant to be changed to suit what you are building. :)

Revision history for this message
Adrian Moș (adimosh) said : 		#3

MikeJJ, presuming that we ever meet in real life, remember to smack me over the head.

It has indeed never occurred to me to actually use the SVN of STLPort. As many modifications to the config file there are, you must understand that I really don't have the necessary time to look through all the symbols and see which are defined and which aren't (compiling problem was mainly due to symbols not being properly defined, the source code modifications in the SVN version for this specific purpose were otherwise minor).

SVN version of STLPort does compile nicely, though there is still no real 64-bit support (and it still damn well uses a lot of deprecated build options) and no multi-core optimizations, but that isn't necessarily a problem.

As I'm posting now, I still have to figure out how to get through the "dcplusplus\dwt\include\dwt\widgets\../Widget.h(48) : fatal error C1083: Cannot open include file: 'tr1/unordered_map': No such file or directory" error (seems that there is a bigger issue, since pointing to the specific include file solves it, but there are many many other problems like this). The appears in both MinGW and VS2008, so I presume I forgot to either define something in my configs or point to include directories in a specific order. By the way, any quick-help here would be appreciated.

Revision history for this message
poy (poy) said : 		#4

if you really want to use a different version of STLPort, you have to specify it in the arguments passed to SCons (see Compile.txt). otherwise, using the compiler's STLPort should be just fine...

Revision history for this message
Adrian Moș (adimosh) said : 		#5

Thanks MikeJJ, that solved my question.