I just recently changed my IDE to MS Visual Studio 2005 coming from MSVC++ 6, and I've gotten a lot of deprecation warnings. Rather than ignore the warning, I started to change them to the _s equivalents. However, I then found out that these were microsoft-only implementations.
I read somewhere that they were pushing for these to become part of the standard. Is it?
Is it a good idea to use these _s functions? Or should I use something else?
Thanks.
The *_s() functions are not part of the C standard, but there is a pending 'Technical Report' proposing that they be added (I'm not sure if the routines in the TR are exactly the same as Microsoft's or if they're just similar).
TR 24731-1: Extensions to the C Library Part I: Bounds-checking interfaces:
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1225.pdf
If you want to continue to use the old functions you can keep the deprecation warnings quiet by defining the macro _CRT_SECURE_NO_WARNINGS (was _CRT_SECURE_NO_DEPRECATE which might still be supported).
You upgraded your IDE and also upgraded your Microsoft libraries. Frankly you can continue to use your old libraries as they continue to be kept (for backwards compatibility) although Microsoft has said that they are going to actually start taking out some of these older functions. I would say that if you're developing forward then you can use the newer functions; if you're developing backwards (or not worrying what the version is) then you might want to use the older functions.
If you're targeting the Microsoft platform, by all means use them. Even if you're not, you can always implement them yourself when (or if) you need to port your software to a non-Microsoft platform.
Worst case is that you end up using a few #ifdefs to conditionally compile.
They're being considered for standardization, as far as I'm able to tell. The proposal is TR 24731.
As for whether it's a good idea to use them, I'd say yes. I don't much like the way they catch errors but I believe you can provide them with your own handler. If you need cross-platform compatibility you have two choices: implement them with macros on the non-Windows platforms or turn off the deprecation warnings.
After doing a review through a large codebase I determined that it's nearly impossible to get all programmers to use the C standard library functions for string manipulation correctly, so everything that aims to correct that is a welcome addition.
You should use the standard functions and disable whatever sadistic warnings Microsoft has turned on by default to discourage you from writing standards-conformant code. I seriously doubt the "_s functions" will ever be added to standard C (though they have been proposed) since they are an invention of a single vendor and have never been implemented by any other vendor. (Hey let's incorporate all of POSIX into the C standard while we're at it...)
Related
I am on Windows, and suppose I want to use different implementation of standard C++ library for my projects - say, libstdc++ or libc++.
Is there a way to persuade my Visual Studio to use it instead of MSVC library, so I can still use #include <algorithm> and not #include <custom/algorithm>? I believe that I can achieve it by simply adding path to my headers into project, but I am looking for more "system-wise" way, so I wouldn't repeat it for every single project.
Will it actually worth the hassle - specifically in terms of modern C++ features being available / standart-compliant?
If so, what would be cons of such replacement, apart of possibility to use some features that are not present in other implementations?
Particulary, answers to this question mention that there may be compatibility issues with other libs - does this apply only to Linux world, or will I have problems on Windows too?
Note: this is mostly a theoretical question - I'm fine with MSVC library, but I'd really like to know more about different stdlib implementations.
Theoretically it's not impossible to swap out stdlib implementations. With clang, you can choose between libc++ (clang's) and libstdc++ (GCC's).
However, in practice, stdlib implementations are often tied fairly fundamentally to the internals of the compiler they ship with, especially when it comes to newer-added C++ features, and this is not truer for many compilers than Visual Studio.
Could you make it work with a lot of hacking around? Maybe. Would it be worthwhile? I very much doubt it. Even if you succeeded, you will have sacrificed a reproducible build environment and will be relying on some deeply dark arts. Your project will not be reusable.
There is no indication in your question as you why you think you need to switch implementations, but it seems unlikely that any reason you could come up with would be worth the trouble.
I work on large scale, multi platform, real time networked applications. The projects I work on lack any real use of containers or the Standard Library in general, no smart pointers or really any "modern" C++ language features. Lots of raw dynamically allocated arrays are common place.
I would very much like to start using the Standard Library and some of the C++11 spec, however, there are many people also working on my projects that are against because "STL / C++11 isn't as portable, we take a risk using it". We do run software on a wide variety of embedded systems as well as fully fledged Ubuntu/Windows/Mac OS systems.
So, to my question; what are the actual issues of portability with concern to the Standard Library and C++11? Is it just a case of having g++ past a certain version? Are there some platforms that have no support? Are compiled libraries required and if so, are they difficult to obtain/compile? Has anyone had serious issues being burnt by non-portable pure C++?
Library support for the new C++11 Standard is pretty complete for either Visual C++ 2012, gcc >= 4.7 and Clang >= 3.1, apart from some concurrency stuff. Compiler support for all the individual language features is another matter. See this link for an up to date overview of supported C++11 features.
For an in-depth analysis of C++ in an embedded/real-time environment, Scott Meyers's presentation materials are really great. It discusses costs of virtual functions, exception handling and templates, and much more. In particular, you might want to look at his analysis of C++ features such as heap allocations, runtime type information and exceptions, which have indeterminate worst-case timing guarantees, which matter for real-time systems.
It's those kind of issues and not portability that should be your major concern (if you care about your granny's pacemaker...)
Any compiler for C++ should support some version of the standard library. The standard library is part of C++. Not supporting it means the compiler is not a C++ compiler. I would be very surprised if any of the compilers you're using at the moment don't portably support the C++03 standard library, so there's no excuse there. Of course, the compiler will have to be have been updated since 2003, but unless you're compiling for some archaic system that is only supported by an archaic compiler, you'll have no problems.
As for C++11, support is pretty good at the moment. Both GCC and MSVC have a large portion of the C++11 standard library supported already. Again, if you're using the latest versions of these compilers and they support the systems you want to compile for, then there's no reason you can't use the subset of the C++11 standard library that they support - which is almost all of it.
C++ without the standard library just isn't C++. The language and library features go hand in hand.
There are lists of supported C++11 library features for GCC's libstdc++ and MSVC 2012. I can't find anything similar for LLVM's libc++, but they do have a clang c++11 support page.
The people you are talking to are confusing several different
issues. C++11 isn't really portable today. I don't think any
compiler supports it 100% (although I could be wrong); you can
get away with using large parts of it if (and only if) you limit
yourself to the most recent compilers on two or three platforms
(Windows and Linux, and probably Apple). While these are the
most visible platforms, they represent but a small part of all
machines. (If you're working on large scale networked
applications, Solaris will probably be important, and Sun CC.
Unless Sun have greatly changed since I last worked on it, that
means that there are even parts of C++03 that you can't count
on.)
The STL is a completely different issue. It depends partially
on what you mean by the STL, but there is certainly no
portability problem today in using std::vector. locale
might be problematic on a very few compilers (it was with Sun
CC—with both the Rogue Wave and the Stlport libraries),
and some of the algorithms, but for the most part, you can
pretty much count on all of C++03.
And in the end, what are the alternatives? If you don't have
std::vector, you end up implementing something pretty much
like it. If you're really worried about the presence of
std::vector, wrap it in your own class—if ever it's not
available (highly unlikely, unless you go back with a time
machine), just reimplement it, exactly like we did in the
pre-standard days.
Use STLPort with your existing compiler, if it supports it. This is no more than a library of code, and you use other libraries without problem, right?
Every permitted implementation-defined behaviour is listed in publicly available standard draft. There is next to nothing less portable in C+11 than in C++98.
In C++, if I write a simple game like pong using Linux, can that same code be compiled on Windows and OSX? Where can I tell it won't be able to be compiled?
You have three major portability hurdles.
The first, and simplest, is writing C++ code that all the target compilers understand. Note: this is different from writing to the C++ standard. The problem with "writing to the standard" starts with: which standard? You have C++98, C++03, C++TR1 or C++11 or C++14 or C++17? These are all revisions to C++ and the newer one you use the less compliant compilers are likely to be. C++ is very large, and realistically the best you can hope for is C++98 with some C++03 features.
Compilers all add their own extensions, and it's all too easy to unknowingly use them. You would be wise to write to the standard and not to the compiler documentation. Some compilers have a "strict" mode where they will turn off all extensions. You would be wise to do primary development in the compiler which has the most strictures and the best standard compliance. gcc has the -Wstrict family of flags to turn on strict warnings. -ansi will remove extensions which conflict with the standard. -std=c++98 will tell the compiler to work against the C++98 standard and remove GNU C++ extensions.
With that in mind, to remain sane you must restrict yourself to a handful of compilers and only their recent versions. Even writing a relatively simple C library for multiple compilers is difficult. Fortunately, both Linux and OS X use gcc. Windows has Visual C++, but different versions are more like a squabbling family than a single compiler when it comes to compatibility (with the standard or each other), so you'll have to pick a version or two to support. Alternatively, you can use one of the gcc derived compiler environments such as MinGW. Check the [list of C++ compilers](less compliant compilers are likely to be) for compatibility information, but keep in mind this is only for the latest version.
Next is your graphics and sound library. It has to not just be cross platform, it has to look good and be fast on all platforms. These days there's a lot of possibilities, Simple DirectMedia Layer is one. You'll have to choose at what level you want to code. Do you want detailed control? Or do you want an engine to take care of things? There's an existing answer for this so I won't go into details. Be sure to choose one that is dedicated to being cross platform, not just happens to work. Compatibility bugs in your graphics library can sink your project fast.
Finally, there's the simple incompatibilities which exist between the operating systems. POSIX compliance has come a long way, and you're lucky that both Linux and OS X are Unix under the hood, but Windows will always be the odd man out. Things which are likely to bite you mostly have to do with the filesystem. Here's a handful:
Filesystem layout
File path syntax (ie. C:\foo\bar vs /foo/bar)
Mandatory Windows file locking
Differing file permissions systems
Differing models of interprocess communication (ie. fork, shared memory, etc...)
Differing threading models (your graphics library should smooth this out)
There you have it. What a mess, huh? Cross-platform programming is as much a state of mind and statement of purpose as it is a technique. It requires some dedication and extra time. There are some things you can do to make the process less grueling...
Turn on all strictures and warnings and fix them
Turn off all language extensions
Periodically compile and test in Windows, not just at the end
Get programmer who likes Windows on the project
Restrict yourself to as few compilers as you can
Choose a well maintained, well supported graphics library
Isolate platform specific code (for example, in a subclass)
Treat Windows as a first class citizen
The most important thing is to do this all from the start. Portability is not something you bolt on at the end. Not just your code, but your whole design can become unportable if you're not vigilant.
C++ is ultra portable and has compilers available on more platforms than you can shake a stick at. Languages like Java are typically touted as being massively cross platform, ironically they are in fact usually implemented in C++, or C.
That covers "portability". If you actually mean, how cross platform is C++, then not so much: The C++ standard only defines an IO library suitable for console IO - i.e. text based, so as soon as you want develop some kind of GUI, you are going to need to use a GUI framework - and GUI frameworks are historically very platform specific. Windows has multiple "native" GUI frameworks now - the C++ framework made available from Microsoft is still MFC - which wraps the native Win32 API which is a C API. (WPF and WinForms are available to CLR C++).
The Apple Mac's GUI framework is called Cocoa, and is an objective-C library, but its easy to access Objective C from C++ in that development environment.
On Linux there is the GTK+ and Qt frameworks that are both actually ported to Windows and Apple, so one of these C++ frameworks can solve your "how to write a GUI application in C++ once that builds and runs on windows, apple mac and linux".
Of course, its difficult to regard Qt as strictly C++ anymore - Qt defines a special markup for signals and slots that requires a pre-compile compile step.
You can read the standard - if a program respects the standard, it should be compilable on all platforms that have a C++ standard-compliant compiler.
As for 3rd party libraries you might be using, the platform availability is usually specified in the documentation.
When GUI comes to question, there are cross-platform options (such as QT), but you should probably ask yourself - do I really want portability when it comes to UI? Sometimes, it's better to have the GUI part platform-specific.
If you are thinking of porting from Linux to Windows, using OPENGL for the graphical part gives you freedom to run your program on both operating systems as long as you don't use any system specific functionality.
Compared to C, C++ portability is extremely limited, if not completely unexisting. For one you can't disable exceptions (well you can), for the standard specifically says that's undefined behaviour. Many devices don't even support exceptions. So as for that, C++ is ZERO portable. Plus seeing the UB, it's obvioulsy a no-go for zero-fail high-performance real time systems in which exceptions are taboo - undefined behaviour has no place in zero-fail environment. Then there's the name mangling which most, if not every, compiler does completely different. For good portability and inter-compatibility extern "C" would have to be used to export symbols, yet this renders any and all namespace information completely void, resulting in duplicate symbols. One can ofcourse choose to not use namespaces and use unique symbol names. Yet another C++ feature rendered void. Then there's the complexity of the language, which results in implementation difficulties in the various compilers for various architectures. Due to these difficulties, true portability becomes a problem. One can solve this by having a large chain of compiler directives/#ifdefs/macros. Templates? Not even supported by most compilers.
What portability? You mean the semi-portability between a couple of main-stream build targets like MSVC for Windows and GCC for Linux? Even there, in that MAIN-STREAM segment, all the above problems and limitations exist. It's retarded to even think C++ is portable.
How to make sure that my program will be fully portable?
Continuous integration on all target platforms.
1. Test
This is a necessary but not a sufficient condition for doing anything properly. To test portability, you'll want multiple platforms and compilers.
2. Write to the standard, not to your development platform.
This means, only do something if the standard says you can do it. Only expect a particular result if the standard says you can expect it. Only use a library or API if the standard says it exists. The standard is available here (among other places):
http://openassist.googlecode.com/files/C%2B%2B%20Standard%20-%20ANSI%20ISO%20IEC%2014882%202003.pdf
It helps if you assume that:
CHAR_BIT is equal to 9.
sizeof(int) is equal to 5 and int is a 37 bit type. Or a 16 bit type.
the basic character set is EBCDIC.
The epoc began in 1721.
time_t is double
And so on. By which I don't mean, write code that relies on those things to be true, I mean write code that will work if they are, and will also work on a sane implementation.
3. Use the most restrictive and pedantic compiler options you can find,
This is the only practical way to give yourself a reasonable chance of achieving (1).
4. Understand that "real compilers" fail to implement the standard correctly or fully, and make some concessions to this fact.
Theoretically, there's nothing non-portable about a C++ program that uses export. If it's a perfectly good C++ program in every other respect, then it will work on any conforming C++ compiler. But hardly anyone uses a conforming C++ compiler, so there's a de facto common subset of C++ that you'll want to stick to.
5. Understand that the C++ standard provides quite a restricted programming environment
Certain things are not portable in standard C++, such as drawing graphics on a screen, since standard C++ has no graphics or GUI API. So there is no such thing as a "fully portable" GUI program written in C++. So you may or may not need to revise your goal, depending what your program is supposed to do.
If your program requires something that simply cannot be done entirely within standard C++, then you can make your program easier to port by encapsulating that behaviour within an interface which you think should be implementable on all platforms you care about. Then set about implementing it for each one. This doesn't result in a "fully portable" program, though, since to me that means a program which you can compile and run unchanged on any conforming C++ implementation. A program which can be ported to most platforms with a C++ compiler, probably, assuming they have a screen and a mouse, with some bespoke programming work, isn't the same thing.
All this can be taken too far, of course. You will probably actually want to assume that CHAR_BIT is 8 (reading files is madness otherwise), and perhaps even rely on a GUI framework like Qt. But you did say, "fully portable", and one of the main things you need to do to write portable programs is usually to work out how far you're willing to compromise on "fully".
6. Assert what you assume
At compile-time if you can, or runtime otherwise, ensure that if your program requires int to be at least 32 bits (or whatever), then it will fail noisily when it isn't. OK, so comprehensive test coverage would catch cases where your arithmetic silently overflows and gives the wrong answer, but it's hard to write truly comprehensive tests, and anyway the tests might make the same non-portable errors as the code, or some poor sucker who has downloaded your code might not run them all properly.
When you use libraries, you are effectively doing this automatically. You'll #include some header, and if the library isn't available that will fail immediately. At least, you hope it will - it's conceivable that some other implementation could have a header of the same name which does something radically or subtly different. Radical differences usually result in compilation failures, for subtle differences you can test for preprocessor symbols to identify implementations.
Your question:
How to make sure that my program will be fully portable?
cannot be answered satisfyingly. You cannot, in any real-world application, make sure it's portable. You can only prove your expectation by accurate tests of the application on the target platform, as has been already proposed here by Lou Franco.
In the process of developing and testing in parallel on different platforms or environments, every one of us finds his bag of tricks and explores his share of pitfalls. You said in one comment you work on a Windows system. This is fine. Try to get your program working with the Visual Studio compiler (and environment). Then, install CygWin with the GCC 4.x compiler suite. Install the Netbeans IDE & C++ Environment and create a project based on the same sources. Netbeans will use the Cygwin GCC 4.x. If your compiled program works with both toolchains, you mastered probably about 90% of the real-world portability hurdles.
Regards
rbo
Avoid platform-specific libraries.
Make it standards compliant. At least a common subset of the standard that is implemented by vendors on all platforms you intend to deploy your application on.
Factor out platform specific portions from platform-independent ones. Typically, the lowest layer or two should deal with the platform.
Keep abreast with changes of:
Platform/OS APIs
Tool chains
Language features
Test, Deploy. Rinse and repeat.
Unit test it, on each platform, during development
Avoid using platform specific libraries. If you can implement desired functionality using the STL and BOOST only, go ahead.
Develop on the most restrictive compilation environment. Use the smallest set of features from C++. Split the platform-dependent portions of code into separate files. Develop a configuration (make) environment for each platform, as part of the software package.
Making sure to only use libraries that actually exist on all target platforms would be a good start.
It is impossible. What happens when I write my operating system that has a weird C compiler?
That said, to be portable, you need to:
Avoid Win32
Avoid POSIX (which is annoying... You may want to just use Cygwin to provide Windows support)
Avoid any platform specific library. This usually limits you in graphics to wxWindows, GTK, and QT.
TEST. Make sure it works.
Don't assume anything. Windows is weird and uses \r\n, so be careful about that.
I think Visual C++ on windows gives you warnings about "unsafe c functions" and asks you to use the "safe ones", which are not standard. Don't fall for Microsoft's attempt to monopolize your program.
Some things will help:
Autoconf will allow any decent system (ie one that includes a shell) to detect common portability issues and set up the correct headers
Cmake can do this as well, but only on platforms that Cmake itself is available on
Know the platforms that you intend to ship for. If some platform convention contradicts the standard, ignore the standard. I'm serious about that. For example, if you use the standard std::ifstream constructor, which takes a char* argument, you won't be able to open any files with Unicode filenames on Windows—you must use the nonstandard wchar_t* overload there. The functionality lost by not being able to open files that are allowed and legal on the platform severely outweighs the portability gained by using only what the standard knows; in the end, it's the functionality that matters, not the adherence to a particular standard.
This is less a direct answer to the question, than an answer in the light of other answers.
You need to balance a requirement for absolute portability against the expectations of platform users - there are different basic HCI/HIG guidelines for Windows, OS X, KDE and Gnome, and none of the portable GUI toolkits will automatically produce the right results in each (some allow you to apply different layouts, which is a start).
The inbetween approach is to have a pure portable core with multiple native GUIs.
It's not necessary (there is a lot of software that succeeds despite ignoring conventions) but it is a trade-off that needs to be considered - in particular if there is an existing strong native application.
I was asking my team to port our vc6 application to vc2005, they are ready to allot sometime to do the same.Now they need to know what is the advantage of porting.
I don't thing they really understand what does it mean to adhere to standard compliance.
Help me list out the advantage to do the porting.
Problem I am facing are
1)No debugging support for standard containers
2)Not able to use boost libraries
3)We use lot of query generation but use CString format function that is not type safe
4)Much time is spent on trouble shooting vc6 problems like having >>
vector<vector<int>>
with out space between >>
Advantages:
More standards compliant compiler. This is a good thing because it will make it easier to port to another platform (if you ever want to do that). It also means you can look things up in the standard rather than in microsoft's documentation. In the end you will have to upgrade your compiler at some point in the feature. The sooner you do it, the less work it will be.
Not supported by MS. The new SDK doesn't work. 64-bit doesn't work. And I don't think they're still fixing bugs either.
Nicer IDE. Personally, I really prefer tabs to MDI. I also think that it's much easier to configure Visual Studio (create custom shortcuts, menu bars, etc.). Of course that's subjective. Check out an express edition and see if you agree.
Better plugin support. Some plugins aren't available for VC6.
Disadvantages:
Time it takes to port. This very much depends on what kind of code you have. If your code heavily uses non-standards compliant VC6 features, it might take some time. As Andrew said, if you're maintaining an old legacy project, it might not be worth it.
Worse Performance. If you're developing on really old computers, Visual Studio may be too slow.
Cost I just had a quick look and Visual Studio licenses seem to be a bit more expensive than VC6's.
Why VC2005? If you are going to invest the time (and testing!) to upgrade from VC6, why not target VC2008?
If you're maintaining a legacy project then there may be no advantage in porting. Simply converting projects and fixing up compiler problems could take weeks of time and introduce instability.
If you're actively developing a product then the main advantage is that you'll no longer be using a product that's over eight years old - which is clearly a good thing.
More recent versions of the Windows SDK don't work with VC6 - if you want to use the latest Windows features, you'll need a more recent compiler.
The later compilers are said to be more standards conforming. I'm sorry I can't be more specific. I do know that VC6 generates lots of compiler warnings just for using standard template classes.
If you use any external libraries that are compiled with a later compiler, you'll need to use something compatible.
Prepare for something of a harsh transition - the IDE's are more different than they should be.
To ensure complete compatibility of the application with different versions of the base platform. And to rectify any errors found thereby so as to give enough freedom to end user to use his own version of the base platform.
I'm not saying you shouldn't convert, but to take your specific points:
1)No debugging support for standard
containers
I debug code using standard containers with VC++ 6 all the time. What's your problem here?
2)Not able to use boost libraries
True. You may find you can use some of the simpler stuff.
3)Much time is spent on trouble
shooting vc6 problems like having >>
[can't get SO to stop mangling this, nb]
with out space between >>
Um, that is a syntax error (at least in the version of C++ understood by VC++6) and will be flagged as such. If your team is spending "much time" on this sort of thing, you need another team.
Edit:
3)We use lot of query generation but
use CString format function that is
not type safe
It will be equally type-unsafe under VS2005. I don't see why this is a reason for porting. If you want type safety use the standard C++ I/O mechanisms.
If your team can't see any advantage and you are unable to explain any advantage, why are you asking them to do this?
Sounds like you are porting just for the sake of it.