[Skydiver]

Mods: I wasn't quite sure whether to post this here in the Caffeine Lounge, Advanced C++, or Software Development forums. Please move as necessary.

I'm a newbie here on DIC and I've made an interesting observation. I'll put on the flamesuit, but still, please be gentle. It's my first time.

The use of "non-standard headers and libs" seems to be highly discouraged here in DIC. On the top of the list of seems to be the various headers and libs that come with Turbo C++. Next to the top of the list seems to be the use of any Windows/DOS specific headers like MSVC's "conio.h".

So my questions are:

What is the exact definition of a non-standard header or library?
Before there was gcc and MSVC wasn't even scaring Borland, Turbo C++ was king. It is because times have moved on and Turbo C++ is now passe that makes the Turbo C++ headers and libs "non-standard"?

From what I can glean from the posts about not using "non-standard headers and libraries" is that part of the definition seems to involve whether something is in the C++11 Standard or not and whether it is implemented correctly by the compiler and/or library.

VS2010's C++ parser and library is falling behind from the current C++11 standards, and doesn't implement all of C++TR1, much less C++03. Does that make the use of VS2010 headers and C-runtime also "non-standard"?

What I find slightly amusing is that after saying that "conio.h" "graphics.h" is not part of the language standard, very shortly the post will say something about about use "ncurses.h" or "windows.h" instead. Why is it okay to use these headers that are not part of the language, but not the older "conio.h" and "graphics.h" which are also not part of the language? Is the sticking point that the old "conio.h" and "graphics.h" had functions not prefixed with an underscore? But then the ncurses and Windows APIs also don't have leading underscores in their functions, so it must be some other criteria.

If I used "termbox" instead of ncurses will I get the same kind of don't use "non-standard" library warnings here in DIC?

If I use the old DirectX 9 Managed DirectX library, is it considered non-standard and that people will say I should use XNA instead? If I choose to use SlimDX, is that non-standard?

Is there a DIC definition of what is a standard library? Or is it like porn? You'll know when you see it? Consider that one man's porn, is another civilization's temple decorations.

Is it bad to use platform specific code, libraries, APIs in code posted to DIC?
I posted some code that used the MSVCRT specific _getch(). I got comments about use of "non-standard" functions that only work on Windows/DOS despite the fact that the code I was commenting on was obviously Windows specific and using the MS Visual C++ Runtime Library. What makes _getch(); any different from system("pause");? The latter hardly seems to draw any comment despite it only working on Windows/DOS. Or have people just gotten used to seeing system("pause"); that it's a common idiom?

Or does it depend on the context? If somebody is asking a platform specific question, then it's okay to use platform specific stuff, but if the question is a generic language or algorithm question, then only "standard" stuff should be used?

How to deal with C# questions where somethings may be in one version of the Framework, but not another? Should LINQ be used?

What frameworks and libraries are considered standard and what is not?
Of these libraries what is considered standard:
jQuery
Boost
ATL
MFC
WTL
NUnit
xUnit
JUnit
ziplib
DotNetZip
DooPHP
Django
SharpUsbLib
Berkeley DB
Sqlite
Hibernate
NHibernate
db4o
Entity Framework
Log4Net
Unity
autofac
Spring.NET
Castle Windsor
XNA

This post has been edited by Skydiver: 06 July 2012 - 12:33 PM

[macosxnerd101]

I'm going to move this to C++ Advanced Discussion for better visibility. Chances are, you won't get the serious discussion you want in the lounge.

[Skydiver]

Thanks for moving the thread!

This post has been edited by Skydiver: 06 July 2012 - 12:29 PM

[ishkabible]

Interesting question.

unless the issue is library/system/compiler specific we want to appeal to the widest audience as other people look at the code in these forums and want to be able to run that code. that means sticking to the standard as much as possible and avoiding compiler specific code.

