Menu
▾
▴
cpp-netlib-devel
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-10-19 15:56:01
|
>Dean Michael Berris wrote on Tuesday, October 19, 2010 11:26 AM >>Erik Nelson wrote: >> The copying is pretty key... if I'm sending a 50GB message, I really >> can't afford to have any copies besides the one that is the source. >> > You can do without copies if you create a message with the data in the > body already. You also don't need to use the post interface that > doesn't include the body and content-type. > >> The design itself ought not impose unnecessary runtime >> overhead in either the time or memory usage domains. If I >> understand it correctly, the asio lib doesn't require the message >> to be marshaled in memory as a contiguous string, and neither >> should netlib, in my opinion. >> > Actually, Asio does. It requires that you give it a set of buffers -- > and std::string objects qualify as good buffers -- to write out to the > sockets. The asio buffers can't be strings, right? As I understand it, asio buffers are simply pointers into contiguous memory regions, and std::string is only one of many types that hold contiguous memory regions (and is in no way preferred). http://bit.ly/dubjW5 std::strings are actually terrible buffers if you're manipulating binary objects, at least in our project. If we have a big memory region that's full of POD and want to send it across the wire, making a std::string out of it means *yet another* copy. That's why the asio buffer interface is in no way std::string-centric. > Also, if you have an std::string implementation that implements > copy-on-write semantics, then you don't pay for a 50GB copy because a > copy is pretty much just a single pointer copy anyway. Most, if not > all implementations of std::string do the COW optimization precisely > because of the overhead of copying strings around even if you don't > modify them. > I'm unconvinced that COW strings can be depended on as a central library feature- a quick Google seems to indicate otherwise. http://bit.ly/hiqqU http://bit.ly/cqpKVN I'm not sure I fully buy into the 'the-optimizer-will-cover-it-up' argument, either. The optimizer covers up very little in debug mode and a program that can't be well exercised in debug mode is hard to... debug. The speed will be slower, but having the memory footprint explode just due to the networking library is a bitter pill to swallow. > At any rate, the next version will have a message type that supports > ranges for bodies. This allows for a means of making the body of a > request a Boost.Range compatible range -- so an input_iterator range > would work fine in that version. In that case data will be pulled from > input iterator ranges, and cpp-netlib can conserve the buffers as they > come. > That sounds great! When you say that cpp-netlib will 'conserve' the ranges/buffers, what does that mean? Erik ---------------------------------------------------------------------- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing. |
|
From: Dean M. B. <mik...@gm...> - 2010-10-20 12:40:17
|
Hi Erik, I apologize for not responding fast enough to this message. Google insists that email from you is spam. :( On Tue, Oct 19, 2010 at 11:55 PM, Nelson, Erik - 2 <eri...@ba...> wrote: > >>Dean Michael Berris wrote on Tuesday, October 19, 2010 11:26 AM >> >> Actually, Asio does. It requires that you give it a set of buffers -- >> and std::string objects qualify as good buffers -- to write out to the >> sockets. > > The asio buffers can't be strings, right? They can be. > As I understand it, asio > buffers are simply pointers into contiguous memory regions, and > std::string is only one of many types that hold contiguous memory > regions (and is in no way preferred). > http://bit.ly/dubjW5 > Yup, my point wasn't that they're required to be std::string. Heck, we can use C strings but they're much more cumbersome to deal with and are just much uglier than std::string. > > std::strings are actually terrible buffers if you're manipulating > binary objects, at least in our project. Hmmm... why? Binary buffers are just thunks of memory, and you can always get the .data() of std::string objects. You can use a Boost.Array and you'd have a good enough statically sized buffer with iterator semantics, but that's not what the message objects are meant to model. Also, it's possible to implement a basic_message<> specialization that uses an internal linked-list of Boost.Array's but, well nobody's asked for that yet. Actually, it's even possible to make the body be just a range as I explained in the previous email. > If we have a big memory > region that's full of POD and want to send it across the wire, > making a std::string out of it means *yet another* copy. That's why > the asio buffer interface is in no way std::string-centric. > Sure, but Asio requires that everything you want to send *is* in memory. Whether it's a string or just a range, well as far as Asio is concerned it'd have to be in memory to be sent. cpp-netlib is built to make simple things easy really. ;) >> Also, if you have an std::string implementation that implements >> copy-on-write semantics, then you don't pay for a 50GB copy because a >> copy is pretty much just a single pointer copy anyway. Most, if not >> all implementations of std::string do the COW optimization precisely >> because of the overhead of copying strings around even if you don't >> modify them. >> > > I'm unconvinced that COW strings can be depended on as a central > library feature- a quick Google seems to indicate otherwise. > > http://bit.ly/hiqqU > http://bit.ly/cqpKVN > cpp-netlib doesn't depend on COW, but most implementations do implement std::string with COW optimizations. This means, GNU's libstdc++ has a COW string, Dinkumware (now Microsoft's STL) implements it as well. Worrying about copies only matters if it's really affecting the performance of the application. If you really need zero-copy messages, that would require that you pass in pointers to the data, and make sure that they're "live" when cpp-netlib starts requiring the data. At this point, it is entirely possible to optimize the cpp-netlib to use messages that use a single buffer, with just ranges of iterators defining which parts of the buffer is the source, destination, etc. but managing these buffers and the ranges are quite a challenge in themselves. > I'm not sure I fully buy into the 'the-optimizer-will-cover-it-up' > argument, either. The optimizer covers up very little in debug > mode and a program that can't be well exercised in debug mode is > hard to... debug. The speed will be slower, but having the > memory footprint explode just due to the networking library is > a bitter pill to swallow. > There's no "the optimizer will cover it up" here. It's just that most std::string implementations (that I know) use COW so there's nothing to worry about there. Now if you use a different string implementation, then maybe you will need to avoid it (not sure if Apache's STL implements COW for strings) or you'd implement your own message type that works well with cpp-netlib. :) You have two choices here: 1) Implement it yourself, use the concepts and make a "better" message type, and send a pull request. :) 2) Wait until I (or someone else) gets around to fixing that part of the implementation. :) >> At any rate, the next version will have a message type that supports >> ranges for bodies. This allows for a means of making the body of a >> request a Boost.Range compatible range -- so an input_iterator range >> would work fine in that version. In that case data will be pulled from >> input iterator ranges, and cpp-netlib can conserve the buffers as they >> come. >> > > That sounds great! When you say that cpp-netlib will 'conserve' the > ranges/buffers, what does that mean? > That means, only when data is going to be sent will data be "linearized" to a fixed-size buffer that gets re-used every time a write is going to be attempted. Asio has the async_read and async_write functions that take non-mutable buffers, and at this time ranges don't count as buffers. This is going to be helpful in the case when files are going to be served, and the possibility of having mmap'ed files/buffers can be expressed as a range of iterators. The data can even be non-linear, it can be a range of joined iterators, it can be a range of function input iterators, but the data will be linearized still to a fixed-size buffer for Asio's consumption. Until Asio has a way of dealing with Boost.Ranges on its own, the linearization will have to be done by cpp-netlib. At the worst case, there will be a fixed overhead which will be caused by a buffer for each connection. HTH (Also, I hope Google doesn't treat your mail as Spam again) -- Dean Michael Berris deanberris.com |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-10-20 15:26:54
|
>Dean Michael Berris wrote on Wednesday, October 20, 2010 8:40 AM >> Erik Nelson wrote: >> std::strings are actually terrible buffers if you're manipulating >> binary objects, at least in our project. > > Hmmm... why? Binary buffers are just thunks of memory, and you can > always get the .data() of std::string objects. > Think about what you'd have to do to store and manipulate an array of doubles in a string, referencing it through the .data() member. vector<double> seems like a much more natural fit >> If we have a big memory >> region that's full of POD and want to send it across the wire, >> making a std::string out of it means *yet another* copy. That's why >> the asio buffer interface is in no way std::string-centric. > > Sure, but Asio requires that everything you want to send *is* in > memory. Whether it's a string or just a range, well as far as Asio is > concerned it'd have to be in memory to be sent. cpp-netlib is built to > make simple things easy really. ;) It's fine to have it in memory... just not copies of it. Simple things *should* be easy. I'm not sure that means there needs to be multiple copies made of the payload. > > If you really need zero-copy messages, that would require that you > pass in pointers to the data, and make sure that they're "live" when > cpp-netlib starts requiring the data. That's how asio works, right? The buffers are pointers, and the app needs to make sure they have not been invalidated; > > You have two choices here: > > 1) Implement it yourself, use the concepts and make a "better" message > type, and send a pull request. :) > > 2) Wait until I (or someone else) gets around to fixing that part of > the implementation. :) > Understood, just wanted to throw the issue into the design discussion. >> >> That sounds great! When you say that cpp-netlib will 'conserve' the >> ranges/buffers, what does that mean? >> > That means, only when data is going to be sent will data be > "linearized" to a fixed-size buffer that gets re-used every time a > write is going to be attempted. Asio has the async_read and > async_write functions that take non-mutable buffers, and at this time > ranges don't count as buffers. > > This is going to be helpful in the case when files are going to be > served, and the possibility of having mmap'ed files/buffers can be > expressed as a range of iterators. The data can even be non-linear, it > can be a range of joined iterators, it can be a range of function > input iterators, but the data will be linearized still to a fixed-size > buffer for Asio's consumption. > Does asio require linearized data? > Until Asio has a way of dealing with Boost.Ranges on its own, the > linearization will have to be done by cpp-netlib. At the worst case, > there will be a fixed overhead which will be caused by a buffer for > each connection. > I think we might just disagree on this point, but, in my view, this linearization is a core problem since it will cause a complete memory copy of anything that is sent (unless I'm missing something). That's fine if you're serving up 1 MB of something, but a problem if you're serving up 50 GB of something. This design will preclude a typical Windows 32-bit program from serving files larger than 1 or 2 GB, right? Is Boost.Range on the roadmap for asio? Erik ---------------------------------------------------------------------- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing. |
|
From: Dean M. B. <mik...@gm...> - 2010-10-21 04:58:55
|
On Wed, Oct 20, 2010 at 11:26 PM, Nelson, Erik - 2 <eri...@ba...> wrote: >>Dean Michael Berris wrote on Wednesday, October 20, 2010 8:40 AM > >>> Erik Nelson wrote: >>> std::strings are actually terrible buffers if you're manipulating >>> binary objects, at least in our project. >> >> Hmmm... why? Binary buffers are just thunks of memory, and you can >> always get the .data() of std::string objects. >> > > Think about what you'd have to do to store and manipulate an array > of doubles in a string, referencing it through the .data() member. > vector<double> seems like a much more natural fit > You can do that, you just have to re-interpret the pointer from a char * to a double *. Alignment issues aside, this is possible to do. Besides, you can't send a vector<double> through a socket, you need a char* so you're going to reinterpret the other way around. >>> If we have a big memory >>> region that's full of POD and want to send it across the wire, >>> making a std::string out of it means *yet another* copy. That's why >>> the asio buffer interface is in no way std::string-centric. >> >> Sure, but Asio requires that everything you want to send *is* in >> memory. Whether it's a string or just a range, well as far as Asio is >> concerned it'd have to be in memory to be sent. cpp-netlib is built to >> make simple things easy really. ;) > > It's fine to have it in memory... just not copies of it. > Simple things *should* be easy. I'm not sure that means there needs > to be multiple copies made of the payload. > The easiest thing that can possibly work is to make copies of the data to help with threading (as already mentioned before) and to delineate where the application's data ends and where cpp-netlib's data starts. >> >> If you really need zero-copy messages, that would require that you >> pass in pointers to the data, and make sure that they're "live" when >> cpp-netlib starts requiring the data. > > That's how asio works, right? The buffers are pointers, and the app > needs to make sure they have not been invalidated; > Asio needs a char * buffer last I checked. Actually, it's generic on the buffer types, but there is a concept of a ConstBuffer in Asio that requires certain things. >> >> You have two choices here: >> >> 1) Implement it yourself, use the concepts and make a "better" message >> type, and send a pull request. :) >> >> 2) Wait until I (or someone else) gets around to fixing that part of >> the implementation. :) >> > > Understood, just wanted to throw the issue into the design discussion. > 1 is easy to do as it is now, it's even possible to make the request objects just POD types -- which I intend to do also -- to allow for use cases where they're just data holders. >>> >>> That sounds great! When you say that cpp-netlib will 'conserve' the >>> ranges/buffers, what does that mean? >>> > >> That means, only when data is going to be sent will data be >> "linearized" to a fixed-size buffer that gets re-used every time a >> write is going to be attempted. Asio has the async_read and >> async_write functions that take non-mutable buffers, and at this time >> ranges don't count as buffers. >> >> This is going to be helpful in the case when files are going to be >> served, and the possibility of having mmap'ed files/buffers can be >> expressed as a range of iterators. The data can even be non-linear, it >> can be a range of joined iterators, it can be a range of function >> input iterators, but the data will be linearized still to a fixed-size >> buffer for Asio's consumption. >> > > Does asio require linearized data? > Yep, it needs the data to be a contiguous thunk of memory. >> Until Asio has a way of dealing with Boost.Ranges on its own, the >> linearization will have to be done by cpp-netlib. At the worst case, >> there will be a fixed overhead which will be caused by a buffer for >> each connection. >> > > I think we might just disagree on this point, but, in my view, this > linearization is a core problem since it will cause a complete > memory copy of anything that is sent (unless I'm missing something). Well, unless you just keep re-using a buffer of 4kb over and over -- then the overhead will be a fixed 4kb of memory. It doesn't matter how large your data range is, it just matters that data is sent through the socket 4kb at a time. This means you only ever linearize 4kb of memory every time. > That's fine if you're serving up 1 MB of something, but a problem > if you're serving up 50 GB of something. This design will preclude > a typical Windows 32-bit program from serving files larger than > 1 or 2 GB, right? > Nope, this won't. Like I point out above, writing just 4kb of data (a default page's size in Linux) at a time will only linearize 4kb of data for every write. You can serve however large file you want. Also, the server will not have this problem in 0.8 because I will allow for handlers to do the writing asynchronously -- so the handlers can figure out how much data it wants to serve as chunks at a time, and they get a chance to write it out on their own. On the client side, having a message type that is a POD and supports ranges allows for more demanding applications (that serve huge amounts of data) to supply ranges instead, which the client will linearize into fixed-sized buffers to be written for every write. > Is Boost.Range on the roadmap for asio? > I don't think so, no. It's trivial to linearize ranges into a Boost.Array anyway, and hand Boost.Asio the Boost.Array pointer and the size of the data in the Boost.Array to write out to the socket. -- Dean Michael Berris deanberris.com |
|
From: Kim G. <kim...@gm...> - 2010-10-20 18:41:15
|
Hi Dean, On Wed, Oct 20, 2010 at 14:39, Dean Michael Berris <mik...@gm...> wrote: >> >> >> I'm unconvinced that COW strings can be depended on as a central >> library feature- a quick Google seems to indicate otherwise. >> >> http://bit.ly/hiqqU >> http://bit.ly/cqpKVN >> > > cpp-netlib doesn't depend on COW, but most implementations do > implement std::string with COW optimizations. This means, GNU's > libstdc++ has a COW string, Dinkumware (now Microsoft's STL) > implements it as well. Worrying about copies only matters if it's > really affecting the performance of the application. Microsoft's STL as of VS2008 doesn't use COW, it uses the small-string optimization. Not sure if they went (back?) to COW in 2010, but I doubt it. LLVM has an interesting sub-project implementing a standard library from scratch, and one of the decisions they mention in the overview is using small string optimization over COW, as if it was a plain truth; http://libcxx.llvm.org/. So, I think there's merit to not expecting COW from std::string. - Kim |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-10-20 19:01:40
|
> Kim Gräsman wrote on Wednesday October 20, 2010 2:41 PM > Microsoft's STL as of VS2008 doesn't use COW, it uses the small-string > optimization. Not sure if they went (back?) to COW in 2010, but I > doubt it. > > LLVM has an interesting sub-project implementing a standard library > from scratch, and one of the decisions they mention in the overview is > using small string optimization over COW, as if it was a plain truth; > http://libcxx.llvm.org/. > > So, I think there's merit to not expecting COW from std::string. > STLPort (ships with Sun C++ compilers) doesn't use COW, either. http://stlport.sourceforge.net/ and the links I put in a previous post http://bit.ly/hiqqU http://bit.ly/cqpKVN have indications in the discussions that gcc may move away from COW in the future. Visual Studio 6.0 had well-known thread-safety bugs in its COW std::string implementation, and was the last version of MSVC to use COW, according to my understanding. http://support.microsoft.com/kb/813810 http://www.eggheadcafe.com/software/aspnet/32308437/-thread-safe-stl-for-vc60.aspx Erik ---------------------------------------------------------------------- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing. |
|
From: Dean M. B. <mik...@gm...> - 2010-10-21 05:00:59
|
On Thu, Oct 21, 2010 at 3:01 AM, Nelson, Erik - 2 <eri...@ba...> wrote: >> Kim Gräsman wrote on Wednesday October 20, 2010 2:41 PM > >> Microsoft's STL as of VS2008 doesn't use COW, it uses the small-string >> optimization. Not sure if they went (back?) to COW in 2010, but I >> doubt it. >> >> LLVM has an interesting sub-project implementing a standard library >> from scratch, and one of the decisions they mention in the overview is >> using small string optimization over COW, as if it was a plain truth; >> http://libcxx.llvm.org/. >> >> So, I think there's merit to not expecting COW from std::string. >> > > STLPort (ships with Sun C++ compilers) doesn't use COW, either. > > http://stlport.sourceforge.net/ > > and the links I put in a previous post > > http://bit.ly/hiqqU > http://bit.ly/cqpKVN > > have indications in the discussions that gcc may move away from COW > in the future. > Yep. > Visual Studio 6.0 had well-known thread-safety bugs in its COW > std::string implementation, and was the last version of MSVC to > use COW, according to my understanding. > > http://support.microsoft.com/kb/813810 > http://www.eggheadcafe.com/software/aspnet/32308437/-thread-safe-stl-for-vc60.aspx > Ah, I stand corrected then. :) That's good to know, I'll fix that most probably in 0.9 -- unless someone else beats me to it and sends a pull request for 0.8-devel. :) -- Dean Michael Berris deanberris.com |
|
From: Dean M. B. <mik...@gm...> - 2010-10-21 04:34:44
|
On Thu, Oct 21, 2010 at 2:41 AM, Kim Gräsman <kim...@gm...> wrote: > Hi Dean, > > On Wed, Oct 20, 2010 at 14:39, Dean Michael Berris > <mik...@gm...> wrote: >>> >>> >>> I'm unconvinced that COW strings can be depended on as a central >>> library feature- a quick Google seems to indicate otherwise. >>> >>> http://bit.ly/hiqqU >>> http://bit.ly/cqpKVN >>> >> >> cpp-netlib doesn't depend on COW, but most implementations do >> implement std::string with COW optimizations. This means, GNU's >> libstdc++ has a COW string, Dinkumware (now Microsoft's STL) >> implements it as well. Worrying about copies only matters if it's >> really affecting the performance of the application. > > Microsoft's STL as of VS2008 doesn't use COW, it uses the small-string > optimization. Not sure if they went (back?) to COW in 2010, but I > doubt it. > Oh, then my info on MS STL would still be pre-2008. Thanks for the update. I learn something new everyday. :D > LLVM has an interesting sub-project implementing a standard library > from scratch, and one of the decisions they mention in the overview is > using small string optimization over COW, as if it was a plain truth; > http://libcxx.llvm.org/. > Yeah, I've been following that too. That's interesting, although that will be a C++0x standard library. I don't want to wait for C++0x to come along to make my life a lot easier in implementing cpp-netlib. :D > So, I think there's merit to not expecting COW from std::string. > Yup, but I haven't been writing cpp-netlib to expect COW. I just think that removing copies can be done later on. ;) -- Dean Michael Berris deanberris.com |
|
From: Kim G. <kim...@gm...> - 2010-10-21 19:18:00
|
Hi Dean, On Thu, Oct 21, 2010 at 06:34, Dean Michael Berris <mik...@gm...> wrote: > >> So, I think there's merit to not expecting COW from std::string. >> > > Yup, but I haven't been writing cpp-netlib to expect COW. I just think > that removing copies can be done later on. ;) Right, I just wanted to make sure you were aware of the reputation of std::string with COW. It's not great ;-) That said, maybe it's not such a bad idea. Multiple threads make it harder to get right, but perhaps not intrinsically worse than heap allocation + copy. I'll have to mull on that for a while. Cheers, - Kim |
|
From: Dean M. B. <mik...@gm...> - 2010-10-22 05:51:00
|
On Fri, Oct 22, 2010 at 3:17 AM, Kim Gräsman <kim...@gm...> wrote: > Hi Dean, > > On Thu, Oct 21, 2010 at 06:34, Dean Michael Berris > <mik...@gm...> wrote: >> >>> So, I think there's merit to not expecting COW from std::string. >>> >> >> Yup, but I haven't been writing cpp-netlib to expect COW. I just think >> that removing copies can be done later on. ;) > > Right, I just wanted to make sure you were aware of the reputation of > std::string with COW. It's not great ;-) > Yeah, I've been bitten by those bugs too. :D > That said, maybe it's not such a bad idea. Multiple threads make it > harder to get right, but perhaps not intrinsically worse than heap > allocation + copy. I'll have to mull on that for a while. > Yup, it's no worse than an allocation + copy. You can't do the allocation and copy atomically either, which means the overhead of locking and things like that may be higher than the cost of COW. Someday when my development machine, time, and other things permit, I might work on an immutable string class -- similar to what the D programming language has -- as a replacement to std::string. Although std::string is the standard, I don't mind writing a better string class at some point that "does the right thing". Alas, I'm dealing with the SNAFU that is upgrading Ubuntu 10.04 to 10.10. nvidia+xorg-1.9 do not play nice yet. :( -- Dean Michael Berris deanberris.com |
|
From: Kim G. <kim...@gm...> - 2010-10-22 05:59:57
|
Hi Dean, On Fri, Oct 22, 2010 at 07:50, Dean Michael Berris <mik...@gm...> wrote: > > Someday when my development machine, time, and other things permit, I > might work on an immutable string class -- similar to what the D > programming language has -- as a replacement to std::string. Although > std::string is the standard, I don't mind writing a better string > class at some point that "does the right thing". I went looking a couple of months ago and found two -- one STL-style and one less idiomatic: - http://conststring.sourceforge.net/ - http://www.codeproject.com/KB/string/fix_str.aspx Maybe you can get some ideas from there. Cheers, - Kim |
|
From: Dean M. B. <mik...@gm...> - 2010-10-24 05:15:45
|
Hi Kim, Sorry it took me a while to respond, I've been wrestling with OS upgrade issues in my quest to try out GCC 4.5. See some of my thoughts below. On Fri, Oct 22, 2010 at 1:59 PM, Kim Gräsman <kim...@gm...> wrote: > Hi Dean, > > On Fri, Oct 22, 2010 at 07:50, Dean Michael Berris > <mik...@gm...> wrote: >> >> Someday when my development machine, time, and other things permit, I >> might work on an immutable string class -- similar to what the D >> programming language has -- as a replacement to std::string. Although >> std::string is the standard, I don't mind writing a better string >> class at some point that "does the right thing". > > I went looking a couple of months ago and found two -- one STL-style > and one less idiomatic: > Cool, thanks! > - http://conststring.sourceforge.net/ This one looks interesting. I wonder if it uses a shared_ptr underneath though. I'll take a look at that implementation to see if it fits with what I was thinking about. > - http://www.codeproject.com/KB/string/fix_str.aspx > Yeah, this one isn't so idiomatic. I like the first one better. > Maybe you can get some ideas from there. > Definitely, thanks for the pointers! :) -- Dean Michael Berris deanberris.com |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X