From 5895414610890986228 X-Google-Thread: f78e5,1d1109cd86668825 X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!pd7cy3no!shaw.ca!news.alt.net!comp-std-cpp-robomod!not-for-mail From: "dstevel" Newsgroups: comp.std.c++ Subject: Re: strtol const-ness problem Date: Mon, 21 Aug 2006 04:40:56 CST Organization: http://groups.google.com Lines: 73 Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: <1155755836.318764.277570@75g2000cwc.googlegroups.com> References: <1155392893.026182.121030@h48g2000cwc.googlegroups.com> <1155445528.956928.185450@p79g2000cwp.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1155755842 19075 127.0.0.1 (16 Aug 2006 19:17:22 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 16 Aug 2006 19:17:22 +0000 (UTC) Return-Path: X-Authentication-Warning: mulga.csse.unimelb.edu.au: fjh set sender to devnull@stump.algebra.com using -f X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Original-To: std-c++@mailman.ucar.edu Delivered-To: std-c++@mailman.ucar.edu User-Agent: G2/0.2 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1b1) Gecko/20060710 Firefox/2.0b1,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: 75g2000cwc.googlegroups.com; posting-host=192.94.38.34; posting-account=MidBUg0AAAA0r3VZXx8ZSe9LraA2fVzN X-Virus-Scanned: amavisd-new at ucar.edu X-Virus-Scanned: amavisd-new at csse.unimelb.edu.au X-Virus-Scanned: amavisd-new at csse.unimelb.edu.au Xref: g2news2.google.com comp.std.c++:3365 Thank you all for your responses. I wanted to reply to Greg who thought it would be unusual to scan a const string. That might be true if it was a string declared in the code and known at compile time. But, consider an std::string from some source. (Or a stream for that matter). Then, using myString.c_str() to obtain a const char* would be OK if you want to use strtol. If we allow something to mess with the internal memory of the std::string, it could be "bad". So I wanted to enforce const-correctness in my function that uses strtol without casting it away or making non-const copies/temporaries. It looks const_cast will have to do for the call to strtol and that will not leave me with any usable non-const pointers into the original string. I just need to trust that strtol is playing nice. Thanks again, ~Dan Greg Herlihy wrote: > First it would be rather unusual (not to mention inefficient) for a > program to spend its cycles scanning text for numbers - when the > contents of text being scanned (and by extension, the number values > contained therein) are both constant and were known at compile time. > Therefore, in the vast majority of cases, it is likely that strtol will > be called to process non-const character values. > > Second, most C++ programmers are accustomed to be able to pass a > pointer to non-const (such as char *) whenever a function declares a > pointer to const parameter. So, by extension, it is likely that C++ > programmers would expect to be able to pass a pointer to a pointer to > non const whenever a pointer to a pointer to const parameter is > declared (in other words to pass char** for a a const char** > parameter). > > As it turns out, a char** pointer cannot be used in place of const > char** parameter: > > // assume: > long strtol(const char *nptr, const char **endptr, int base); > > ... > char *s = "15"; > > long n; > n = strtol(s, &s, 10);// ERROR: > // invalid conversion: char** to const char** > > So were strtol's second parameter declared a const char** pointer, then > C++ programmers would be quite likely to encounter this > counterintuitive conversion error. Furthermore, give the first point > above (that the string being scanned will - in all likelihood - be > non-const) encountering this error becomes ever more likely - at least > when compared against its counterpart - the error that is seen today: > (whenever a program tries to pass a const char** pointer for strtol's > char**, second parameter.) > > Finally, since a cast will be necessary either in one case or the other > - it seems that a decision favoring the less unusual cast in the less > likely scenario is, on the whole, nothing other than a decision to > annoy fewer C++ programmers, the fewer number of times. > > 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.comeaucomputing.com/csc/faq.html ] --- [ 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.comeaucomputing.com/csc/faq.html ]