C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  [std lib] is cute feature X missing? Goto page 1, 2, 3  Next          C++Talk.NET Forum Index -> C++ language, library and standards View previous topic :: View next topic   Author Message Thorsten Ottosen Guest Posted: Tue Aug 16, 2005 9:44 pm    Post subject: [std lib] is cute feature X missing? Dear All, I'm baking on a small paper for the C++ standard committee. It's gonna be a mix of little things or changes or tweaks to the standard library. If you have any ideas that you would like me to incorporate, let's discuss it here and we'll see if its worth including. Maybe you're missing an algorithm. Maybe you would like a new member function in vector. Who knows. Let's hear your ideas. I have my own list, but I won't disclose it before the paper is out. best regards Thorsten --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Joe Gottman Guest Posted: Wed Aug 17, 2005 3:02 am    Post subject: Re: [std lib] is cute feature X missing? ""Thorsten Ottosen"" <nesotto (AT) cs (DOT) aau.dk> wrote Quote: Dear All, I'm baking on a small paper for the C++ standard committee. It's gonna be a mix of little things or changes or tweaks to the standard library. If you have any ideas that you would like me to incorporate, let's discuss it here and we'll see if its worth including. Maybe you're missing an algorithm. Maybe you would like a new member function in vector. Who knows. Let's hear your ideas. I have my own list, but I won't disclose it before the paper is out. best regards Thorsten One thing that would be neat is a make_array template function, similar to make_pair and make_tuple, that returns a tr1::array object. template <class X> array<X, 0> make_array(); template <class X, class P1> array<X, 1> make_array(const P1 &p1); template <class X, class P1, class P2> array<X, 2> make_array(const P1 &p1, const P2 &p2); etc. This would interact very nicely with the new auto syntax, which seems likely to make it into C++09 auto array1 = make_array<string>("Foo", "Bar", "Glarch"); // type is array<string, 3> auto array2 = make_array<double>(1, 2, 2.5, 3); //type is array<double, 4> The paper that originally proposed tr1::array (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1479.html) mentioned that there was no way to parallel the automatic type deduction seen in the code int x[] = {0, 1, 2, 3}; The make_array function together with auto would add that ability, albeit with a new syntax. Joe Gottman --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top garthdickie@gmail.com Guest Posted: Wed Aug 17, 2005 4:34 am    Post subject: Re: is cute feature X missing? Jim King posted a suggestion a few years ago for std::set set-theoretic operators: http://groups.google.com/group/comp.std.c++/tree/browse_frm/thread/34ce925366074bd5/e9bbf1c4c3c32a35?rnum=1&hl=en&q=james+e+king&_done=%2Fgroup%2Fcomp.std.c%2B%2B%2Fbrowse_frm%2Fthread%2F34ce925366074bd5%2Fe9bbf1c4c3c32a35%3Fq%3Djames+e+king%26rnum%3D2%26hl%3Den%26#doc_e9bbf1c4c3c32a35 I have been using his implementation for more than three years, and it certainly makes it a lot easier to deal with sets. The operators are union ( operator | ), intersection ( operator & ), symmetric difference ( operator ^ ), and set difference ( operator - ), as well as the in-place versions |=, &=, ^=, and -=. --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Thorsten Ottosen Guest Posted: Wed Aug 17, 2005 9:22 pm    Post subject: Re: [std lib] is cute feature X missing? ""Joe Gottman"" <jgottman (AT) carolina (DOT) rr.com> wrote Quote: ""Thorsten Ottosen"" <nesotto (AT) cs (DOT) aau.dk> wrote in message Let's hear your ideas. One thing that would be neat is a make_array template function, similar to make_pair and make_tuple, that returns a tr1::array object. template <class X> array<X, 0> make_array(); template <class X, class P1> array<X, 1> make_array(const P1 &p1); template <class X, class P1, class P2> array<X, 2> make_array(const P1 &p1, const P2 &p2); etc. This would interact very nicely with the new auto syntax, which seems likely to make it into C++09 auto array1 = make_array<string>("Foo", "Bar", "Glarch"); // type is array<string, 3 auto array2 = make_array 4 The paper that originally proposed tr1::array (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1479.html) mentioned that there was no way to parallel the automatic type deduction seen in the code int x[] = {0, 1, 2, 3}; The make_array function together with auto would add that ability, albeit with a new syntax. In the example above, one can use the normal { .... } syntax. Mentioning the type is easier than with make_array, but specifying the size is irritating. Then again, why not use a vector if you don't want to specify the size? (well, eficieny, but is that important here?) If only we could avoid making N overloads of the function :-) Another question is what the practical limit of the number of overloads should be? -Thorsten --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Thorsten Ottosen Guest Posted: Thu Aug 18, 2005 5:34 am    Post subject: Re: is cute feature X missing? <garthdickie (AT) gmail (DOT) com> wrote Quote: Jim King posted a suggestion a few years ago for std::set set-theoretic operators: http://groups.google.com/group/comp.std.c++/tree/browse_frm/thread/34ce925366074bd5/e9bbf1c4c3c32a35?rnum=1&hl=en&q=james+e+king&_done=%2Fgroup%2Fcomp.std.c%2B%2B%2Fbrowse_frm%2Fthread%2F34ce925366074bd5%2Fe9bbf1c4c3c32a35%3Fq%3Djames+e+king%26rnum%3D2%26hl%3Den%26#doc_e9bbf1c4c3c32a35 nice little post Quote: I have been using his implementation for more than three years, and it certainly makes it a lot easier to deal with sets. yes, that would be the main argument. performane wise I have also considered that it should be possible tp "splice" two sets (or maps for that sake), and these operators do all that. His implmentation of uset is far from optimal. I imagine that member operations that move elements from one set to another can move the nodes themselves and thus completely avoid allocations. Quote: The operators are union ( operator | ), intersection ( operator & ), symmetric difference ( operator ^ ), and set difference ( operator - ), as well as the in-place versions |=, &=, ^=, and -=. it all seems fairly simple to specify. I'll seriously consider it. Thanks -Thorsten --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Joe Gottman Guest Posted: Thu Aug 18, 2005 5:35 am    Post subject: Re: [std lib] is cute feature X missing? ""Thorsten Ottosen"" <nesotto (AT) cs (DOT) aau.dk> wrote Quote: ""Joe Gottman"" <jgottman (AT) carolina (DOT) rr.com> wrote in message news:pvvMe.134235$3j2.4505031 (AT) twister (DOT) southeast.rr.com... ""Thorsten Ottosen"" <nesotto (AT) cs (DOT) aau.dk> wrote in message Let's hear your ideas. One thing that would be neat is a make_array template function, similar to make_pair and make_tuple, that returns a tr1::array object. template <class X> array<X, 0> make_array(); template <class X, class P1> array<X, 1> make_array(const P1 &p1); template <class X, class P1, class P2> array<X, 2> make_array(const P1 &p1, const P2 &p2); etc. This would interact very nicely with the new auto syntax, which seems likely to make it into C++09 auto array1 = make_array<string>("Foo", "Bar", "Glarch"); // type is array<string, 3 auto array2 = make_array array<double, 4 The paper that originally proposed tr1::array (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1479.html) mentioned that there was no way to parallel the automatic type deduction seen in the code int x[] = {0, 1, 2, 3}; The make_array function together with auto would add that ability, albeit with a new syntax. In the example above, one can use the normal { .... } syntax. Mentioning the type is easier than with make_array, but specifying the size is irritating. Then again, why not use a vector if you don't want to specify the size? (well, eficieny, but is that important here?) One reason is that make_array can be used after construction. array // do some processing foo = make_array<int>(4, 5, 6); Also, tr1::array is supposed to be a replacement for C-style arrays. It would be nice if it emulated all the features of C-style arrays, including automatic size deduction. Quote: If only we could avoid making N overloads of the function :-) This might be possible if the variadic template proposal passes ([url]http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1603.pdf)[/url]. I have no idea how likely this is to happen. Quote: Another question is what the practical limit of the number of overloads should be? At least the maximum number of elements allowed in a tuple, which is implementation-defined but at least 10. Joe Gottman --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Jeff Flinn Guest Posted: Fri Aug 19, 2005 4:58 am    Post subject: Re: is cute feature X missing? ""Thorsten Ottosen"" <nesotto (AT) cs (DOT) aau.dk> wrote Quote: [email]garthdickie (AT) gmail (DOT) com[/email]> wrote in message news:1124248853.468519.15200 (AT) o13g2000cwo (DOT) googlegroups.com... Jim King posted a suggestion a few years ago for std::set set-theoretic operators: http://groups.google.com/group/comp.std.c++/tree/browse_frm/thread/34ce925366074bd5/e9bbf1c4c3c32a35?rnum=1&hl=en&q=james+e+king&_done=%2Fgroup%2Fcomp.std.c%2B%2B%2Fbrowse_frm%2Fthread%2F34ce925366074bd5%2Fe9bbf1c4c3c32a35%3Fq%3Djames+e+king%26rnum%3D2%26hl%3Den%26#doc_e9bbf1c4c3c32a35 nice little post I have been using his implementation for more than three years, and it certainly makes it a lot easier to deal with sets. yes, that would be the main argument. performane wise I have also considered that it should be possible tp "splice" two sets (or maps for that sake), and these operators do all that. His implmentation of uset is far from optimal. I imagine that member operations that move elements from one set to another can move the nodes themselves and thus completely avoid allocations. The operators are union ( operator | ), intersection ( operator & ), symmetric difference ( operator ^ ), and set difference ( operator - ), as well as the in-place versions |=, &=, ^=, and -=. it all seems fairly simple to specify. I'll seriously consider it. This one gets my vote as well. I've had several projects that would have benefited from the availability of such functionality. Jeff Flinn --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Thorsten Ottosen Guest Posted: Fri Aug 19, 2005 4:58 am    Post subject: Re: [std lib] is cute feature X missing? ""Joe Gottman"" <jgottman (AT) carolina (DOT) rr.com> wrote Quote: ""Thorsten Ottosen"" <nesotto (AT) cs (DOT) aau.dk> wrote in message In the example above, one can use the normal { .... } syntax. Mentioning the type is easier than with make_array, but specifying the size is irritating. Then again, why not use a vector if you don't want to specify the size? (well, eficieny, but is that important here?) One reason is that make_array can be used after construction. array<int, 3> foo = make_array<int>(1,2, 3); // do some processing foo = make_array<int>(4, 5, 6); right. is that very used? the committee is going to look a lot at initialization for C++0x, for example to support { .... } initialization of classes like vector. perhaps one should also be able to use { ... } in assignments. Quote: Also, tr1::array is supposed to be a replacement for C-style arrays. It would be nice if it emulated all the features of C-style arrays, including automatic size deduction. it would be nice. Quote: If only we could avoid making N overloads of the function :-) This might be possible if the variadic template proposal passes ([url]http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1603.pdf)[/url]. I have no idea how likely this is to happen. me neither. br -Thorsten --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Joe Gottman Guest Posted: Fri Aug 19, 2005 11:40 pm    Post subject: Re: is cute feature X missing? ""Jeff Flinn"" <NONONE (AT) nowhere (DOT) com> wrote Quote: ""Thorsten Ottosen"" <nesotto (AT) cs (DOT) aau.dk> wrote in message news:4303a7ce$0$18645$14726298 (AT) news (DOT) sunsite.dk... [email]garthdickie (AT) gmail (DOT) com[/email]> wrote in message news:1124248853.468519.15200 (AT) o13g2000cwo (DOT) googlegroups.com... Jim King posted a suggestion a few years ago for std::set set-theoretic operators: http://groups.google.com/group/comp.std.c++/tree/browse_frm/thread/34ce925366074bd5/e9bbf1c4c3c32a35?rnum=1&hl=en&q=james+e+king&_done=%2Fgroup%2Fcomp.std.c%2B%2B%2Fbrowse_frm%2Fthread%2F34ce925366074bd5%2Fe9bbf1c4c3c32a35%3Fq%3Djames+e+king%26rnum%3D2%26hl%3Den%26#doc_e9bbf1c4c3c32a35 nice little post I have been using his implementation for more than three years, and it certainly makes it a lot easier to deal with sets. yes, that would be the main argument. performane wise I have also considered that it should be possible tp "splice" two sets (or maps for that sake), and these operators do all that. His implmentation of uset is far from optimal. I imagine that member operations that move elements from one set to another can move the nodes themselves and thus completely avoid allocations. The operators are union ( operator | ), intersection ( operator & ), symmetric difference ( operator ^ ), and set difference ( operator - ), as well as the in-place versions |=, &=, ^=, and -=. it all seems fairly simple to specify. I'll seriously consider it. This one gets my vote as well. I've had several projects that would have benefited from the availability of such functionality. Note also that std::set_union, set_intersection, etc. don't work with hashed containers because they require sorted ranges. If we add these for associative sets we might as well do the same for hashed sets. Joe Gottman --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Zara Guest Posted: Tue Aug 23, 2005 2:30 pm    Post subject: Re: is cute feature X missing? I think standard library could be extended so that the following program could be legal: #include <main> void main(std::vector<std::string> const & args) { (...) } <main> would be a system header that be something like: #include <vector> #include <string> void main(std::vector<std::string> const & args); int main(int argc, char * argv[]) { std::vector<std::string> args(argc); for (int index=0;index } That should give an "STLed" way of writing the main function of a programa, and would link it to the concrete library implementation being used. Just to forget c strings. --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Thorsten Ottosen Guest Posted: Wed Aug 24, 2005 5:32 am    Post subject: Re: is cute feature X missing? "Zara" <yozara (AT) terra (DOT) es> wrote Quote: I think standard library could be extended so that the following program could be legal: #include <main void main(std::vector { (...) } That should give an "STLed" way of writing the main function of a programa, and would link it to the concrete library implementation being used. Just to forget c strings. well, the above is nice, but usually not enough when you really need parse options. http://www.boost.org/doc/html/program_options.html shows how much that is actually needed. br Thorsten --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Joe Gottman Guest Posted: Thu Aug 25, 2005 3:45 am    Post subject: Re: is cute feature X missing? I've just thought of another possible cute feature. I've occasionally seen posts on this board complaining about the fact that the code vector<double> vec(1000); zero-initializes the vector. If the vector is to be used as an output-buffer for instance, this may cost more time than the user would like. What if we made it possible to say something like vector<double> vec(1000, no_init); to create a vector<double> of size 1000 without zero-initializing it? no_init would be a special value, like ignore in the sequence int x, z; tie(x, ignore, z) = tuple<int, int, int>(1,2,3); // now x = 1 and z = 3. Of course, this constructor would have to require that the vector's value_type be a POD, but it could be very useful for people who need to squeeze the last ounce of speed out of their programs. Also, if we do add this constructor, we would also want to be able to say vec.resize(2000, no_init); as well, with this version of resize() also requiring that the vector's value_type be a POD. It might also be possible to add this functionality for deque and list, but I don't see this as nearly as useful. Joe Gottman --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Howard Hinnant Guest Posted: Thu Aug 25, 2005 3:44 pm    Post subject: Re: is cute feature X missing? In article <009Pe.46776$ll3.540047 (AT) twister (DOT) southeast.rr.com>, [email]jgottman (AT) carolina (DOT) rr.com[/email] ("Joe Gottman") wrote: Quote: I've just thought of another possible cute feature. I've occasionally seen posts on this board complaining about the fact that the code vector<double> vec(1000); zero-initializes the vector. If the vector is to be used as an output-buffer for instance, this may cost more time than the user would like. What if we made it possible to say something like vector<double> vec(1000, no_init); to create a vector<double> of size 1000 without zero-initializing it? no_init would be a special value, like ignore in the sequence int x, z; tie(x, ignore, z) = tuple<int, int, int>(1,2,3); // now x = 1 and z = 3. Of course, this constructor would have to require that the vector's value_type be a POD, but it could be very useful for people who need to squeeze the last ounce of speed out of their programs. Also, if we do add this constructor, we would also want to be able to say vec.resize(2000, no_init); as well, with this version of resize() also requiring that the vector's value_type be a POD. It might also be possible to add this functionality for deque and list, but I don't see this as nearly as useful. You'll get more milage out of: template <class T, class A> class vector { ... template <class F> vector(size_type n, F f); ... }; used like: struct no_init {    template <class T>     void operator()(T*, size_t) {} }; std::vector<double> vec(1000, no_init()); This has the added advantage of being able to initialize your vector with legacy C code: extern "C" int interpol(const double *x, const double *fx, int n,              const double *z, double *pz, int m); inline vector<double> interpolate(const vector<double>& x, const vector<double>& fx, const vector<double>& z) { assert(x.size() == fx.size()); return vector<double> ( z.size(), bind ( interpol, x.data(), fx.data(), x.size(), z.data(), _1, _2 ) ); } In the example above, the returned vector is sized and then initialized by calling the legacy C interpol function. bind is used to adapt the interface of the legacy C function into the f(T*, size) functor that vector is looking for. -Howard --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top msalters Guest Posted: Fri Aug 26, 2005 4:26 am    Post subject: Re: is cute feature X missing? "Joe Gottman" schreef: Quote: I've just thought of another possible cute feature. I've occasionally seen posts on this board complaining about the fact that the code vector<double> vec(1000); zero-initializes the vector. If the vector is to be used as an output-buffer for instance, this may cost more time than the user would like. What if we made it possible to say something like vector<double> vec(1000, no_init); to create a vector<double> of size 1000 without zero-initializing it? Why no spell it void()? That looks like an expression. vector<double> vec(1000, void() ); Of course, we could generalize that: int i = void(); // leave i uninitialized The reason you'd do that is to make int i; equal to int i = int(); This doesn't break existing programs (they'd have to assume i could be anything, 0 included) but makes it easier for new programmers. The void() syntax would again be a performance optimalization. HTH, Michiel Salters --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Joe Gottman Guest Posted: Fri Aug 26, 2005 5:17 am    Post subject: Re: is cute feature X missing? "Howard Hinnant" <hinnant (AT) metrowerks (DOT) com> wrote Quote: In article <009Pe.46776$ll3.540047 (AT) twister (DOT) southeast.rr.com>, [email]jgottman (AT) carolina (DOT) rr.com[/email] ("Joe Gottman") wrote: I've just thought of another possible cute feature. I've occasionally seen posts on this board complaining about the fact that the code vector<double> vec(1000); zero-initializes the vector. If the vector is to be used as an output-buffer for instance, this may cost more time than the user would like. What if we made it possible to say something like vector<double> vec(1000, no_init); to create a vector<double> of size 1000 without zero-initializing it? no_init would be a special value, like ignore in the sequence int x, z; tie(x, ignore, z) = tuple<int, int, int>(1,2,3); // now x = 1 and z = 3. Of course, this constructor would have to require that the vector's value_type be a POD, but it could be very useful for people who need to squeeze the last ounce of speed out of their programs. Also, if we do add this constructor, we would also want to be able to say vec.resize(2000, no_init); as well, with this version of resize() also requiring that the vector's value_type be a POD. It might also be possible to add this functionality for deque and list, but I don't see this as nearly as useful. You'll get more milage out of: template <class T, class A class vector { .. template .. }; used like: struct no_init { template <class T void operator()(T*, size_t) {} }; std::vector This has the added advantage of being able to initialize your vector with legacy C code: extern "C" int interpol(const double *x, const double *fx, int n, const double *z, double *pz, int m); inline vector<double interpolate(const vector const vector<double>& fx, const vector<double>& z) { assert(x.size() == fx.size()); return vector<double ( z.size(), bind ( interpol, x.data(), fx.data(), x.size(), z.data(), _1, _2 ) ); } In the example above, the returned vector is sized and then initialized by calling the legacy C interpol function. bind is used to adapt the interface of the legacy C function into the f(T*, size) functor that vector is looking for. How would this interact with the current vector::vector(size_t, const value_type &, const Allocator &) constructor? Currently, if I write vector the compiler will correctly call that constructor, converting 42 from an int to a double. Would your proposed template constructor get called in this case? Unless one of the concepts proposals is accepted I'm afraid that it would. My original proposal is a non-template constructor, and decltype(no_init) would not be convertible to or from any other type, so it would probably be much safer. Joe Gottman --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ language, library and standards All times are GMT Goto page 1, 2, 3  Next Page 1 of 3   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.