Sign in to follow this  

Unity STL malignant or benign

This topic is 4531 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I vote malignant. I can't believe how much people are using different versions of core classes for anything from regular expressions to just common hash tables. It has grounded my development to a hault cause I just can't seem to get compatible libraries for simple things such as a hash table or even the most usefull string class. Definitely a complete pain! Please, feel free to disagree but man I'm upset with the open source community for not having an actual standard set of template classes that are used.

Share this post


Link to post
Share on other sites
Errrrm.... the STL IS standard. And for stuff it doesn't currently include, most people use Boost. You can be upset with developers for not using them, but I don't think anyone would argue that there isn't "an actual standard set of template classes that are used".

Share this post


Link to post
Share on other sites
Well, I have boost I donwloaded it and deleted it like ummm about 5 times now and I have Dev-Cpp and I have cygwin and mingw and I also have microsofts version of the C++ stls for VC++ 6 and still I can't get things to compile because of missing headers lots and lots of crappy missing headers.

I've got about zero patience right now so please forgive me!

[edit: and by the way I'm attempting to work with an ogre project right now but I also am having a terrible time with boost, crystalspace, and wxwidgets. Using them in my projects that is.]

[Edited by - 5MinuteGaming on July 19, 2005 3:33:12 PM]

Share this post


Link to post
Share on other sites
I agree with Sneftel. Your rant sounds like a poster-child argument FOR the STL (and Boost). That way, you can be sure people are coding against the same class interfaces. Beats having to deal with multiple custom implementations...


edit - Well looks like you've got either yourself or VC6 to blame... What are the errors you get, precisely? What headers are missing? Are you sure they are standard C++ headers, or are you relying on obsolete, pre-standardization libraries ... which would rightfully not be provided anymore by C++ vendors as they get superceded by standard libraries? Beware of online tutorials...

Share this post


Link to post
Share on other sites
Quote:
Original post by 5MinuteGaming
Well, I have boost I donwloaded it and deleted it like ummm about 5 times now and I have Dev-Cpp and I have cygwin and mingw and I also have microsofts version of the C++ stls for VC++ 6 and still I can't get things to compile because of missing headers lots and lots of crappy missing headers.

So you've approached your build environment in more or less the same manner that an angry monkey would approach a china cabinet. I suggest that rather than continually downloading and deleting stuff, you GET some patience and try to figure out ONE problem at a time.

Share this post


Link to post
Share on other sites
Sneftel, well my rant has to do with the fact that it seems to work for every other person on the planet but me. Sure they download and compile and ah no problems but not for me.

I have patients to work through each problem that occurs. First I locate the missing file and add it to the include path and then I get a problem with the one I added so I find that missing file and then I get another missing file somewhere else then I get a duplicate definition problem. I must be missing something awefully big cause I shouldn't have to go through and change all the headers of a project like ogre's source in order to get it to compile.

Share this post


Link to post
Share on other sites
The problem is that you are using an 8 year old compiler with an STL that predates the standardization of STL and does not properly support many constructs required for the STL to function properly.

To fix this, download STLport.

Share this post


Link to post
Share on other sites
Well if you have a specific problem, make a thread in Programming forum detailing it and there is a very good chance it will get solved.

Share this post


Link to post
Share on other sites
"The Standard Template Library", commonly abbreviated as "The STL", now known as The Standard C++ Library (which I abbreviate as "The SC++L"), is a well defined standard well supported by the open source community. If you're using GCC 2.95, expect to see some problems - why? Well, GCC 4.0 is out. 2.95 is ancient. It's not the fault of the community as a whole if your distro's mantainers can't be arsed to update the shipped compiler.

You can get GCC 3.4.4 prebuilt for windows via MinGW or Cygwin, both of which support the SC++L quite nicely (well, minus locales on windows) and you can use these to build 4.0 as well.

[Edited by - MaulingMonkey on July 18, 2005 10:51:03 PM]

Share this post


Link to post
Share on other sites
Quote:
Original post by 5MinuteGaming
I'm using gcc 3.4.4 and have cygwin installed.

Then prehaps you're refering to out of date documentation? GCC 3.4.4 is a fine compiler with a fine implementation of the standard library. I had no problems following Boost's "Getting Started" installation guide with installing Boost on MinGW GCC 3.4.2, except for not realizing that boost-jam-3.1.10-1-ntx86.zip was in fact the prebuilt windows version of Boost.Jam (my brain was refusing to make the connection: NT = Windows NT = Windows).

Share this post


Link to post
Share on other sites
You are using VC++6.

VC++6 ships with the old style pre-standardisation headers (like string.h, vector.h) rather than the standard library style headers.

It's little wonder that you couldn't get a program using the standard library to compiler on both gcc3.4.4 and VC++6, seeing as all the std classes are in different headrer and different namespaces with each compiler.

It's also no suprise that you have trouble with boost - boost is extremely template heavy - the template support in VC++6 is totally inadequate for boost.

Why use VC++6 when you already have gcc3.4.4? If you want two different compilers to test against then download the optimizing compiler the microsoft give away for free.

Share this post


Link to post
Share on other sites
Quote:
Original post by Nitage
You are using VC++6.


I was under the impression he was mainly trying to use GCC? VC++6 is prestandard and a piece of dung not worthy of my toilet bowl (Okay, maybe not that bad (especially considering said toilet is currently clogged with shit and I have no plunger >_<), but it's support for the standard is quite lacking in many places), so if he's mixing the two together that would indeed cause problems.

SC++L headers should only be used with the compiler they were meant for. -Mike

Share this post


Link to post
Share on other sites
Quote:
SC++L headers should only be used with the compiler they were meant for. -Mike


I didn't mean that he might be mixing the header files, I meant that this would not compile in VC6:

#include <vector>

void foo()
{
std::vector<int> v;
}



and this will not compiler in gcc


#include <vector.h>

void foo()
{
vector<int> v;
}



So the only ways to write code that will compile on both platforms are to either totally avoid the standard library, or use a 3rd party implementation with VC6.

So it isn't a suprise he's been having problems and believes the std library isn't that standard.

Share this post


Link to post
Share on other sites
Quote:
Original post by Nitage
I didn't mean that he might be mixing the header files, I meant that this would not compile in VC6:
*** Source Snippet Removed ***


Im using VC6 at work and trust me that does compile just fine, the problems with VC6 are invalid scoping lacking partial template specializations and that is sometimes get very creative (or lacking in that department) when trying to handle complex templates. But most of the vanilla code encountred will compile just fine or with minor tweaks.

Share this post


Link to post
Share on other sites
Quote:
Original post by DigitalDelusion
Quote:
Original post by Nitage
I didn't mean that he might be mixing the header files, I meant that this would not compile in VC6:
*** Source Snippet Removed ***


Im using VC6 at work and trust me that does compile just fine, the problems with VC6 are invalid scoping lacking partial template specializations and that is sometimes get very creative (or lacking in that department) when trying to handle complex templates. But most of the vanilla code encountred will compile just fine or with minor tweaks.


I was under the impression that VC6 did not ship with the standard headers, only the old style ones. My mistake.

Share this post


Link to post
Share on other sites
Well, Actually my dilemma is quiet mixed. I am using VC++6 for a project that ties in Ogre and CEGUI and have been unsuccessfull in getting it to compile because of missing headers <hash_set> specifically and then <ext/hashtable> when I am able to get to the <hash_set> library header then there are a ton of errors probably as DigitalDelusion pointed out VC6 is lacking in support for template classes which is no suprise to me since I've attempted to make plenty of template classes in VC6 and have always run into problems.

It may be the case that I am trying to use the library header made for GCC with VC6 but my dilemma is that now I need to know where I can get the most recent STL library or the STL library that Ogre uses so there is no compatibility issues with either the compiler and code.

So in short is there a version of the extended STL or STL port that will work with VC6. I noticed in the install for STLport which I downloaded it mentioned something about setting it up for your compiler. I'm still a little lost as to why in God's name you would have to compile a standard library just to use the library unless they mean create the precompiled libraries using your compiler and in that case hmmmm their really lazy and wasting my time.

Please, someone enlighten me I'm so lost its pathetic.

Share this post


Link to post
Share on other sites
Yeah! I already thought of that one. I'm one step ahead of you except the shipping company is not I made the mistake of ordering the CD. But it was free except for shipping which wasn't that bad hopefully I'll have that soon.

I've used Visual Studio with .NET before but didn't really like it but I'll get used to it.

Also, does anyone know how I can configure the STLport with my compiler like I stated before do I have to compile the source to a library file, or run some script or something.

Share this post


Link to post
Share on other sites
Quote:
Original post by 5MinuteGaming
and have been unsuccessfull in getting it to compile because of missing headers <hash_set> specifically and then <ext/hashtable> when I am able to get to the <hash_set> library header then there are a ton of errors


The problem is that the hash_set class is not part of the C++ standard library. When the standard committee decided what should be included, the proposal for hash tables came in too late. It therefore was not included in the standard. Vendors did include hash table implementations of their own and as you have noticed, the Dinkumware implementation (included in VC6) differs from the SGI implementation (included in GCC). One of the main differences in interface is how the hash function is specified.

If you really want to use that hash_set class, you'll probably have to write a wrapper yourself to provide a unified interface and either use conditional compilation or your build process (preferably) to select one implementation or another.

Quote:
So in short is there a version of the extended STL or STL port that will work with VC6. I noticed in the install for STLport which I downloaded it mentioned something about setting it up for your compiler.


STLport should work with VC6.

Quote:
I'm still a little lost as to why in God's name you would have to compile a standard library just to use the library unless they mean create the precompiled libraries using your compiler and in that case hmmmm their really lazy and wasting my time.


The only part of STLport you need to compile is the IOStream library (you know, std::cin, std::cout ...) and even that is optional: if you don't it'll just use the IOStream library that ships with your C++ platform (the reason why you can compile it is because you generally only care about the char and wchar_t specializations of the class templates). The rest of the library is implemented as header files (it's all template code so there isn't much choice). As for them being lazy, do you really think they should provide a binary library build for each and every combination of compilers, architectures, etc? I think not. The Boost C++ library is in precisely the same situation, for all that they do provide you with makefiles supporting a number of compilers.

Share this post


Link to post
Share on other sites
Well, its all completely frustrating, cause there are too many different things that are attempting to work together here that just have no knowledge of each other. That and I don't exactly want to take all that time and become an expert on every single one to get them to compile, but I guess it's just one of the frustrations you have to work through with C/C++, and the open source community.

I guess I shouldn't expect anything from thousands of coders who like to do their own thing. I know cause I'm one of them.

Well, I will attempt to get things to compile with STLport now that I finally know thats what I most likely missed.

And for future reference I hope that you take careful not with any project you have to make sure and DO NOT ASSUME anything if you use STLport say so. And if you use even one class from an external library FOR GOD'S SAKE LET PEOPLE KNOW YOU ARE. IT'S COMMON SENSE WHEN ATTEMPTING TO HAVE OTHER PEOPLE WORKING ON THE SAME PROJECT TO MAKE SURE THEY ARE USING THE SAME LIBRARIES AND THE STL ARE A LIBRARY SO FOR THE LAST TIME PLEASE DON'T MAKE THE ASSUMPTION THAT THEY HAVE IT.

ok I'm done you can stone me now.

Share this post


Link to post
Share on other sites
Quote:
Original post by 5MinuteGaming
Well, its all completely frustrating, cause there are too many different things that are attempting to work together here that just have no knowledge of each other.


There's a difference between working with no knowledge of each other and trying to work independantly of each other. A lot of projects (re)implement simple things like strings even though the standard library has a perfectly fine string class - all in the name of independance from the nuances of the standard library and the many pre-standard STL variants. OSS usually try to support portability a lot.

Quote:
That and I don't exactly want to take all that time and become an expert on every single one to get them to compile,


Which is why there's precompiled libraries and headers :-).

Quote:
but I guess it's just one of the frustrations you have to work through with C/C++, and the open source community.


C should run unmolested on just about any computer still, that was standardized way earlier than C++. It's so standardized I can compile code with multiple compilers, have it all link to each other and some compiled python code, and form a completed program. In the grand scheme of things, C++ and OSS are relatively new.

Quote:
And for future reference I hope that you take careful not with any project you have to make sure and DO NOT ASSUME anything if you use STLport say so. And if you use even one class from an external library FOR GOD'S SAKE LET PEOPLE KNOW YOU ARE. IT'S COMMON SENSE WHEN ATTEMPTING TO HAVE OTHER PEOPLE WORKING ON THE SAME PROJECT TO MAKE SURE THEY ARE USING THE SAME LIBRARIES AND THE STL ARE A LIBRARY SO FOR THE LAST TIME PLEASE DON'T MAKE THE ASSUMPTION THAT THEY HAVE IT.


Most OSS projects state their dependancies... and most projects that rely on the core C++ libraries either rely on the actual standardized version, or include workarounds for half a bazillion different STL variants. Considering they write code that compiles on all sorts of platforms, they're usually the type to assume damn little :-).

Share this post


Link to post
Share on other sites
Quote:
Original post by 5MinuteGaming
IT'S COMMON SENSE WHEN ATTEMPTING TO HAVE OTHER PEOPLE WORKING ON THE SAME PROJECT TO MAKE SURE THEY ARE USING THE SAME LIBRARIES AND THE STL ARE A LIBRARY SO FOR THE LAST TIME PLEASE DON'T MAKE THE ASSUMPTION THAT THEY HAVE IT.


Hmmm. Unless you are in very, very particular circumstances (which you would know you are in, so since you don't know it, know that you aren't and thus they do not apply to you), you will always have a STL implementation along with a standard C++ compiler. That's what the word standard in "Standard C++ Library" means. It also means that the library is supposed to behave the same way on all platforms, so the version of the library you're using does not, bugs aside, matter.

So yes, my code will make the assumption you "have the STL" and no, I won't bother to check you have the same as I do.

Do yourself a favour. Either take the time to install STLport, or just ditch VC6.


See that wasn't much of a stoning. A few pebbles at most. [smile]

Share this post


Link to post
Share on other sites
Quote:
Original post by 5MinuteGaming
...THE STL ARE A LIBRARY SO FOR THE LAST TIME PLEASE DON'T MAKE THE ASSUMPTION THAT THEY HAVE IT.
Totally, utterly, completely wrong.

There is no such thing as the "STL," technically speaking, for starters. The Standard C++ Library incorporates the Standard C Library, what was formerly known as the Standard Template Library and C++ I/O streams into a single entity which is part of the C++ Programming Language standard specification, and which is required to be present in any standard C++ environment. The term "STL" persists for convenience sake, mostly.

Secondly, there are numerous proposed enhancements and extensions to the STL, some which are so popular that people erroneously assume them to be part of the STL (std::hash_map, for instance). Such assumptions are inaccurate, but they do not alter the status or the value of the STL.

If you rely on Standard C++ Library (some like the notation "SC++L") entities alone, your code should compile unaltered on every platform and installation. Problems arise when dependencies are assumed to be resolved, which justifies your point about explicitly stating such dependencies (Boost, STLPort - which includes std::hash_map, for instance - etc).

I simply feel that your frustrations are aimed at the wrong party. The Standard Template Library has been a huge benefit to software development in C++, and I encourage you to learn and fully embrace it. Besides, it's not going anywhere.

Happy hacking.

Share this post


Link to post
Share on other sites

This topic is 4531 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Forum Statistics

    • Total Topics
      628706
    • Total Posts
      2984309
  • Similar Content

    • By Dafu
      FES Retro Game Framework is now available on the Unity Asset Store for your kind consideration!
      FES was born when I set out to start a retro pixel game project. I was looking around for an engine to try next. I tried a number of things, from GameMaker, to Fantasy Consoles, to MonoGame and Godot and then ended up back at Unity. Unity is just unbeatable in it's cross-platform support, and ease of deployment, but it sure as heck gets in the way of proper retro pixel games!
      So I poured over the Unity pipeline and found the lowest levels I could tie into and bring up a new retro game engine inside of Unity, but with a completely different source-code-only, classic game-loop retro blitting and bleeping API. Months of polishing and tweaking later I ended up with FES.
      Some FES features:
      Pixel perfect rendering RGB and Indexed color mode, with palette swapping support Primitive shape rendering, lines, rectangles, ellipses, pixels Multi-layered tilemaps with TMX file support Offscreen rendering Text rendering, with text alignment, overflow settings, and custom pixel font support Clipping Sound and Music APIs Simplified Input handling Wide pixel support (think Atari 2600) Post processing and transition effects, such as scanlines, screen wipes, screen shake, fade, pixelate and more Deploy to all Unity supported platforms I've put in lots of hours into a very detail documentation, you can flip through it here to get an better glimpse at the features and general overview: http://www.pixeltrollgames.com/fes/docs/index.html
      FES is carefully designed and well optimized (see live stress test demo below). Internally it uses batching, it chunks tilemaps, is careful about memory allocations, and tries to be smart about any heavy operations.
      Please have a quick look at the screenshots and live demos below and let me know what you think! I'd love to hear some opinions, feedback and questions!
      I hope I've tickled your retro feels!



      More images at: https://imgur.com/a/LFMAc
      Live demo feature reel: https://simmer.io/@Dafu/fes
      Live blitting stress test: https://simmer.io/@Dafu/fes-drawstress
      Unity Asset Store: https://www.assetstore.unity3d.com/#!/content/102064

      View full story
    • By Dafu
      FES Retro Game Framework is now available on the Unity Asset Store for your kind consideration!
      FES was born when I set out to start a retro pixel game project. I was looking around for an engine to try next. I tried a number of things, from GameMaker, to Fantasy Consoles, to MonoGame and Godot and then ended up back at Unity. Unity is just unbeatable in it's cross-platform support, and ease of deployment, but it sure as heck gets in the way of proper retro pixel games!
      So I poured over the Unity pipeline and found the lowest levels I could tie into and bring up a new retro game engine inside of Unity, but with a completely different source-code-only, classic game-loop retro blitting and bleeping API. Months of polishing and tweaking later I ended up with FES.
      Some FES features:
      Pixel perfect rendering RGB and Indexed color mode, with palette swapping support Primitive shape rendering, lines, rectangles, ellipses, pixels Multi-layered tilemaps with TMX file support Offscreen rendering Text rendering, with text alignment, overflow settings, and custom pixel font support Clipping Sound and Music APIs Simplified Input handling Wide pixel support (think Atari 2600) Post processing and transition effects, such as scanlines, screen wipes, screen shake, fade, pixelate and more Deploy to all Unity supported platforms I've put in lots of hours into a very detail documentation, you can flip through it here to get an better glimpse at the features and general overview: http://www.pixeltrollgames.com/fes/docs/index.html
      FES is carefully designed and well optimized (see live stress test demo below). Internally it uses batching, it chunks tilemaps, is careful about memory allocations, and tries to be smart about any heavy operations.
      Please have a quick look at the screenshots and live demos below and let me know what you think! I'd love to hear some opinions, feedback and questions!
      I hope I've tickled your retro feels!



      More images at: https://imgur.com/a/LFMAc
      Live demo feature reel: https://simmer.io/@Dafu/fes
      Live blitting stress test: https://simmer.io/@Dafu/fes-drawstress
      Unity Asset Store: https://www.assetstore.unity3d.com/#!/content/102064
    • By Dafu
      Hello all,
      I've been hard at work on a new retro pixel-perfect framework called FES Retro Game Framework. It is now available on the Unity Asset Store for your kind consideration!
      FES was born when I set out to start a retro pixel game project. I was looking around for an engine to try next. I tried a number of things, from GameMaker, to Fantasy Consoles, to MonoGame and Godot and then ended up back at Unity. Unity is just unbeatable in it's cross-platform support, and ease of deployment, but it sure as heck gets in the way of proper retro pixel games!
      So I poured over the Unity pipeline and found the lowest levels I could tie into and bring up a new retro game engine inside of Unity, but with a completely different source-code-only, classic game-loop retro blitting and bleeping API. Months of polishing and tweaking later I ended up with FES.
      Some FES features:
      Pixel perfect rendering RGB and Indexed color mode, with palette swapping support Primitive shape rendering, lines, rectangles, ellipses, pixels Multi-layered tilemaps with TMX file support Offscreen rendering Text rendering, with text alignment, overflow settings, and custom pixel font support Clipping Sound and Music APIs Simplified Input handling Wide pixel support (think Atari 2600) Post processing and transition effects, such as scanlines, screen wipes, screen shake, fade, pixelate and more Deploy to all Unity supported platforms I've put in lots of hours into a very detail documentation, you can flip through it here to get an better glimpse at the features and general overview: http://www.pixeltrollgames.com/fes/docs/index.html
      FES is carefully designed and well optimized (see live stress test demo below). Internally it uses batching, it chunks tilemaps, is careful about memory allocations, and tries to be smart about any heavy operations.
      Please have a quick look at the screenshots and live demos below and let me know what you think! I'd love to hear some opinions, feedback and questions!
      I hope I've tickled your retro feels!



      More images at: https://imgur.com/a/LFMAc
      Live demo feature reel: https://simmer.io/@Dafu/fes
      Live blitting stress test: https://simmer.io/@Dafu/fes-drawstress
      My own game I started working on using FES, a roguelike, very early: https://simmer.io/@Dafu/merl
      Unity Asset Store: https://www.assetstore.unity3d.com/#!/content/102064
       
       
    • By Apollo Cabrera
      Yasss!!! My first Unity3d game is on the App Store and Google Play.
      Download please! About 30 minutes to get through 5 missions.
      Let me know what you guys think.
      Thanks a bunch
       
    • By Mert Oguz
      well, i have started developing games last year, alone , I made a singleplayer 3d openworld rpg on unity you can look at it on googleplaystore ( kooru stone rpg ) whatever, this year, i wanted to make mmo, which gone really fine until I first try real hosting, I was working on "wamp" until then. The reason i am desperate now is that the way my game works.
      On my pc, using wamp mysql , with localhost as host for my game, i was testing my mmorpg with using andorid emulators, ofcourse no lag no issues no restrictions, beautiful dream... But then, I wanted to get real host from web, so, I rent a basic, cheaphest ever web host ( 10$ year ), and transferred my php files along with sql database. 
      So, I launched the game, still no issues, tried to handle 2-3 players by using my pc, phone, friend's phone...  
      After a while, ( after really short time (3-4mins)) host started not to respond, beacause those web hosting were not fit to handle mmos, i predicted that.
      now what i am explaining is that my game works like this and asking what way should i use to handle it :
      - Creates web request ( like : webhost.com/game/getplayerdata.php?ID=2 )
      -Reads request ( request result be like = "ID2-GoodGuyXx-23-123-4-123-43 )
      -Builds player using result string
      -does similar requests REEAALY FREQUENTLY  ( total requests of 8 - 12 times per seconds )
      With my current ultimate cheap web hosting, i can handle 2 players with low lag ( lol ) but, i want to handle around 20-100 players,
      just need a clear path, i have been struggling with google cloud sql and other vps server dedicated server options, i dont wanna pay much and get ripped off.
  • Popular Now