- How to split a char array? - 6 Updates
- New address of the C Containers library - 2 Updates
- list of operating systems that can run C++? - 2 Updates
| "Heinz-Mario Frühbeis" <Div@Earlybite.individcore.de>: Mar 30 09:04PM +0200 Am 30.03.2016 um 17:25 schrieb Geoff: >>>>>>>> Am 27.03.2016 um 15:03 schrieb Alf P. Steinbach: >>>>>>>>> On 27.03.2016 11:17, Heinz-Mario Frühbeis wrote: >> [...] [...] > Since you were copying a const char *nString, I assumed you knew where > it was coming from and would obtain the lock on that string before > copying it to the local mutable string for manipulation. I know, what I experience... std::string.c_str works, std::string not. Regards Heinz-Mario Frühbeis |
| Dombo <dombo@disposable.invalid>: Mar 30 09:59PM +0200 Op 30-Mar-16 om 16:38 schreef Mr Flibble: >> That makes a big difference in efficiency. > x is a constant though so it makes no difference as far as algorithmic > "efficiency" (complexity) is concerned. But it does make a difference as far as effective speed and memory fragmentation is concerned. |
| Mr Flibble <flibble@i42.co.uk>: Mar 30 09:23PM +0100 On 30/03/2016 20:59, Dombo wrote: >> "efficiency" (complexity) is concerned. > But it does make a difference as far as effective speed and memory > fragmentation is concerned. You can use a custom allocator with std::list to avoid fragmentation; without a custom allocator std::deque also suffers from fragmentation. /Flibble |
| Paavo Helde <myfirstname@osa.pri.ee>: Mar 30 11:15PM +0200 On 30.03.2016 21:04, Heinz-Mario Frühbeis wrote: > I know, what I experience... std::string.c_str works, std::string not. Sorry, with C++ this is not sufficient. You have to know whether and why something works and something does not. If you do not know and do not want to learn, please choose another language, with less Undefined Behavior. Cheers Paavo |
| "Öö Tiib" <ootiib@hot.ee>: Mar 30 02:26PM -0700 On Wednesday, 30 March 2016 22:04:42 UTC+3, Heinz-Mario Frühbeis wrote: > I know, what I experience... std::string.c_str works, std::string not. And we know that you are incorrect. The code that you posted should not compile on C++ compiler. It is full of odd screaming syntax errors. Your code, my comments added: std::string string_var; if(string_var.length() > 0) // FINE ... you wrote ERROR {} if(strlen(string_var.c_str) > 0) // ERROR: invalid use of member function 'c_str' ... you wrote NO ERROR {} if(string_var == "HALLO"() > 0) // ERROR: string literal can't be called as function ... you wrote ERROR {} if(string_var.c_str == "HALLO") // ERROR: invalid use of member function 'c_str' ... you wrote NO ERROR {} So you either experience troll lulz from responses of you pretending ignorance or you really write such kooky voodoo code and anything you experience with it is only within your imagination. |
| jt@toerring.de (Jens Thoms Toerring): Mar 30 09:34PM >> if you don't own the lock on it you are not thread safe. Your >> experiment is flawed and your statement above is incorrect. > I know, what I experience... std::string.c_str works, std::string not. Please take a deep breath, relax and consider for just a moment that you may have misunderstood a number of things: unfortunately, your "experience" is completely irrelevant here as programming is not an experimental science. Just because something happens with a lower probability (e.g. the problems you experienced with a C arrays compared to a C++ std::string) and you thus may not yet have experienced it is no proof that it can't happen. What you say is a bit like "experimental mathematics": 3 is a prime, 5 is a prime, 7 is a prime, thus, according to "experience", all odd numbers are prime;-) If you use threads and a thread can modify an object while another thread accesses it (even just for reading) at the same time you've got a massive problem, called a "race condition" (do yourself a favour and look it up). These problems are insidious because they are non-deterministic - most of the time it looks as if everything is fine and dandy (because most of the time there's just one thread doing anything with the object), but once in a while something strange will happen but can't be reproduced. Threads are nice and all, but they come with their own set of requirements to work pro- perly: you either have to operate on "atomic" objects or obtain locks while accessing them when there's even the slightest chance that this object could be accessed by a different thread simulta- nously. Everything else is simply a recipe for disaster. A function can be "thread-safe", which just means that it will work properly when two different threads call it at the same time. But (with very few exceptions) objects aren't (neither a C array nor a C++ std::string is) - only objects that can be acces- sed "atomically" are - and there are very few of that kind (and what is an "atomic" types can differ on different machines, so that's another realm where your "experience" you gained on one platform is, unfortunately, worth zilch). And - BTW and out of context - one other of your code snippets from a different thread if (my_string.c_str() == "HELLO") { .... } is very unlikely to do what you seem to think it does. It com- pares the address of where the 'my_string' std::string object has stored it's string to where the compiler has stored the non-modifiable C string "HELLO". That's rather unlikely to be what you really want to know: from the looks of it you want to know if these strings have the same content. But that's a dif- ferent question and would require the use of the strcmp() func- tion. if (my_string == "HELLO") and if (my_string.c_str() == "HELLO") may look similar (up to the point of getting fooled into assu- ming that they are equivalent), but what they actually test for is very, very different. Regards, Jens -- \ Jens Thoms Toerring ___ jt@toerring.de \__________________________ http://toerring.de |
| jacobnavia <jacob@jacob.remcomp.fr>: Mar 30 08:38PM +0200 Le 30/03/2016 18:14, Scott Lurndal a écrit : >> Please, there is NO comparison here! > Wrong group for this argument. Suffice it to say > horses for courses. Tex is used in scientific journals like astronomy and astrophysics. It is the work of D. Knuth, someone I profoundly respect. The independence of TeX from the machine, and many other things of TeX makes it a unique creation. Obviously nroff has the same stuff, and many other text handling programs (probably, I do not really know nroff that well) but in a mathematical way, TeX is relly something. I remember when it appeared, the bugs of Knuth, his analysis of those bugs, those wonderfully typesetted programming books that Knuth wrote. Mostly sentimental reasons as you see. |
| jacobnavia <jacob@jacob.remcomp.fr>: Mar 30 10:07PM +0200 Le 30/03/2016 18:23, Keith Thompson a écrit : > hashtable.c:383:15: note: 'HashIdx' was declared here > HashIndex HashIdx,*hi; > ^ This comes because the code analyzer of gcc fails to realize that this data is initialized in the call to getfirst in function Clear > integer expressions [-Wsign-compare] > if (h->Log2N == -1 || h->count > (1 << h->Log2N)) { > "-std=c99" gives similar results. OK. Thanks I will look at that one later > One more minor problem: "make clean" doesn't remove "test.o". OK. Thanks |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Mar 30 08:47PM +0200 On 30.03.16 19.07, Bo Persson wrote: [VM with git vs. C++] > So, to have optimal performance you either download an executable > specifically optimized for your system, or a JVM with specific > optimizations for your system. Except that the latter has to be done only once for each platform while the optimized executable has to be build for the cross product of platforms and applications. In real live no one does the latter. Even common Linux distributions target only roughly the hardware. So many new CPU features are unused by most of the applications. Some exceptions prove the rule, of course. E.g. the FFTW library comes with optimized assembler code for many architectures. Marcel |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Mar 30 06:56PM On Tue, 2016-03-29, Christopher Pisz wrote: > in C++? > My office mate is arguing with me that C# is now more portable than C++, > because...mono. He is making me angry. You should be mildly amused and secretly condescending. Problem solved! /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