- extracting substrings from a string - 3 Updates
- How do you do something like this? - 3 Updates
- Jesus Christ The Bastard - 9 Updates
- readsome() vs. fread() - 10 Updates
| porparek@gmail.com: Feb 28 11:24AM -0800 Hi, I would like to parse the following string to extract the following parts: std::string unsername; std::string host; int port; std::string db; protocol://[username:password@]host[:port]/db [...] designates the optional parts My algorithm uses std::string::find_first_of heavily. In fact I don't like it. It doesn't look clean. I wonder whether there is an efficient way of doing this using only a standard C++ (11+ allowed) or boost (C++ standard preferred) Idealy would be to have only a single pass through the string. Could you please give me some hints or provide some kind of code snippet. Thanks in advance. |
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 28 09:28PM +0200 > My algorithm uses std::string::find_first_of heavily. In fact I don't like it. It doesn't look clean. > I wonder whether there is an efficient way of doing this using only a standard C++ (11+ allowed) or boost (C++ standard preferred) > Idealy would be to have only a single pass through the string. Take a look at <regex>: http://en.cppreference.com/w/cpp/regex |
| legalize+jeeves@mail.xmission.com (Richard): Feb 28 09:37PM [Please do not mail me a copy of your followup] porparek@gmail.com spake the secret code >I would like to parse the following string to extract the following parts: ^^^^^ This is the key to your whole question. When you need to parse something, use a parser :). Options are: 0) Use an existing library 1) find a regex pattern to match your input 2) write a parser by hand 3) use a parser library 4) use a parser generator My opinions on pros/cons of the above options: 0) Recognize that you're parsing a URL. Lots of people have already solved this problem, so look for a library that already does this and use it. Google "c++ url parser". 1) For simple things, a regex is fine, but I would put this problem as too complicated. The regex is going to look really ugly considering all the optional parts. 2) Writing a parser by hand for this shouldn't be too hard. In fact, one shows up on stackoverflow from the above google search. 3) You can use Boost.Spirit to write parsers in a pretty succinct manner. They are fast. However, other people unfamiliar with Boost.Spirit may find your code hard to understand. If you're comfortable with Spirit, this is an easy way to get a high quality parser. If you're uncomfortable with Spirit (or your team is uncomfortable), then a hand written parser may be better. 4) You could use YACC to generate a parser for this structure. However, IMO it would be overkill. Debugging through YACC parsers is pretty disgusting IMO. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| David Brown <david.brown@hesbynett.no>: Feb 28 09:59AM +0100 On 27/02/18 23:07, Real Troll wrote: >> thrd_sleep(&(struct timespec){.tv_sec=1}, NULL); // sleep 1 sec >> printf("Time: %s", ctime(&(time_t){time(NULL)})); >> } Works fine for me with gcc. Did you remember to use "-std=c11", or a gcc version new enough to have "-std=gnu11" as the default? Did you use a new enough gcc? (I think 4.9 is needed.) Did you use a library with the right support (not a Windows gcc version that uses MS's old and limited C libraries)? |
| Keith Thompson <kst-u@mib.org>: Feb 28 10:03AM -0800 > a new enough gcc? (I think 4.9 is needed.) Did you use a library with > the right support (not a Windows gcc version that uses MS's old and > limited C libraries)? On Linux systems, gcc typically uses GNU libc by default, and GNU libc doesn't support <threads.h>. Specifying -std=... doesn't help. I don't think Visual Studio supports it either. (<threads.h> is optional, so this doesn't mean these implementations are non-conforming as long as they predefine __STDC_NO_THREADS__.) On Debian-based systems, you can install an alternative C library, MUSL, which does support <threads.h>. You have to use a wrapper called musl-gcc to compile with it. -- Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister" |
| David Brown <david.brown@hesbynett.no>: Feb 28 10:35PM +0100 On 28/02/18 19:03, Keith Thompson wrote: > On Debian-based systems, you can install an alternative C library, > MUSL, which does support <threads.h>. You have to use a wrapper > called musl-gcc to compile with it. Oh, you are correct. The gcc I tested was using MUSL. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Feb 28 07:15AM -0800 On Sunday, February 4, 2018 at 12:28:52 PM UTC-5, [Leigh Johnston pretending to be Rick C. Hodgin] wrote: > assembly of the LORD." -- Deuteronomy 23:2 > Jesus Christ was himself illegitimate as his Father was not married to > the whore Mary. I came across this today and wanted to address this point. There are various teachings out there which state something like what you say above, or that Mary was raped and therefore God is a tyrant and a brute ... but please know the work that is in play in the world regarding the Bible. It's being targeted by forces bent on hiding what it teaches, and for a very good reason ... because it is the word of God and it speaks the truth. Those forces do not want people to know the truth because the truth WILL set them free: Begins at 24:56: https://www.youtube.com/watch?v=tR_7tkC6ZiA&t=24m56s "The NIV is now owned by (Rupert Murdoch) a secular publishing company. So it's outside the hands of the Christian community. And as a matter of fact it's with something called Harper San Francisco, which produces very very blasphemous books about Jesus Christ saying He was a mystic, and that His mother was raped and just horrible horrible things..." ----- The facts: An angel appeared to Mary to proclaim the good news. Pay special attention to verse 38 where Mary gives her consent to that which the angel has proclaimed: https://www.biblegateway.com/passage/?search=Luke+1%3A26-38&version=KJV 26 And in the sixth month the angel Gabriel was sent from God unto a city of Galilee, named Nazareth, 27 To a virgin espoused to a man whose name was Joseph, of the house of David; and the virgin's name was Mary. 28 And the angel came in unto her, and said, Hail, thou that art highly favoured, the Lord is with thee: blessed art thou among women. 29 And when she saw him, she was troubled at his saying, and cast in her mind what manner of salutation this should be. ==> 30 And the angel said unto her, Fear not, Mary: for thou hast found favour with God. 31 And, behold, thou shalt conceive in thy womb, and bring forth a son, and shalt call his name Jesus. 32 He shall be great, and shall be called the Son of the Highest: and the Lord God shall give unto him the throne of his father David: 33 And he shall reign over the house of Jacob for ever; and of his kingdom there shall be no end. 34 Then said Mary unto the angel, How shall this be, seeing I know not a man? 35 And the angel answered and said unto her, The Holy Ghost shall come upon thee, and the power of the Highest shall overshadow thee: therefore also that holy thing which shall be born of thee shall be called the Son of God. 36 And, behold, thy cousin Elisabeth, she hath also conceived a son in her old age: and this is the sixth month with her, who was called barren. 37 For with God nothing shall be impossible. ==> 38 And Mary said, Behold the handmaid of the Lord; be it unto me according to thy word. And the angel departed from her. This declaration followed a prophesy given by God formerly, one of miraculous construct, one which would demonstrate that Jesus, born of a virgin truly was the Son of God, for virgins cannot have children, save by miracles given them directly by God: https://www.biblegateway.com/passage/?search=Isaiah+7%3A14&version=KJV 14 Therefore the Lord himself shall give you a sign; Behold, a virgin shall conceive, and bear a son, and shall call his name Immanuel. The name "Immanuel" in Hebrew means "God with us": http://biblehub.com/text/isaiah/7-14.htm http://biblehub.com/hebrew/6005.htm ----- The truth is stronger than fiction and lies. It also has the unique trait of being the only thing that's correct and foundational upon which to build. If any of you want to know the truth, seek it out. When it comes to finding God, and knowing who you are, what sin is, who He is, and why you need Him in your life ... you will find it ... when you seek it with all your heart. -- Rick C. Hodgin |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Feb 28 04:27PM On 28/02/2018 15:15, Rick C. Hodgin wrote: > If any of you want to know the truth, seek it out. When it comes to finding > God, and knowing who you are, what sin is, who He is, and why you need Him in > your life ... you will find it ... when you seek it with all your heart. Mary giving her consent doesn't change anything regarding Jesus Christ's legitimacy: Mary was not married to God ergo Jesus Christ is still a bastard. But of course as Jesus is also the Father, Jesus fucked himself to give birth to himself which makes perfect sense and isn't absurd in the slightest. #atheism -- Thank you, Rick C. Hodgin |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Feb 28 09:14AM -0800 On Wednesday, February 28, 2018 at 11:27:57 AM UTC-5, Rick C. Hodgin wrote: > Mary giving her consent doesn't change anything regarding Jesus Christ's > legitimacy: Mary was not married to God ergo Jesus Christ is still a > bastard... I, the real Rick C. Hodgin, did not write this post. Please examine the headers to see that there is someone usurping my identity (and without my permission). I post from Eternal September and Google Groups only. -- Rick C. Hodgin PS -- Leigh, you are absolutely disgusting in your vulgarity, a true servant of Satan's twisting lies perpetrated upon your life. It is unbecoming for a creation of God to behave as you are choosing. May God open your eyes to the beautiful creation you are, and lead you into understanding and repentance for your sin. |
| "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Feb 28 11:07AM -0800 On 2/4/2018 9:59 AM, Rick C. Hodgin wrote: > On 2/4/2018 12:28 PM, Rick C. Hodgin wrote: >> "No one of illegitimate birth ... > I, the real Rick C. Hodgin, did not write this post. We know. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Feb 28 11:16AM -0800 On Wednesday, February 28, 2018 at 2:11:27 PM UTC-5, Chris M. Thomasson wrote: > >> "No one of illegitimate birth ... > > I, the real Rick C. Hodgin, did not write this post. > We know. Blind and non-forward-thinking Chris ... I do not write these messages for you or the others here who, today, know what's happening in this group. I write it for the unknowing soul who searches for my name on Google and arrives at some horrid blasphemy perpetrated against me by a Class-A coward. > > Please examine the headers to see that there is someone usurping my > > identity (and without my permission). I post from Eternal September > > and Google Groups only. There is true, foundational wisdom that exists, Chris. Seek it. -- Rick C. Hodgin |
| "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Feb 28 11:55AM -0800 On 2/28/2018 11:16 AM, Rick C. Hodgin wrote: >>> identity (and without my permission). I post from Eternal September >>> and Google Groups only. > There is true, foundational wisdom that exists, Chris. Seek it. Wow, you really are a nice guy... ;^o |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Feb 28 12:35PM -0800 On Wednesday, February 28, 2018 at 2:55:39 PM UTC-5, Chris M. Thomasson wrote: > Wow, you really are a nice guy... ;^o You're so... flippant, Chris. Casual about everything. Never considering things of substance, or seeking out solidity in things. I want to grab you by the ears and shake you back and forth screaming into your thinking: WAKE UP!! WAKE UP!! WAKE UP!! But I fear it would do no good. I fear you'll have to go through the hardest things, being hurt significantly as you go, before you will wisen up. One of the hardest things for me in this world is to know that no matter how much I try and teach people the truth, with all the varying ways from simple instruction to figuratively grabbing people by the ears and shaking them as I indicated above ... some people will not be saved. It breaks my heart. It's such a waste. And it's all lost to pride. -- Rick C. Hodgin |
| "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Feb 28 12:40PM -0800 On 2/28/2018 12:35 PM, Rick C. Hodgin wrote: > and shake you back and forth screaming into your thinking: WAKE UP!! WAKE UP!! > WAKE UP!! But I fear it would do no good. I fear you'll have to go through the > hardest things, being hurt significantly as you go, before you will wisen up. Shi% Just a matter of time? |
| scott@slp53.sl.home (Scott Lurndal): Feb 28 09:34PM "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: It's such a waste. And it's all lost to pride. Indeed, your Hubris is astonishing. |
| Juha Nieminen <nospam@thanks.invalid>: Feb 28 05:45AM > whether either of the two ways of doing this was noticeably superior to > the other. What I've learned is that they're pretty similar for this > kind of task. Understanding <iostream> is ok, but be aware that most, if not all, implementations of it are less efficient than those of <cstdio>. Even std::istream::read() can be less efficient than std::fread(), even though logically they do the exact same thing. |
| Melzzzzz <Melzzzzz@zzzzz.com>: Feb 28 05:58AM > implementations of it are less efficient than those of <cstdio>. > Even std::istream::read() can be less efficient than std::fread(), > even though logically they do the exact same thing. Why? -- press any key to continue or any other to quit... |
| Hergen Lehmann <hlehmann.expires.5-11@snafu.de>: Feb 28 09:23AM +0100 Am 28.02.2018 um 06:45 schrieb Juha Nieminen: > implementations of it are less efficient than those of <cstdio>. > Even std::istream::read() can be less efficient than std::fread(), > even though logically they do the exact same thing. Another problem with <iostream> is that it does too good a job in hiding the underlying file handle. It is fine for basic file IO in simple single-process/single-user applications, but in "real life" you will quickly run in into situations where you need more control over the opening mode, need to set runtime flags like record locks, or need to operate on non-file streams like sockets. <iostream> can't do that, at least not without re-inventing the wheel (by writing your own streambuf with it's highly complex and awkward interface). |
| Ian Collins <ian-news@hotmail.com>: Feb 28 10:17PM +1300 On 02/28/2018 09:23 PM, Hergen Lehmann wrote: > sockets. <iostream> can't do that, at least not without re-inventing the > wheel (by writing your own streambuf with it's highly complex and > awkward interface). On the contrary, it is a very simple interface... I often use specialised streambuf implementations as a teaching example. All that is required for an underflow() override. -- Ian. |
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 28 12:01PM +0200 On 28.02.2018 7:58, Melzzzzz wrote: >> Even std::istream::read() can be less efficient than std::fread(), >> even though logically they do the exact same thing. > Why? I just stepped through a std::ifstream::read() in the MSVC++2017 debugger. In addition to an indirection (stream -> readbuf) it calls the following virtual functions: virtual streamsize basic_streambuf::xsgetn(); virtual int_type basic_filebuf::uflow(); xsgetn() is called once and uflow() is called when the read buffer gets empty. So it's not so bad (I have an impression some other std::istream features involve virtual calls per each character). Underneath it uses the FILE* infrastructure, but does not use any public FILE* functions for reading the bulk of the data; instead it uses the internal read buffer in the FILE structure directly. In short: std::ifstream::read() is built on top of FILE* mechanism with some indirections and virtual calls added. As such, it cannot be faster than fread(); if it is slower depends on a lot of things, most probably the actual I/O speed will be the bottleneck anyway, but YMMV. And in another implementation ifstream::read() might be implemented differently. If the file is in the disk cache then the ifstream::read() overhead seems to matter to some extent. I made a test reading a 8MB binary file repeatedly and summing each 128-th byte, the results are (I also added mmap/MapViewOfFile for curiosity): istream::read: 3.48344 ms fread: 2.09826 ms mmap: 0.990501 ms Cheers Paavo |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Feb 28 11:16AM On Wed, 28 Feb 2018 22:17:07 +1300 > On the contrary, it is a very simple interface... I often use > specialised streambuf implementations as a teaching example. All > that is required for an underflow() override. I agree that std::basic_streambuf is a reasonably designed and simple-ish interface to implement. The bare minimum is to inherit from std::basic_streambuf and override sync() and overflow() for output and underflow() for input. If you want the most efficient block reads and writes which bypass the internal buffers you might also want to override xsputn() and xsgetn(), and you are also going to have to override seekoff() and seekpos() if you want to implement seekability on seekable files (irrelevant for things like sockets of course). My objection is more having to do it at all for the most common case, namely when you want to construct a stream object for a pre-opened file descriptor. I find it surprising that, on unix-like platforms at least, gcc and clang do not provide built in streambuffers for this. The built-in streams provided by C++ do not actually enable you to write a safe temporary file. So in a unix-like environment you either have to write your own streambuffer (which is what I have done) or you take the easier route of using POSIX fdopen() and C streams instead. Chris |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Feb 28 11:36AM On Wed, 2018-02-28, Ian Collins wrote: > On the contrary, it is a very simple interface... I often use > specialised streambuf implementations as a teaching example. All that > is required for an underflow() override. You should teach us ... I've spent a lot of time on it, then barely understood enough to to implement something useful -- and forgotten it again. The documentation in Stroustrup's book isn't enough, not for me anyway. ISTR that James Kanze had a web page on the subject. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Feb 28 12:32PM On 28 Feb 2018 11:36:29 GMT > again. The documentation in Stroustrup's book isn't enough, not for > me anyway. > ISTR that James Kanze had a web page on the subject. Josuttis's "The C++ Standard Library" gives an introduction and sample implementation, which isn't bad (or at least the first edition does, I don't have the second). |
| Melzzzzz <Melzzzzz@zzzzz.com>: Feb 28 12:52PM > istream::read: 3.48344 ms > fread: 2.09826 ms > mmap: 0.990501 ms Heh, I always use fstream/sstream, didn't know that this is that slower ;) I even implemented simple database exclusivelly with fstream ;p And parsing strings , I don't like snprintf/sscanf at all ;) -- press any key to continue or any other to quit... |
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 28 04:15PM +0200 On 28.02.2018 14:52, Melzzzzz wrote: > Heh, I always use fstream/sstream, didn't know that this is that slower > ;) > I even implemented simple database exclusivelly with fstream ;p Depends on the usage. If the file is not in the OS disk cache the timings would probably be much longer and more equal. Also, whenever the program does something more substantial with the file content then it also does not matter if there is a millisecond lost somewhere. > And parsing strings , I don't like snprintf/sscanf at all ;) snprintf,sscanf et al are locale sensitive, meaning that a substantial part of their work is spent on setting up and locking the global locale. This can become significant in a massively multithreaded app. At least C++ streams have the imbue() functionality for binding a non-global locale which ought to remove this particular bottleneck. Of course, if locale dependency is not needed at all, like when parsing source code of a typical programming language, the most performing way is to use special functions with built-in ASCII/C-locale behavior. But again, all this matters only if the speed is important at that point. |
| 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