Why stray from cross platform when there is ANSI STL????

I am a beginner with opengl but understand it’s “ANSI C” syntax and cannot understand why no one uses ANSI STL syntax in there programming it seems to me as a novice in stl that this is really the only way to go while dealing with cross platform issues as it is already in there!
I have made some opengl programs using glut v3.6, stl and the .stl file extension and it worked very fast however my opengl program that read and displayed the vector information from a boat.stl file was removed or i can not find it at the “Code project”
however it worked great for importing .stl cad models into opengl for games.
I think the only way to go is using ANSI C, C++(the ability to create classes and not dictate rule), stl, unix. this way your programs work on any platform, also I had been able to get freeglut to run on netbeans IDE with one #define WIN_32_LEAN_AND_MEAN macros definition i think.

There’s no such thing as “ANSI STL” that I know of. At least, not in terms of any C or C++ concept. There are .stl files, but that’s a file format, which has nothing to do with language. And the C++ standard library is (erroneously) sometimes called the STL, but that has nothing to do with either OpenGL or .stl files. And while C++ is technically an ANSI standard, it is more accurately called “ISO C++” because it’s an ISO standard (which by treaty as I understand it, makes it an ANSI standard). At least, you can get ISO/IEC 14882 (ie: the C++ standard) from ANSI’s website at quite reasonable prices.

Your post seems very odd and confused. Could you clear up what you’re talking about?

One reason for not using STL stuff in API-headers is that STL-implementations may vary from system to system. Using only PODs ensures that the data passed to the API is actually in the format the binary interface expects. The same goes for C++ in General: One has to take some care to ensure C+±constructs work on other Systems/Compilers when distributing headers and precompiled binaries.

For a general market being portable is Not Very Important. Take games as an example: according to the latest Steam Hardware & Software Survey you can not give a sweet damn about portability and still hit ~95% of your target market. That’s in the desktop PC/Mac space, mobile is of course different, but since this is the desktop OpenGL forum (and not the GL ES forum) mobile doesn’t concern us.

So if in exchange for that ~5% you’re not going to hit you get better tools (please don’t try compare gdb to Microsoft’s debuggers), better focus, the ability to exploit platform-specific stuff to make a better end product, earlier release, a single code-base to maintain, a single platform to have to test on, that seems more than a fair tradeoff.

If you’re aiming for a specialized or enthusiast market then maybe being portable is important, but the moral of that story is to do your market research first. Know your target audience, know what they use, and don’t make compromises to meet some theoretical ideal that solves problems you don’t even have to begin with.

With MSVS STL, it’s worse than that. It can vary from compilation to compilation in the same compiler on the same system (_HAS_ITERATOR_DEBUGGING and SECURE_SCL, I’m referring to you). Varying STL container class type sizes just to make your life more fun. So on Windows, beware, even if you’re using the result on the same system. That said, on Linux I’ll freely use STL containers in interfaces. Just spec out your portability requirements and do what makes sense for your frameworks.

I’m thankful for the new warnings about mismatching iterator-debug levels, but the problem is nasty:

template<class X> struct size_printer { void print_size() const { printf("%d
", sizeof(X)); } };

#include "template_clash.h"
struct local_struct { int x; };
void print1() { size_printer<local_struct> p; p.print_size(); }

#include "template_clash.h"
struct local_struct { int x; int y; };
void print2() { size_printer<local_struct> p; p.print_size(); }

extern void print1();
extern void print2();


Makes the life of local structs dangerous. Is nothing special when compared to local C-functions, but somehow unexpected with c++.
I can just advise to declare structs local to one source-file in a dedicated Namespace - I could not imagine a way to uniquely identify a classes identity.

You could just use anonymous namespaces for “file static” class definitions.

A big Thanks!
I was not aware of anonymous namespaces. Saves typing and is likely far more secure that imagining a name for oneself.

Reading you twice: I was reaching far out - the Problem scatches above could be prevented by decorating the classes linker-name with it’s size but would surely not catch all that Situation and could break some existing code.