C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  proposal for a new class: a buffer Goto page 1, 2  Next          C++Talk.NET Forum Index -> C++ language, library and standards View previous topic :: View next topic   Author Message Tommi Mäkitalo Guest Posted: Sat Dec 17, 2005 4:16 am    Post subject: proposal for a new class: a buffer Hi, I would like to make a proposal for a new class it the standard-library: a buffer. The motivation is, that I need often a buffer for collecting something temporary, e.g. a receive-buffer for network-IO. The systemcall read needs a pointer to memory, where it should write the received data. I could use a static array, but to make the buffer configurable at runtime, I need to deal with heap-memory. I have to allocate memory, which need to be released somewhere. A buffer-class allocates, holds and releases the memory, but allowes full access to it. The buffer could be used also in a std::streambuf as the actual data-area. A uage-example is here: void someFunc(int fd, unsigned bufsize) { std::buffer<char> myBuffer; myBuffer.resize(bufsize); // or std::buffer<> myBuffer(bufsize); int n = read(fd, myBuffer.data(), bufsize); // do something with the data } std::buffer is not copyable or assignable. This makes it as lightweight as possible. I have a implemenation of something like it in my own toolbox and find it very handy. What do you think about it? Tommi Mäkitalo --- [ 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 Nevin :-] Liber Guest Posted: Sat Dec 17, 2005 5:59 am    Post subject: Re: proposal for a new class: a buffer In article <dnv8qa$2ahs$1 (AT) ulysses (DOT) news.tiscali.de>, Tommi Mäkitalo <tommi (AT) maekitalo (DOT) de> wrote: Quote: A buffer-class allocates, holds and releases the memory, but allowes full access to it. The buffer could be used also in a std::streambuf as the actual data-area. A uage-example is here: void someFunc(int fd, unsigned bufsize) { std::buffer<char> myBuffer; myBuffer.resize(bufsize); // or std::buffer<> myBuffer(bufsize); int n = read(fd, myBuffer.data(), bufsize); // do something with the data } What do you think about it? I think I'd rather just use std::vector. I don't see what this offers that vector doesn't. -- Nevin "" Liber <mailto:nevin (AT) eviloverlord (DOT) com> (773) 961-1620 --- [ 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 Tommi Mäkitalo Guest Posted: Sat Dec 17, 2005 11:58 pm    Post subject: Re: proposal for a new class: a buffer Nevin ":-]" Liber wrote: .. Quote: I think I'd rather just use std::vector. I don't see what this offers that vector doesn't. You don't get a writable pointer to data from a std::vector. Tommi --- [ 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 Dietmar Kuehl Guest Posted: Sat Dec 17, 2005 11:58 pm    Post subject: Re: proposal for a new class: a buffer Tommi Mäkitalo wrote: Quote: A buffer-class allocates, holds and releases the memory, but allowes full access to it. Have you looked at the functions 'get_temporary_buffer()' and 'return_temporary_buffer()'? What does your class offer which these functions don't - except, of course, the automated acquire and release. I think these two function provide the necessary functionality including the ability to deal appropriately with situations where no temporary buffer of the required size is available. A thin and easy to write wrapper class could do just this and provide your favorite buffer interface of the day, i.e. it is something not reasonable to put into a standard. Quote: The buffer could be used also in a std::streambuf as the actual data-area. Stream buffers need to cling to their buffers. It is entirely appropriate to allocate the buffer e.g. on the heap or embedded into the buffer. -- <mailto:dietmar_kuehl (AT) yahoo (DOT) com> <http://www.dietmar-kuehl.de/> <http://www.eai-systems.com> - Efficient Artificial Intelligence --- [ 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 Marc Schoolderman Guest Posted: Sat Dec 17, 2005 11:58 pm    Post subject: Re: proposal for a new class: a buffer [email]nevin (AT) eviloverlord (DOT) com[/email] wrote: Quote: std::buffer<char> myBuffer; myBuffer.resize(bufsize); // or std::buffer<> myBuffer(bufsize); int n = read(fd, myBuffer.data(), bufsize); // do something with the data What do you think about it? I think I'd rather just use std::vector. I don't see what this offers that vector doesn't. Perhaps it should be pointed out that a vector<char> also provides complete access to its internals: std::vector<char> myBuffer(bufsize); int n = read(fd, &myBuffer[0], bufsize); // do something ~Marc. --- [ 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 Tommi Mäkitalo Guest Posted: Sat Dec 17, 2005 11:59 pm    Post subject: Re: proposal for a new class: a buffer Nevin ":-]" Liber wrote: Quote: In article <dnv8qa$2ahs$1 (AT) ulysses (DOT) news.tiscali.de>, .. I think I'd rather just use std::vector. I don't see what this offers that vector doesn't. A difference is also, that a buffer don't need to care about data, when resized. The buffer throws the old data away and allocates new. There are 2 advantages about this approach: The data don't need to be copied, which speeds it up and the memory is only needed once. When a vector is copied, it needs at least temporarily space for the old and for the new data. A buffer will have a method swap, which eases reallocating and manually copying data like this: std::buffer<char> buffer(initial_size); .. // to extend size and keep the data: { std::buffer<char> tmpBuffer(initial_size + some_amount); // allocate a larger buffer std::copy(buffer.begin(); buffer.end(), tmpBuffer.begin()); // copy old data to the new buffer buffer.swap(tmpBuffer); // replace the old buffer with the new one // tmpBuffer now holds the old buffer } // the destructor of tmpBuffer deallocates the old data Maybe there should be a basic_buffer and typedefs like this: namespace std { template <typename _CharT, typename _Alloc = allocator<_CharT> > class basic_buffer; typedef basic_buffer<char> buffer; typedef basic_buffer<wchar_t> wbuffer; } There is no traits, because buffer does not do anything with the character-type. The user can as well define e.g. a: typedef basic_buffer<struct pollfd> pollfd_buffer; for use in poll(2). --- [ 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 Tommi Mäkitalo Guest Posted: Sun Dec 18, 2005 4:22 pm    Post subject: Re: proposal for a new class: a buffer Dietmar Kuehl wrote: Quote: Tommi Mäkitalo wrote: A buffer-class allocates, holds and releases the memory, but allowes full access to it. Have you looked at the functions 'get_temporary_buffer()' and 'return_temporary_buffer()'? What does your class offer which these functions don't - except, of course, the automated acquire and release. I think these two function provide the necessary functionality including the ability to deal appropriately with situations where no temporary buffer of the required size is available. A thin and easy to write wrapper class could do just this and provide your favorite buffer interface of the day, i.e. it is something not reasonable to put into a standard. The buffer could be used also in a std::streambuf as the actual data-area. Stream buffers need to cling to their buffers. It is entirely appropriate to allocate the buffer e.g. on the heap or embedded into the buffer. Exactly this automated acquire and release is what I get, including exception-safety. I need sometimes the system-call poll. This need a pointer to struct pollfd, where I can pass the file-descriptors, I am interested in. I can't use get_temporary_buffer here, because I don't want to deal with less than a specific count of elements. It is perfectly ok to get a alloc_error, when memory is exhausted. It is a easy to write wrapper, but very usable. I don't think it is a argument, that it is simple to write. std::copy is simple to write. And so is std::auto_ptr. Or less, min, max. The standard should have solutions for common problems. They might be trivial, but I like code, where I can say: Oh - here is a list<> - I know exactly, how the program deal with the data, without looking into the implementation or documentation of some individual solution. And so it would be nice to see: Oh - here the program uses std::basic_buffer<char> - the program handles memory in a exception-safe manner. Tommi --- [ 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: Sun Dec 18, 2005 4:23 pm    Post subject: Re: proposal for a new class: a buffer Tommi Mäkitalo wrote: Quote: Nevin ":-]" Liber wrote: . I think I'd rather just use std::vector. I don't see what this offers that vector doesn't. You don't get a writable pointer to data from a std::vector. you do: if( !vec.empty() ) foo( &*vec.begin(), vec.size() ) the problem with vector is that you then initialize the data twice, quite expensive in many situations. Some proposals have been made to remedy this: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1870.html#add-set-buffer-t-size-t-to-vector-and-basic-string -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 Greg Herlihy Guest Posted: Sun Dec 18, 2005 4:23 pm    Post subject: Re: proposal for a new class: a buffer Tommi Mäkitalo wrote: Quote: Hi, I would like to make a proposal for a new class it the standard-library: a buffer. The motivation is, that I need often a buffer for collecting something temporary, e.g. a receive-buffer for network-IO. The systemcall read needs a pointer to memory, where it should write the received data. I could use a static array, but to make the buffer configurable at runtime, I need to deal with heap-memory. I have to allocate memory, which need to be released somewhere. A buffer-class allocates, holds and releases the memory, but allowes full access to it. The buffer could be used also in a std::streambuf as the actual data-area. A uage-example is here: void someFunc(int fd, unsigned bufsize) { std::buffer<char> myBuffer; myBuffer.resize(bufsize); // or std::buffer<> myBuffer(bufsize); int n = read(fd, myBuffer.data(), bufsize); // do something with the data } std::buffer is not copyable or assignable. This makes it as lightweight as possible. I have a implemenation of something like it in my own toolbox and find it very handy. What do you think about it? I think to make this buffer idea more interesting - and to distinguish it from a std::vector - it should be a read/write circular buffer. A circular buffers is fairly tricky to implement - which makes it a very good candidate for a standard library implementation. In other words, no one who needs one should have to write their own. Conceptually, however, a circular buffer is easy to describe. A "writer" client writes data into the buffer (often data received over the network) and advances a "write to" pointer to the next location in the buffer to write subsequent data. More or less concurrently with the write operations, a reader client "reads" the data in the buffer, transferring it or otherwise consuming it, and advances a "read from" pointer to indicate at which point in the buffer reading should resume. Since the buffer is fixed in size, at some point the writer will have written enough bytes to reach the end of the buffer. At this point the writer moves the "write to" pointer to start of the buffer. Assuming some data has been read, there will be free space available for writing at the start of the buffer. So the writer can write up to (but not beyond) the "read from" pointer set by the reader. By the same token, when the reader has read up to the end of the buffer, it resumes reading from the start of the buffer up to (but not beyond) the "write to" pointer. In essence the reader chases after the writer, and optimally neither lets the writer "lap" its position (and thus fill the buffer) or catch up to the writer (thus emptying the buffer) except when there is no more data to be read. A circular buffer is efficient since it minimizes copy operations. Moreover, a circular buffer should not need semaphores or other locking mechanisms to arbitrate between the reader and the writer - so an implementation should be quite portable. Note that a circular buffer could be implemented with a std::vector<char> providing the storage. In which case all that is needed is to design and implement the circular buffer interface. Here is rough sketch of how such an interface might look: class circular_buffer { public: circular_buffer( size_t size); size_t readable_buffer_size() const; const char * readable_buffer_ptr() const; size_t read( char *outBuffer, size_t len); size_t writable_buffer_size() const; char * writable_buffer_ptr(); size_t write( const char *bytes, size_t len); bool empty() const; bool full() const; ... Greg --- [ 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 Tommi Mäkitalo Guest Posted: Sun Dec 18, 2005 6:32 pm    Post subject: Re: proposal for a new class: a buffer Thorsten Ottosen wrote: Quote: Tommi Mäkitalo wrote: Nevin ":-]" Liber wrote: . I think I'd rather just use std::vector. I don't see what this offers that vector doesn't. You don't get a writable pointer to data from a std::vector. you do: if( !vec.empty() ) foo( &*vec.begin(), vec.size() ) the problem with vector is that you then initialize the data twice, quite expensive in many situations. Some proposals have been made to remedy this: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1870.html#add-set-buffer-t-size-t-to-vector-and-basic-string -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 ] Does *vec.begin() return a reference to the first element of the internal buffer or a dereferenced interator, which just have to behaves like a reference to the first element, which might well be a reference to the first element? "&*vec.begin()" as well as "&vec[0]" is ugly syntax. "vec.begin()" and "vec[0]" deal with the first element, but not with the whole data. Takinga pointer and dealing it as a pointer to a array of elements breaks logic. It is not intuitive at all. Another solution to my buffer-problem is to add a method std::vector::data(), which returns pointer to the buffer, like std::basic_string::data(). The difference to std::string would be, that the non-const data()-method will return a non-const pointer. That would make my buffer almost obsolete. There is still one issue left: when resizing a vector, the vector will copy the data, even when not currently logically empty. std::buffer (or std::basic_buffer) does not copy data, but discards old content when resized. And I don't like the mentioned proposal at all. std::vector and std::basic_string have to deal with something, they have not allocated. That is a bad idea. Tommi --- [ 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 Tommi Mäkitalo Guest Posted: Sun Dec 18, 2005 6:32 pm    Post subject: Re: proposal for a new class: a buffer Greg Herlihy wrote: Quote: Tommi Mÿÿkitalo wrote: Hi, . ÿ I think to make this buffer idea more interesting - and to distinguish it from a std::vector - it should be a read/write circular buffer. A circular buffers is fairly tricky to implement - which makes it a very good candidate for a standard library implementation. In other words, no one who needs one should have to write their own. ÿ . ÿ Greg ÿ ÿ --- [ 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 ] This might well be a adapter to std::basic_buffer. I wouldn't mix them, but it is still an interesting idea. Tommi --- [ 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 Dietmar Kuehl Guest Posted: Sun Dec 18, 2005 10:10 pm    Post subject: Re: proposal for a new class: a buffer Tommi Mäkitalo wrote: Quote: Exactly this automated acquire and release is what I get, including exception-safety. Sure. The buffer functions are not intended to be used without an appropriate wrapper. How this wrapper looks exactly, however, depends on your needs - and you managed to significantly weaken your case by pointing out that you want a buffer which, when resized, does not copy its elements. In the few cases where I need a buffer, I don't need resizing at all! ... and in all cases where I need resizing of a container, I need the elements to be copied. That is, we and I guess other interested in temporary buffers disagree of the design principles of the buffer. Quote: I need sometimes the system-call poll. This need a pointer to struct pollfd, where I can pass the file-descriptors, I am interested in. I can't use get_temporary_buffer here, because I don't want to deal with less than a specific count of elements. It is perfectly ok to get a alloc_error, when memory is exhausted. Maybe it is time to read the documentation (or, if this is bad, the holy standard) instead of insisting that what you need is the ultimate and nothing already there might be helpful in achieving your goal. The function 'get_temporary_buffer()' will return a pair of null values if it can't allocate a buffer, i.e. it signals an allocation error. Quote: It is a easy to write wrapper, but very usable. I don't think it is a argument, that it is simple to write. No, not that alone. Hands up everybody who has ever used a 'max()' or a 'min()' function! Right, nearly everybody. Only those too lazy to put their hands up or those sleeping didn't put their hands up. Hands up everybody who has every used a temporary buffer. I would expect ten, maybe twenty percent of the hands to go up on this one. Utility is another important measure. Of course, to those needing a temporary buffer it is highly useful but even those disagree on the details. The overall percentage of C++ users which would benefit from any particular buffer class design is probably below one percent. Worth the effort for something which can trivially be built upon existing facilities to serve at least all those who need a buffer? Quote: std::copy is simple to write. You think it is? I have done the exercise and I disagree with you. In fact, you cannot built a reasonable and portable 'std::copy()' unless you use TR1 facilities. "Reasonable", of course, includes that the implementation of 'std::copy()' performs well for all kinds of sequences and e.g. uses 'memmove()' where appropriate, handles segmented sequences, 'move()'s its elements, etc. Quote: And so is std::auto_ptr. Interesting... I thought it is impossible to write a conforming implementation in C++. But then, I haven't been following the discussion on this oddball to closely. Quote: Or less, This is an interesting one! Here is an exercise: write a portable 'less<void*>' without using 'std::less<void*>', of course. However, apart from this special case, there is another reason d'etre for this class template: it is used as the default in various places in the standard C++ library. Quote: min, max. These are pretty trivial and I would expect that these are indeed quite frequently used - several orders of magnitude more frequently than temporary buffers in general (which, as mentioned above, is used one or two orders of magnitude more often than any specific buffer design). Quote: The standard should have solutions for common problems. Indeed. ... and I would consider things like sockets, XML parsers, and database access facilities to be several orders of magnitudes more important than buffer classes! In fact, I would claim that buffer classes are a rather uncommon need. Quote: They might be trivial, but I like code, where I can say: Oh - here is a list<> - I know exactly, how the program deal with the data, without looking into the implementation or documentation of some individual solution. And so it would be nice to see: Oh - here the program uses std::basic_buffer<char> - the program handles memory in a exception-safe manner. You like others to do your work. Of course, you also want them to do your work the way you would do it not necessarily as they would do it. Don't we all? (so that we have more time doing the work we consider to be really important) -- <mailto:dietmar_kuehl (AT) yahoo (DOT) com> <http://www.dietmar-kuehl.de/> <http://www.eai-systems.com> - Efficient Artificial Intelligence --- [ 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: Mon Dec 19, 2005 12:51 am    Post subject: Re: proposal for a new class: a buffer Tommi Mäkitalo wrote: Quote: Thorsten Ottosen wrote: Another solution to my buffer-problem is to add a method std::vector::data(), which returns pointer to the buffer, like std::basic_string::data(). The difference to std::string would be, thatthe non-const data()-method will return a non-const pointer. That would make my buffer almost obsolete. See http://www.open-std.org/JTC1/SC22/WG21/docs/lwg-defects.html#464 Quote: There is still one issue left: when resizing a vector, the vector will copy the data, even when not currently logically empty. std::buffer (or std::basic_buffer) does not copy data, but discards old content when resized. And I don't like the mentioned proposal at all. std::vector and std::basic_string have to deal with something, they have not allocated. That is a bad idea. Well, there could be an additional requirement that the allocator must be compatible with the allocator of the string/vector. -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: Mon Dec 19, 2005 12:51 am    Post subject: Re: proposal for a new class: a buffer Tommi Mäkitalo wrote: Quote: Greg Herlihy wrote: Tommi M��kitalo wrote: Hi, . � I think to make this buffer idea more interesting - and to distinguish it from a std::vector - it should be a read/write circular buffer. A circular buffers is fairly tricky to implement - which makes it a very good candidate for a standard library implementation. In other words, no one who needs one should have to write their own. In the mean time, check out http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/libs/circular_buffer/ Already accepted into boost and will probably be part of the next release. -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 Carl Barron Guest Posted: Mon Dec 19, 2005 12:51 am    Post subject: Re: proposal for a new class: a buffer In article <do46n1$7kg$1 (AT) ulysses (DOT) news.tiscali.de>, Tommi Mˆ§kitalo <tommi (AT) maekitalo (DOT) de> wrote: Quote: Another solution to my buffer-problem is to add a method std::vector::data(), which returns pointer to the buffer, like std::basic_string::data(). The difference to std::string would be, thatthe non-const data()-method will return a non-const pointer. That would make my buffer almost obsolete. There is still one issue left: when resizing a vector, the vector will copy the data, even when not currently logically empty. std::buffer (or std::basic_buffer) does not copy data, but discards old content when resized. You have been shown how to get a T * to the data of vector<T,A>. now to resize a vector without copying [just default constructing] template <class T,class A> void buffer_resize(std::vector<T,A> &vec,typename std::vector<T,A>::size_type n) { if(n > vec.size()) { std::vector<T,A> temp; temp.swap(vec); } vec.resize(n); } does not copy, but uses T() if on entry n > vec.size() otherwise it does nothing but change the size and 'end' of the vector internally. these are normally very cheap, especially for things used to build an array for a buffer. --- [ 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  Next Page 1 of 2   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.