when I Google "how to read a line in from the console" I want to see a thread that explains how to do what I want regardless of the system/compiler I'm using. if however I Google "how to access webcam on windows" I want code that will work on any decent compiler I have on windows. when I google "how to display a rectangle with GLUT" I want to see code that will work on any platform GLUT will work on.

if you're just using windows then use windows.h and the question should be "how do I do this on windows"; then the answer should work on MSVC++, MinGW, Cygwin, and other compilers. if however what your asking can be done within the standard then stick to the standard.

compiler specific code is probably the worst unless the question is explicitly about how to use a compiler feature. system specific is probably next but, again, if the question is explicitly about a certain system then it's ok. often we get library specific questions, those are ok.

also, this spills over in the good practice. if something can be done in a cross platform way, then it should be done in a cross platform way. that's arguably an even bigger concern than reaching bigger audiences.

if something can be done inside the standard, then it should be done in the standard. what can't be done in the standard should be as widely applicable as possible.

This post has been edited by ishkabible: 06 July 2012 - 01:09 PM

[vividexstance]

If you don't know what the "standard" libraries are then have a look at this page: http://cplusplus.com/reference/ or http://en.cppreference.com/w/. The second link covers more of C++11 than the other. Those libraries are guaranteed to be apart of a standards-conforming compiler. Some of the headers are standard C and the rest are standard C++. Any header/library that isn't listed, is not a part of either standard.

This is just my opinion, but if you don't know what the standard libraries are, how do you expect to help people on here with their questions?

[ishkabible]

N3225, a very close draft of the C++11 standard, is freely available. It's what I primarily use to answer the slightly trickier questions relating to the standard we get on the forms.

[jimblumberg]

Quote

The use of "non-standard headers and libs" seems to be highly discouraged here in DIC.

Yes that is very true, in most cases. In my view the reason is because most of the posts on this board seem to be beginning C/C++ topics, and I believe that these posters should concentrate on using mainly the functions described in the C/C++ standards.

Quote

What is the exact definition of a non-standard header or library?

In my opinion any header not defined in the C or C++ standards.

Quote

Before there was gcc and MSVC wasn't even scaring Borland, Turbo C++ was king. It is because times have moved on and Turbo C++ is now passe that makes the Turbo C++ headers and libs "non-standard"?

Actually Turbo C/C++ predates even MSVC, Turbo C/C++ was the first IDE available for DOS, but Microsoft C was still king. There are really only two headers that are the cause of problems. The first is conio.h, and the major problem with this header is that it is only available for Windows based compilers, plus the fact that not all functions provided by one compiler are available in another compiler even if both compilers provide this header. The problem with graphics.h is the fact that is only available for the
ancient Borland compilers, and no other. The use of this compiler is really what is being discouraged. This group of compilers are pre-standard compilers and have many inconsistencies compared to modern C or C++.

Quote

VS2010's C++ parser and library is falling behind from the current C++11 standards, and doesn't implement all of C++TR1, much less C++03. Does that make the use of VS2010 headers and C-runtime also "non-standard"?

As far as the C++ compiler I would say that it is adequate at present and is getting better. But their C compiler is another issue altogether. I would say that this compiler is also becoming obsolete and Microsoft has publicly stated that they have no plans of updating there compiler. So yes I myself discourage the use of the Microsoft C compiler. There is another problem with using some of the other modern C compilers on Windows the reliance on the Microsoft C runtime libraries, this runtime library also doesn't cleanly support parts of the current standard.

Quote

I posted some code that used the MSVCRT specific _getch(). I got comments about use of "non-standard" functions that only work on Windows/DOS despite the fact that the code I was commenting on was obviously Windows specific and using the MS Visual C++ Runtime Library.

Actually it wasn't the fact that you used _getch() it was the fact that you added another header just to keep the console window open, when they were already using the iostream header.

Quote

What makes _getch(); any different from system("pause");? The latter hardly seems to draw any comment despite it only working on Windows/DOS. Or have people just gotten used to seeing system("pause"); that it's a common idiom?

