Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 9 of 9

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

  1. #1
    Newbie Newbie
    Join Date
    Jul 2013
    Posts
    2

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

    Hello:
    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.

  2. #2
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    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?

  3. #3
    Junior Member Regular Contributor
    Join Date
    Nov 2012
    Location
    Bremen, Germany
    Posts
    149
    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.

  4. #4
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,136
    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.

  5. #5
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    3,124
    Quote Originally Posted by hliwin
    One reason for not using STL stuff in API-headers is that STL-implementations may vary from system to system.
    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.
    Last edited by Dark Photon; 07-25-2013 at 05:36 PM.

  6. #6
    Junior Member Regular Contributor
    Join Date
    Nov 2012
    Location
    Bremen, Germany
    Posts
    149
    I'm thankful for the new warnings about mismatching iterator-debug levels, but the problem is nasty:
    Code :
    template_clash.h:
    template<class X> struct size_printer { void print_size() const { printf("%d\n", sizeof(X)); } };
     
    template_clash1.cpp:
    #include "template_clash.h"
    struct local_struct { int x; };
    void print1() { size_printer<local_struct> p; p.print_size(); }
     
    template_clash2.cpp:
    #include "template_clash.h"
    struct local_struct { int x; int y; };
    void print2() { size_printer<local_struct> p; p.print_size(); }
     
    template_clasher.cpp:
    extern void print1();
    extern void print2();
     
    print1();
    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.
    Last edited by hlewin; 07-26-2013 at 04:27 PM.

  7. #7
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    You could just use anonymous namespaces for "file static" class definitions.

  8. #8
    Junior Member Regular Contributor
    Join Date
    Nov 2012
    Location
    Bremen, Germany
    Posts
    149
    A big Thanks!
    I was not aware of anonymous namespaces. Saves typing and is likely far more secure that imagining a name for oneself.

  9. #9
    Junior Member Regular Contributor
    Join Date
    Nov 2012
    Location
    Bremen, Germany
    Posts
    149
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •