|
11/23 |
2001/2/21 [Computer/SW/Languages/C_Cplusplus] UID:20640 Activity:nil |
2/19 I want to use pair, string, and list of SGI's STL at http://www.sgi.com/tech/stl with VC 6.0. I am having a hell of a time trying to compile the source, and using it. QUESTIONS: 1) Are all of the STL's out there uses/have the same interface? \_ what part of S don't you understand \_ SGI's STL has some non-standard extensions, although these are documented. 2) Other than the not intuitive docs availalbe at the site, are there any recommended online/offline references which I can use without spending like months trying to figure things out? 3) Are there more intuitive STL's out there besides SGI's? \_ There's a semi-standard interface that's defined with C++ (I believe it's part of the standard). I would rely on what's in the latest Stroustrup ("The C++ Programming Language", 3rd ed., which for the record is considerably better than previous editions) both for the "standard" interface as well as the docs. It would be difficult to learn STL from what's on the SGI site (although it is a good reference). Stroustrup does a reasonably good job. As far as VC++ goes, the way we do it is to include the header files you want (all without .h's; i.e. #include <list>, #include <string>). When you do this, everything is in the std namespace, so it is probably easiest for you to do "using namespace std;" in your include headers so you can declare lists instead of std::lists. When you do this you use the std ostream and istream operators, which differ from the regular ones, but you probably won't notice much difference. Good luck. \_ Thanks for the tips. That's very helpful. One more Q. If I want to put all of the templates in the same dir as my project as in D:\myproject\, do I need to anything special since all of the STL files refer to each other as <file> instead of "file"? \_ Minus any special knowledge about what your situation is, I would strongly urge you to leave the headers in the VC++ directories where they are shipped. STRONGLY urge. In answer to your specific question, include "" looks: directory of included file, directory of including file, compiler option /I paths, INCLUDE env. variable. include <> looks: compiler option /I paths, INCLUDE env. variable. So you might have a bit of trouble putting them in your compiling directory. (This is all MS VC++ specific; actual behavior of #include <> is "implementation defined".) \_ By the way, last time I checked MS VC++ shipped with a version of STL that didn't include hash_map. If you end up using the MS VC++ STL and you need hash_map, you can get a stand alone copy from my web page at http://www.csua.berkeley.edu/~emin \_ MS's STL was actually written by the folks at DinkumWare (http://www.dinkumware.com ; they have (costly) upgrades if you are in need of them, since they're more recent than the MS ones. Of more interest are their "bug fixes" at http://www.dinkumware.com/vc_fixes.html: well documented and quite helpful. The sstream one was of particular interest to me. \_ Try http://www.stlport.org -- it's still free, and it should work better. Read http://www.stlport.org/doc/README.VC++.html for VC++-specific issues. -- misha. |
11/23 |
|
www.sgi.com/tech/stl Industries 10 Developers 11 Services and Support 12 Serious Fun STL 13 Services & Support Standard Template Library Programmer's Guide 14 Introduction to the STL 15 How to use this site 16 Table of Contents 17 Download the STL 18 Index 19 Index by Category 20 Design Documents 21 What's New 22 Other STL Resources 23 Frequently Asked Questions 24 IOstreams library (experimental) 25 Send us a comment Permission to use, copy, modify, distribute and sell this software and its documentation for any purpose is hereby granted without fee, provided that the below copyright notice appears in all copies and that both the copyright notice and this permission notice appear in supporting documentation. Silicon Graphics makes no representations about the suitability of this software for any purpose. It is provided "as is" without express or implied warranty. Copyright 1994 Hewlett-Packard Company 26 Using this site means you accept its terms of use | 27 privacy policy | 28 trademark information Copyright 1993-2004 Silicon Graphics, Inc. |
www.dinkumware.com Dinkum Libraries Dinkum Proofers Dinkum References Dinkum Support Dinkum Exam? Order On-Line NEW! Borland Adopts Dinkum C and C++ Libraries We're pleased to announce that Borland Software Corporation has licensed our libraries for their new line of C and C++ development tools. Click here to find out more. And watch for new announcements from 10 Borland in the coming months. NEW! For Serious Developers Need to support dozens of developers, on multiple platforms? Now you can get the same level of service that Dinkumware has offered our OEM customers for the past seven years. Our new Dinkum Developer Sublicense Agreement gives you the professional backing you need to deploy C and C++ applications with the best libraries available. You get access to our rich base of C and C++ source code, to configure just the development environments you need, plus guaranteed upgrades. You can even sublicense our products as needed to satisfy your most demanding customers. Click here to find out more. Windows CE. Intel C++ compiler for Windows. You get our industry-leading Standard C++, Abridged, and EC++ libraries -- with optional iterator debugging, multithreading, exception handling, and namespaces. You can use them with the existing VC++ C library, our C95 library or our C99 library. It's a natural companion to our highly portable Dinkum Unabridged Library, which works with most other popular compilers. Click here to find out more. C and C++ libraries in one convenient and highly portable package. You get our industry-leading Standard C++, Abridged, and EC++ libraries -- with optional iterator debugging, multithreading, exception handling, and namespaces. You can use them with an existing C library, our C95 library or our C99 library. And we've ported this package to most popular compilers, running on Windows and Unix-style systems from Mac OS/X to PC Linux to Sparc Solaris to IBM S/390. With Comeau C++, we now offer the world's first completely conforming C++ and C99 implementations. Click here to find out more. Standard C++ Library. It features portable support for multi-threading, several alternative allocators for different memory-management strategies, and an assortment of the most-used multibyte/wide-character code conversions. Click here to find out more. Standard C Libraries Compared Most programmers assume that all Standard C libraries are reasonably conforming and complete. That may have been mostly true before Amendment 1 (1995) Standard C++ additions (1998), and the revised C Standard (1999), but it's far from true today. Using our new Dinkum Quick Proofer, we've tested a number of widely used C libraries to produce a unique overview of current C library technology. Click here to find out more. Standard C++ Libraries Compared It's been over two years since The C/C++ Users Journal ranked the major C++ implementations for conformance to the C++ Standard, so we decided to provide an update. We found Perennial's C++VS and our own Dinkum C++ Proofer to give pretty consistent results. The only completely conforming libraries today are from Dinkumware. They easily outranked other commercial libraries, such as from Rogue Wave, as well as no-cost add-ons, such as STLport and LibStdc++. Click here to find out more. Try Before You Buy The Dinkum Exam Page lets you compile and link your own test code against our various libraries. Find out whether your code truly conforms to the C++ or C Standards, or to the EC++ Technical Specification. See how close our Windows CE library matches the VC++ desktop environment. Learn first hand what compiled Java can do for your small or embedded programs. Click here to give it a try. Manuals for C++, C99, EC++, CoreX, and Java We offer our latest HTML Library References for C++, C99, EC++, CoreX, and Java for your perusal right here at our website. You can purchase the first three of these, as our Dinkum Unabridged Library, for immediate download. They make a convenient reference while you work. They even look good on handhelds. We also offer deep discounts for use by multiple developers. Click here to find out more. Java^ Compiler Technology from Dinkumware and EDG You can combine JFE, the 20 Edison Design Group Java front end, along with the 21 Dinkum Jcore Library, for a true compiled Java environment. The JFE/Jcore combination are the result of our joint development 22 project with EDG. Read about our novel approach to 23 compiling Java code just like C. Posix Locales for Dinkum C The Dinkum C Library has long featured rich support for tailorable locales. We provide, as a free upgrade, the dozens of Western locales collected over the years by SC22/WG15 (Posix) in a form directly usable by our C Library customers. They're equally accessible from C++ if you license our Dinkum Unabridged Library. Teach your code to print dates in Finnish, or to order text by Spanish rules. Click here to find out more. Our Track Record We're the folks who supply the Standard C++ library that ships with Microsoft VC++, and we've done so for the past seven years. We're also the leading supplier of C++ and EC++ libraries to the embedded community. We offer the only commercially supported Standard C and C99 libraries not tied to a specific compiler, and we offer the only libraries that conform completely to the C++ and C99 Standards. To learn more about us, see our recent 25 press releases and a partial list of our 26 customers and partners. Our Expertise We at Dinkumware have particular expertise on the Standard C, C++, and Java 27 libraries. We tracked the development of Standard C++ through its final stages, upgrading our 28 documentation, source code, and testing tools 29 (Proofers) to match it at each stage. We've also upgraded our mature and successful Standard C Library to match the recently revised C Standard (C99). And our Jcore Library is tracking the evolving Java specification. As the choice of leading software vendors, our products may well be just what you need to stay up to date with C, C++, and Java. Dinkumware, Ltd. Copyright 1996-2003 by Dinkumware, Ltd. Dinkumware, Dinkum, Jcore, and Proofer are registered trademarks of Dinkumware, Ltd. Please see our 32 privacy statement. Edison Design Group is a registered trademark of Edison Design Group, Inc. Windows and Visual C++ are registered trademarks of Microsoft Corporation Inc. Java is a registered trademark of Sun Microsystems, Inc. Sand Eater Image The Dinky Di Meet the newest breed of Australian sand eater, first observed in 1999. You can trust its heritage because old bushmen call it the Dinky Di. That's about as genuine as they come in Oz. X References 1. |
www.dinkumware.com/vc_fixes.html Dinkum Libraries Dinkum Proofers Dinkum References Dinkum Support Dinkum Exam? You can also install the replacement file directly from the browser while you are viewing it -- simply select File/Save As File and store the file with the appropriate name in the include directory. YOU ARE STRONGLY ENCOURAGED TO SAVE THE EXISTING HEADER BEFORE OVERWRITING IT. Files\DevStudio\VC\include and save the file with the name deque. Be warned that updating a header file does not necessarily trigger a recompilation. You may have to force a rebuild to see the effect of a change. Note also that some header-file information is captured in DLLs supplied by Microsoft. If you encounter a conflict, you must either avoid using the DLL (by linking statically) or rebuild the offending DLL. We still can supply no information on how to rebuild the standard DLLs shipped with VC++. It is always a good idea to apply the latest Microsoft service pack to upgrade your compiler. Many problems quietly disappear when you do so. SP3. Plauger. All rights reserved. Microsoft Corporation is in no way involved with the production or release of these files. The files are offered on an as is'' basis. DINKUMWARE, LTD. PLAUGER MAKE NO REPRESENTATIONS OR WARRANTIES ABOUT THE SUITABILITY OF THESE FILES, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. DINKUMWARE, LTD. PLAUGER SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY LICENSEE AS A RESULT OF USING THESE FILES. Fix to <algorithm> The internal template algorithm _Buffered_merge (two versions) fails to initialize local variables in two places. Change the code as indicated by the comments: if (_D2 < _D1) {_D1n = _D1 / 2, _D2n = 0; And for the version with predicate: if (_D2 < _D1) {_D1n = _D1 / 2, _D2n = 0; If the sequence exactly fills the last allocated block, incrementing the iterator that designates the last element can yield a value that does not match the value returned by end(). The larger the elements stored in the container, the more likely this situation will arise. The fix is to ensure that every iterator has just one possible representation. For added security, the ends of the container are now guarded with null map pointers. It is no longer possible to step an iterator off either end of the sequence. The header <fstream> defines template class basic_filebuf (among other things. Its member function _Init contains a bug that causes files opened by name to disable buffering unnecessarily, resulting in a serious degradation of performance. Fix to <istream> The header <istream> contains a definition for member function basic_istream::getline. It has a lookahead problem -- typing a delimiter to end the input doesn't return control until you type yet another character. Change the code as indicated by the comment: else if (_C == _Di) {++_Chcount; It is an adequate fix, but you can also apply the above patch safely. Fix to <list> (updated 7 July 1998) Both versions of the member function list::sort misplace elements if asked to sort a container with more than 32,768 elements. You might also consider increasing _MAXN from 15 to, say 25. That way, you would have to sort a list of more than 32 million elements, instead of 32 thousand, before the performance begins to degrade. Fix to <memory> Template class auto_ptr creates two owners for an object if you copy an auto_ptr object back to a previous owner that still stores the same object pointer. Note that this template class has been redesigned more than once since this version of the library was frozen. No attempt is made here to track those changes. Class basic_stringbuf grows its buffer by fixed-size increments, which can be very slow if the buffer gets very large. To grow the buffer exponentially, replace the line in basic_stringbuf::overflow that reads: size_t _Ns = _Os + _Alsize; Fix to <string> The header <string> contains a definition for template function getline. It has a lookahead problem -- typing a delimiter to end the input doesn't return control until you type yet another character. Change the code as indicated by the comment: else if (_Tr::eq(_C, _D)) {_Chg = true; Fix to <vector> The header <vector> sometimes fails to extend a vector properly. In two versions ofinsert, change the code as shown: _Destroy(_First, _Last); Fix to <xmemory> Template class _Destroy has an unfortunate interaction with a bug in the VC++ compiler. It gets confused if you ask it to destroy an object of a class that defines the name _Ty. The best workaround is to replace the template parameter _Ty with a really strange name, as in: // TEMPLATE FUNCTION _Destroy template<class _Xyzzy> inline void _Destroy(_Xyzzy _FARQ *_P) {_DESTRUCTOR(_Xyzzy, _P); Fixes to <xstring> The header 12 <xstring> (original 25 May 1998) presented here corrects a problem with string assignments. Assigning a shorter sequence to an existing string can cause the old string to be copied in full to the newly allocated area, thus causing a storage overwrite, and an occasional storage leak as a result. In rarer circumstances, a string is partially altered by a replace member function before the copy on write occurs, thus causing changes to an apparently unrelated string object. The fix is a small but significant change to the private member function _Grow. Several calls to _Freeze, to force a copy on write, are also added. Please note that this implementation is still not as thread safe as it should be, because of the reference-counted implementation. A write to a copy'' of a string in one thread can confuse a read of that string in another thread, because the two still secretly share the same representation. Another way is to disable reference-counting altogether, making string operations thread safe. Simply change the value of _FROZEN to zero: enum _Mref {_FROZEN = 255}; Fix to <xtree> The header 13 <xtree> (original 25 June 1998) presented here eliminates all need for thread locks and corrects a number of thread-safety issues for template classes map, multimap, set, and multiset. It also solves some nasty problems with sharing these classes across DLLs. Note that no attempt has been made to retrofit the changes needed to make these template classes exception safe in the sense required by the final C++ Standard. March 2000) fails to supply locale information needed for the %X conversion specifier used by template class time_put. To fix the problem, add the missing line shown below to the function _Gettnames. Change the code from: s += strlen(strcpy(s, pt->ww_ldatefmt)) + 1; Dinkumware. We do not supply a replacement for it. Copyright 1996-2003 by Dinkumware, Ltd. Dinkumware, Dinkum, Jcore, and Proofer are registered trademarks of Dinkumware, Ltd. Windows and Visual C++ are registered trademarks of Microsoft Corporation Inc. X References 1. |
www.stlport.org The company was started back in 1997 by a small group of developers gathered around STLport Standard Library Project. Since then STLport has been accepted by the technical community as industry standard for multiplatform development. |
www.stlport.org/doc/README.VC++.html If you are using new_alloc or malloc_alloc, you won't need that). Using _STLP_USE_OWN_NAMESPACE is the most safe way to cooperate with new I/O library and is definitely recommended unless you recompile the whole C++ std library with STLport installed. Default node allocator is quite fast, so I wouldn't recommend disabling it without serious reason. However, if it causes problems, define _STLP_USE_MALLOC or _STLP_USE_NEWALLOC to get bare malloc()-based or new()-based default allocator. Using native versions is necessary to avoid clashes with compiled code in C++ runtime library. |
www.csua.berkeley.edu/~emin -> www.csua.berkeley.edu/~emin/ Old Farmer's Almanac * 10 Great Books Online Software: * 11 SourceForge * 12 Freshmeat * 13 GNU News: * 14 National Public Radio * 15 New York Times * 16 Slashdot Thesaurus: Go Dictionary: Go Google: Search Quote of the day from the UNIX fortune program: Convention is the ruler of all. |