Actually, both are bad, some will say system() is worse than getch(). I do get tired of complaining about both, to me getch() is worse because I don't do Windows and if the program contains a system() call the program will still compile, getch() will cause a compile error.

Quote

What I find slightly amusing is that after saying that "conio.h" "graphics.h" is not part of the language standard, very shortly the post will say something about about use "ncurses.h" or "windows.h" instead.

I don't usually recommend ncurses.h or windows.h unless the OP is also using things like gotoxy(), which is only available with a Borland compiler. I would normally suggest using the Windows API functions and stop using that outdated compiler. As I said earlier graphics.h is only available for Borland compilers and since these compilers will only produce 16 bit programs, that won't work on the latest Windows operating systems without adding emulators to the mix, their use should be discouraged.


Jim

[Skydiver]

ishkabible, on 06 July 2012 - 01:03 PM, said:

also, this spills over in the good practice. if something can be done in a cross platform way, then it should be done in a cross platform way. that's arguably an even bigger concern than reaching bigger audiences.

So as an aside, so if people are posting Windows code, DIC culture seems to point to always prefer ANSI, which will present:

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE, PSTR pCmdLine, int nCmdShow)
{
    // Register the window class.
    const char CLASS_NAME[]  = "Sample Window Class";
    
    WNDCLASS wc = { };

    wc.lpfnWndProc   = WindowProc;
    wc.hInstance     = hInstance;
    wc.lpszClassName = CLASS_NAME;

    RegisterClass(&wc);

    // Create the window.

    HWND hwnd = CreateWindowEx(
        0,                              // Optional window styles.
        CLASS_NAME,                     // Window class
        "Learn to Program Windows",    // Window text
        WS_OVERLAPPEDWINDOW,            // Window style

        // Size and position
        CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT,

        NULL,       // Parent window    
        NULL,       // Menu
        hInstance,  // Instance handle
        NULL        // Additional application data
        );

but does not compile with the default setting of VS2010.

The modern standard is UNICODE:

int WINAPI wWinMain(HINSTANCE hInstance, HINSTANCE, PWSTR pCmdLine, int nCmdShow)
{
    // Register the window class.
    const wchar_t CLASS_NAME[]  = L"Sample Window Class";
    
    WNDCLASS wc = { };

    wc.lpfnWndProc   = WindowProc;
    wc.hInstance     = hInstance;
    wc.lpszClassName = CLASS_NAME;

    RegisterClass(&wc);

    // Create the window.

    HWND hwnd = CreateWindowEx(
        0,                              // Optional window styles.
        CLASS_NAME,                     // Window class
        L"Learn to Program Windows",    // Window text
        WS_OVERLAPPEDWINDOW,            // Window style

        // Size and position
        CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT,

        NULL,       // Parent window    
        NULL,       // Menu
        hInstance,  // Instance handle
        NULL        // Additional application data
        );

But to reach the widest audience, the code should be presented as:

int WINAPI _tWinMain(HINSTANCE hInstance, HINSTANCE, LPTSTR pCmdLine, int nCmdShow)
{
    HWND hwnd;
    WNDCLASS wc;

    // Register the window class.
    const TCHAR CLASS_NAME[]  = TEXT("Sample Window Class");
    
    ZeroMemory(&wc, sizeof(wc));

    wc.lpfnWndProc   = WindowProc;
    wc.hInstance     = hInstance;
    wc.lpszClassName = CLASS_NAME;

    RegisterClass(&wc);

    // Create the window.

    hwnd = CreateWindowEx(
        0,                              // Optional window styles.
        CLASS_NAME,                     // Window class
        TEXT("Learn to Program Windows"),    // Window text
        WS_OVERLAPPEDWINDOW,            // Window style

        // Size and position
        CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT,

        NULL,       // Parent window    
        NULL,       // Menu
        hInstance,  // Instance handle
        NULL        // Additional application data
        );

to work with ANSI vs UNICODE builds, and to deal with compilers that don't know how to handle WNDCLASS wc = { };, as well as work with old C compilers instead of current C/C++.

[JackOfAllTrades]

vividexstance, on 06 July 2012 - 04:19 PM, said:

If you don't know what the "standard" libraries are then have a look at this page: http://cplusplus.com/reference/ or http://en.cppreference.com/w/. The second link covers more of C++11 than the other. Those libraries are guaranteed to be apart of a standards-conforming compiler. Some of the headers are standard C and the rest are standard C++. Any header/library that isn't listed, is not a part of either standard.

This is just my opinion, but if you don't know what the standard libraries are, how do you expect to help people on here with their questions?

I think Skydiver just happens to take a wider view of "standard". Us pedants are far more narrow-minded.

[Skydiver]

vividexstance, on 06 July 2012 - 01:19 PM, said:

If you don't know what the "standard" libraries are then have a look at this page: http://cplusplus.com/reference/ or http://en.cppreference.com/w/. The second link covers more of C++11 than the other. Those libraries are guaranteed to be apart of a standards-conforming compiler. Some of the headers are standard C and the rest are standard C++. Any header/library that isn't listed, is not a part of either standard.

This is just my opinion, but if you don't know what the standard libraries are, how do you expect to help people on here with their questions?

That's a great resource. I've actually referred to that same set of pages a lot in the past.

I think that my confusion stems from the past threads I've seen where people are told not to use the non-standard headers, and then with a few sentences later, advice is given to use "ncurses.h" or "windows.h" instead. This has lead to me to believe that the latter two files are considered standard.

[jimblumberg]

Quote

So as an aside, so if people are posting Windows code, DIC culture seems to point to always prefer ANSI

To me this problem is twofold, one there is a lot more code snippets and tutorials that are using the lowest common denominator, the ASCII character set. So when the users come asking about code that is not using Unicode but their compiler is set to compile for Unicode, what do you do? Start rewriting the tutorial/code the OP has presented or change compiler settings? To me Unicode support is still a very grey area, support is very spotty. One compiler using one "standard" and others using a different "standard".

To point out what I think is another problem for most beginning users it that the default IDE compiler warning settings are set too low. I think beginner programmers should be taught to use as many warnings as possible and never ignore warnings.

Jim

[ishkabible]

Quote

I think that my confusion stems from the past threads I've seen where people are told not to use the non-standard headers, and then with a few sentences later, advice is given to use "ncurses.h" or "windows.h" instead. This has lead to me to believe that the latter two files are considered standard.

they're not considered standard. they're considered the mostly widely applicable headers for the 2 largest class of systems(well for what ncurses does at least); *nix and windows. becuase a 3rd party library would be less applicable(although potentially more cross platform), it's generally not recommended without qualification on the fact that it's a third party library.

there is a distinction to be made between 3rd party and systems libraries. 3rd party libraries need to be built and setup somehow(at the very least, put in the right folders) where standard and systems libraries are already there and the need to link an external library is low.

This post has been edited by ishkabible: 06 July 2012 - 02:10 PM

[Bench]

Skydiver, on 06 July 2012 - 08:25 PM, said:

The use of "non-standard headers and libs" seems to be highly discouraged here in DIC. On the top of the list of seems to be the various headers and libs that come with Turbo C++. Next to the top of the list seems to be the use of any Windows/DOS specific headers like MSVC's "conio.h".

Discouraged for those starting out learning C++, yes. Just in the same way as reading Shakespeare would be discouraged for someone starting out learning English. But just as a university-level English student will probably have to analyse the meaning behind Shakespeare's Sonnets, a software developer will eventually need to write platform-specific code. (Hopefully not using ancient libraries like conio.h though)

Skydiver, on 06 July 2012 - 08:25 PM, said:

What is the exact definition of a non-standard header or library?
Before there was gcc and MSVC wasn't even scaring Borland, Turbo C++ was king. It is because times have moved on and Turbo C++ is now passe that makes the Turbo C++ headers and libs "non-standard"?

From what I can glean from the posts about not using "non-standard headers and libraries" is that part of the definition seems to involve whether something is in the C++11 Standard or not and whether it is implemented correctly by the compiler and/or library.

Back when Turbo C++ had been released desktop PCs used a 16-bit OS, but technology has most definitely moved on; in fact, it's becoming increasingly difficult for people to even run Turbo C++ now that Windows 7 has dropped support for legacy MS-DOS software.

However, standard libraries are those defined as part of the C++ standard (either C++98, C++03 or C++11). For C++11, there's a document called ISO/IEC 14882:2011 which specifies the entire standard language, including the libraries;

While it may not be true for other languages, in C++ the standard libraries are very much an equal part of the core language since many of them act as replacements for built-in language features such as string, vector, shared_ptr, etc. This is in contrast to some libraries such as those in Java/.NET where a lot of library features aren't so universally applicable (such as graphics libraries), it's usually not a good idea to write C++ code while completely ignoring standard libraries in favour of arrays/pointers/etc.

Skydiver, on 06 July 2012 - 08:25 PM, said:

VS2010's C++ parser and library is falling behind from the current C++11 standards, and doesn't implement all of C++TR1, much less C++03. Does that make the use of VS2010 headers and C-runtime also "non-standard"?

There currently aren't any implementations which I'm aware of that are fully compliant with the entire C++11 language, Although there are some compilers out there which do support all of the new libraries, and I believe VC++2012 will include the full set. Those libraries are standard because they are defined in the ISO document, not because they are always universally available everywhere

Skydiver, on 06 July 2012 - 08:25 PM, said:

What I find slightly amusing is that after saying that "conio.h" "graphics.h" is not part of the language standard, very shortly the post will say something about about use "ncurses.h" or "windows.h" instead. Why is it okay to use these headers that are not part of the language, but not the older "conio.h" and "graphics.h" which are also not part of the language? Is the sticking point that the old "conio.h" and "graphics.h" had functions not prefixed with an underscore? But then the ncurses and Windows APIs also don't have leading underscores in their functions, so it must be some other criteria.

It's got absolutely nothing to do with "not being part of the standard" and a lot more to do with the fact that conio.h and graphics.h are usually an indication that some code has been written for a platform which is 20 years out of date (Specifically, Borland's Turbo C++ 3.0), so the usual advice for anybody learning is to always learn the latest-and-greatest by picking up a compiler which supports at least some of the C++11 standard such as GCC or Visual C++, or even Embarcadero's replacement for Borland's compilers.

Of course, those people who have the misfortune of being "stuck" on those old compilers will have no choice, but the vast majority of threads on DIC come from learners who are picking up C++ for the first time and have the choice of using a modern C++ implementation. It would be doing a bit of a disservice to not at least try guiding them away from obsolete technology.

There's also another issue related specifically to learning - and that is to learn the C++ standard language before branching out to 3rd-party/vendor-specific tools; the reason being that learners have much better support in the form of books and online resources for the C++ standard libraries than there are for any vendor-specific tools. More importantly, the C++ standard libraries are designed to gel together with the language, so in learning how to use them, someone getting to grips with the basics are far more likely to learn C++ paradigms (This is the same reason why its also best to ignore parts of the standard C language/libraries when learning C++)

On a related note - names with a leading underscore (e.g. _getch or _hello) are reserved by the standard for vendors to use, there's nothing else particularly interesting about them otherwise. It's not 'bad' to call a vendor function with a reserved name, just so long as you don't declare your own variables/functions/etc using a leading underscore

Skydiver, on 06 July 2012 - 08:25 PM, said:

Is it bad to use platform specific code, libraries, APIs in code posted to DIC?

No, of course its not, but it depends on whether the library/API is actually appropriate to a particular thread, and on whether the person asking the question is likely to be able to understand the kind of nomenclature used in API documentation.

3rd-party APIs and libraries are often unescapable for a real projet, but there's a time-and-place for platform-specific code on DIC (Which is a community where the majority of threads are started by novices) - unfortunately most of the time those libraries just aren't really very beginner-friendly (and their documentation even less so). I've seen more threads than I can count from learners who've just figured out how a 'for' loop works suddenly trying to build something with OpenGL, Win32 API, etc. when they haven't even used a std::vector or std::map before, and would almost certainly drown in the terminology used by library documentation.

There's also the matter of whether that library would ever actually be useful. For example, conio.h is not a particularly good library - better alternatives exist, and you hopefully would never use it in a real project (Similarly, I would hope noone ever uses 'system()' in a real project, even though it is part of the C standard library)

Skydiver, on 06 July 2012 - 08:25 PM, said:

I posted some code that used the MSVCRT specific _getch(). I got comments about use of "non-standard" functions that only work on Windows/DOS despite the fact that the code I was commenting on was obviously Windows specific and using the MS Visual C++ Runtime Library. What makes _getch(); any different from system("pause");? The latter hardly seems to draw any comment despite it only working on Windows/DOS. Or have people just gotten used to seeing system("pause"); that it's a common idiom?

I assume the question was something along the lines of "How do i stop the output window from being closed" - the kind of question which most people come stuck against in the first few months of learning.
For that particular case, neither of them are particularly good when the C++ standard library provides you with std::cin::get(). Again, it goes back to learning how to use the standard libraries first before learning platform-specific stuff.

[NickDMax]

I have in the past made many of the same points as the original post here. I see people getting hounded for using conio.h or system("pause") and honestly get a little aggravated because platform specific development and the use of "third party libraries" are really necessary to modern programming.

However, the use of Turbo C++ in the modern classroom is really inexcusable. Telling students that they are learning C++ when what they are actually learning is a 20 year old dialect is IMO dishonest and does the student a large disservice***

Lets face it ye'olde System("pause") (and all the stupid "platform independent/standard complaint" work-arounds) is actually caused by a poor design decision by IDE developers (granted they were targeting professionals not students). By closing the command prompt window immediately when the program exited without offering SOME kind of option to keep it open (short of knowing which mode to run a program in) was just dumb.

To be honest, people would not need to use system("cls")/system("pause")/system("color") etc. if conio.h were a little more accepted. While I know *why* conio.h or any another such libraries were never added to the C++ standard, I actually think it was a pseudo-mistake (that is that perhaps it was a slippery slope best left alone - but beginners have all paid a price for it).



*** you know if you really think about that statement above ("...learning a 20 year old dialect") it is kind of amusing as modern C++ is rarely actually discussed in classrooms or textbooks anyway.

[snoopy11]

hmm,

Skydiver said

Quote

I posted some code that used the MSVCRT specific _getch(). I got comments about use of "non-standard" functions that only work on Windows/DOS despite the fact that the code I was commenting on was obviously Windows specific and using the MS Visual C++ Runtime Library. What makes _getch(); any different from system("pause");? The latter hardly seems to draw any comment despite it only working on Windows/DOS. Or have people just gotten used to seeing system("pause"); that it's a common idiom?

Yes I have had this argument before as well, I don't see anything wrong with

_getch();

as Microsoft say _getch is ISO C++ conformant.

See here

Im not a fan of any system calls for a lot of reasons but mainly because my Kaspersky
Internet Security reports any use of a program using system as being potentially malicious.

And no one will want to use a program that their anti-virus software reports as being malicious.
People simply will not use it.

While I do feel a program should be cross-compiler compliant on the same platform.
So intentionally shy away from Microsoft specific headers as much as I can.

I find this DIC policy on code being cross platform compliant a little strange too and perhaps needs to be re-thought.

All the best.

Snoopy.

This post has been edited by snoopy11: 15 July 2012 - 10:48 PM