| comp.lang.c++@googlegroups.com | Google Groups |  |
| Unsure why you received this message? You previously subscribed to digests from this group, but we haven't been sending them for a while. We fixed that, but if you don't want to get these messages, send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
- Onwards and upwards - 5 Updates
- C++ and Web Services (OT maybe?) - 4 Updates
- "JetBrains CLion C++ IDE First Impressions" - 1 Update
- Why is this - 1 Update
- Alternative? - 14 Updates
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 01 06:13PM +0100 > is the smallest, is meant to be very portable. The > library, front tier and generated code are meant to > be highly portable, and I believe they are. Using Winsock doesn't sound very portable to me. /Flibble |
| woodbrian77@gmail.com: Oct 01 06:57PM -0700 On Wednesday, October 1, 2014 12:13:54 PM UTC-5, Mr Flibble wrote: > Using Winsock doesn't sound very portable to me. I believe the asio library also uses Winsock on Windows. Brian Ebenezer Enterprises http://webEbenezer.net |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 02 06:42PM +0100 >> Using Winsock doesn't sound very portable to me. > I believe the asio library also uses Winsock on > Windows. Of course it does and std::thread will also use a Windows thread on Windows so what is your point? boost.asio hides winsock from you so you can write portable code. Another reason to use boost.asio is that it is likely that it will go into next major revision of C++. /Flibble |
| woodbrian77@gmail.com: Oct 02 11:52AM -0700 On Thursday, October 2, 2014 12:42:54 PM UTC-5, Mr Flibble wrote: > Windows so what is your point? boost.asio hides winsock from you so you > can write portable code. Another reason to use boost.asio is that it is > likely that it will go into next major revision of C++. I don't consider asio to be beyond competition and some of what's in the standard isn't very good. Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 02 08:55PM +0100 >> likely that it will go into next major revision of C++. > I don't consider asio to be beyond competition and > some of what's in the standard isn't very good. Stop reinventing a not very good wheel mate. Use boost.asio; abstract it if you like (I do). /Flibble |
| Christopher Pisz <nospam@notanaddress.com>: Oct 01 06:44PM -0500 On 10/1/2014 5:19 PM, Jorgen Grahn wrote: >> C++ clients using web services. > Out of curiosity, what's a C++ client? Clients normally want to talk > to servers, not the other way around ... True... Wording. I want to talk to them and so do others. > Or a more precise question: what is your code doing, when it attracts > web service people? What area are you working in? Retrieving data from another system's database. Making two pieces of software, developed separately, usually using a different technology, share information. I can't really be more specific than that or the bosses might get upset :P Up to now, I've either made my own protocol and handed it to another company's team and went the way of just making a plain old socket on some specified port, or relied on flat file exports and the like. |
| Ian Collins <ian-news@hotmail.com>: Oct 02 12:50PM +1300 Christopher Pisz wrote: > define my own protocol or XML schema. I understand web services are just > REST and SOAP. Where would we start in C++ land without handy IDE code > generators and frameworks those .NET guys have? SOAP is just XML, so all you really need is a decent XML library. -- Ian Collins |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 02 02:01PM On Wed, 2014-10-01, Christopher Pisz wrote: > software, developed separately, usually using a different technology, > share information. I can't really be more specific than that or the > bosses might get upset :P Understood -- I realized that could be a limitation. > Up to now, I've either made my own protocol and handed it to another > company's team and went the way of just making a plain old socket on > some specified port, or relied on flat file exports and the like. I've done that too. Although I see it as a partial failure -- IMHO it's better if you can stick to designing text file formats and do Unix pipelines, perhaps tunneled over ssh. But that might very well not be feasible in your environment: it just happenes to often work in mine. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 02 06:44PM +0100 On 02/10/2014 00:50, Ian Collins wrote: >> REST and SOAP. Where would we start in C++ land without handy IDE code >> generators and frameworks those .NET guys have? > SOAP is just XML, so all you really need is a decent XML library. My C++ XML library "NoFussXML" is the fastest! :) /Flibble |
| "AP" <unixpronospam@verizon.net>: Oct 02 12:18PM -0400 "Rick C. Hodgin" wrote in message news:220ff353-0f27-44de-ad4d-32281ee42b2c@googlegroups.com... >Think about what this means... <snip> You choose to worship a human being. You choose to spread false dogma, to misinterpret and outright falsify the Bible, to paint the very idea of faith as something repugnant and delusional. I'm sure your intentions are good, but if you consider the outcome, they are nothing but evil whichever way you look at it. The crux of your message seems to serve one purpose : to take a natural human impulse yearning for God and spirituality and replace it with worship of a man - and you must resort to blackmail and bribery - all that nonsense with your versions of hell and heaven; high pressure sales tactics - salvation today, tomorrow is too late; forgeries abound. You build a huge strawman out of the so called Old Testament before taking it apart - relying on "translations" that are anything but. And on top of it all, the false piety of nitpicking on software titles is nothing short of psychotic !! Before too late, put in an effort and do some research into the original sources. It's never too late. And you shouldn't do it because of some cartoonish flames, but because it seems that at some point, your soul was actually drawn to the Truth - the kind that takes an effort to uncover. --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| scott@slp53.sl.home (Scott Lurndal): Oct 02 02:38PM >ned types would be a better choice, but back then with the segmented archit= >ecture used for the popular x86 processors then, I would also have chosen a= >n unsigned value. std::vector was introduced almost a decade after the i386 added flat addressing modes and every relevent operating system switched away from segmentation, even Windows. While C compiled for for the PDP-11 segmented architecture, it wasn't designed around a segmented architecture. And there was never a unix system that used x86 segments (other than the obligitory CS/DS/GDT required to use linear addressing on x86). I generally use unsigned for everything, unless negative values are legal in context. For example, if I'm representing a physical or virtual address, the type must be unsigned; size_t is the correct type for counts of objects, bytes, etc. ssize_t should only be used for return values from certain system calls that return -1 on error (IIRC, ssize_t was originally only defined over [-1...MAXINT]). |
| MikeCopeland <mrc2323@cox.net>: Oct 01 03:36PM -0700 I'm scanning a std::vector and deleting certain elements as I traverse the vector. Help mI've received here suggest that I must use a scalar index for this process, even though I'm using an iterator to traverse the vector. I know that I can use the "itertor-vector,begin()" comoutation to obtain the specific index, but this seems awkward. Is there an STL function that does this, or is there a cleaner way? Please advise. TIA --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com |
| Ian Collins <ian-news@hotmail.com>: Oct 02 11:44AM +1300 MikeCopeland wrote: > traverse the vector. Help mI've received here suggest that I must use a > scalar index for this process, even though I'm using an iterator to > traverse the vector. What made you reach that conclusion? -- Ian Collins |
| Scott Neugroschl <no.spam@its.invalid>: Oct 01 03:49PM -0700 On 10/1/2014 3:36 PM, MikeCopeland wrote: > I know that I can use the "itertor-vector,begin()" comoutation to > obtain the specific index, but this seems awkward. Is there an STL > function that does this, or is there a cleaner way? Please advise. TIA Why do you need an index? What's wrong with... std::vector<T> v; std::vector<T>::iterator it = v.begin(); while (it != v.end()) { if (*it matches criteria) it = std::erase(*it); // per C++03 23.1.1/7 else ++it; } |
| Scott Neugroschl <no.spam@its.invalid>: Oct 01 03:50PM -0700 On 10/1/2014 3:49 PM, Scott Neugroschl wrote: > while (it != v.end()) > { > if (*it matches criteria) // CORRECTION HERE it = v.erase(it); // per C++03 23.1.1/7 > else > ++it; > } Oops. typo. See correction above. |
| Christopher Pisz <nospam@notanaddress.com>: Oct 01 06:36PM -0500 On 10/1/2014 5:50 PM, Scott Neugroschl wrote: >> ++it; >> } > Oops. typo. See correction above. Not enough info given really. If you expect to go front to back, and delete multiple elements, then that's probably the best way. You can also look at std::find_if in <algorithm>. |
| Victor Bazarov <v.bazarov@comcast.invalid>: Oct 01 07:44PM -0400 On 10/1/2014 7:36 PM, Christopher Pisz wrote: > Not enough info given really. If you expect to go front to back, and > delete multiple elements, then that's probably the best way. You can > also look at std::find_if in <algorithm>. You probably meant std::remove_if ... V -- I do not respond to top-posted replies, please don't ask |
| Christopher Pisz <nospam@notanaddress.com>: Oct 01 06:48PM -0500 On 10/1/2014 6:44 PM, Victor Bazarov wrote: >>>> On 10/1/2014 3:36 PM, MikeCopeland wrote: >>>>> I'm scanning a std::vector and deleting certain elements as I >>>>> traverse the vector. SNIP >> also look at std::find_if in <algorithm>. > You probably meant std::remove_if ... > V Even better! |
| David Harmon <source@netcom.com>: Oct 01 09:11PM -0700 On Wed, 01 Oct 2014 19:44:18 -0400 in comp.lang.c++, Victor Bazarov <v.bazarov@comcast.invalid> wrote, >You probably meant std::remove_if ... After you figure out how to make it work. |
| peter koch <peter.koch.larsen@gmail.com>: Oct 02 04:19AM -0700 Den torsdag den 2. oktober 2014 06.13.17 UTC+2 skrev David Harmon: > <v.bazarov@comcast.invalid> wrote, > >You probably meant std::remove_if ... > After you figure out how to make it work. Yes. This can be tricky. It requires that you read the documentation. Actually, this is only partly sarcastic. You must be aware that remove_if does not remove anything, so it might be a bad name although I am pressed to find a better one. /Peter |
| Victor Bazarov <v.bazarov@comcast.invalid>: Oct 02 08:19AM -0400 On 10/2/2014 7:19 AM, peter koch wrote: > documentation. Actually, this is only partly sarcastic. You must be > aware that remove_if does not remove anything, so it might be a bad > name although I am pressed to find a better one. std::rearrange_if ? (I'm for that one) std::preerase_if ? (worse, yet suggestive) After all, all that algorithm does is to *mutate* the sequence in a way that makes it easier to trim/excise the specific elements. V -- I do not respond to top-posted replies, please don't ask |
| Juha Nieminen <nospam@thanks.invalid>: Oct 02 01:25PM > Is there an STL > function that does this, or is there a cleaner way? Please advise. TIA std::remove_if(). It has the advantage of running in O(n) time rather than in O(n^2) time like your solution. (Note that you need to resize the vector after running std::remove_if because it doesn't actually change its size.) --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 02 02:05PM On Wed, 2014-10-01, MikeCopeland wrote: > traverse the vector. Help mI've received here suggest that I must use a > scalar index for this process, even though I'm using an iterator to > traverse the vector. Several people recommended std::remove_if() or variants as the right solution. There's no indexing there! At least none that you have to worry about. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| peter koch <peter.koch.larsen@gmail.com>: Oct 02 07:21AM -0700 Den torsdag den 2. oktober 2014 14.20.12 UTC+2 skrev Victor Bazarov: > > aware that remove_if does not remove anything, so it might be a bad > > name although I am pressed to find a better one. > std::rearrange_if ? (I'm for that one) That suggests that the algorithm preserves the elements of the vector - something aka partition. > std::preerase_if ? (worse, yet suggestive) Hmmm... better. Perhaps prepare_to_erase_if? Or arrange_for_erasure_if. We just love long names. ;-) > After all, all that algorithm does is to *mutate* the sequence in a way > that makes it easier to trim/excise the specific elements. No - it does not necesarrily mutate. What happens to the erasable elements is unspecified. Come to think about it, I believe we should keep the name. If not for anything else then because it marks the beginning of a tradition which has continued with names like std::move and std::forward. Even if std::move moves nothing and std::forward does not forward, the names are clear enough that you esily understand what they do. /Peter |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 02 02:24PM On Thu, 2014-10-02, peter koch wrote: > Actually, this is only partly sarcastic. You must be aware that > remove_if does not remove anything, so it might be a bad name although > I am pressed to find a better one. std::last_judgement() maybe? The good go to Heaven, the bad to Hell? /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment