- operator == on vectors - 4 Updates
- migraines - 1 Update
- boost::regex_relace vs. std::regex_replace: Who is right? - 1 Update
- use of the new override specifier - 1 Update
- Using std::string by reference - 1 Update
| Juha Nieminen <nospam@thanks.invalid>: Jun 14 06:16AM > if(z == {}) I hope you are doing that only out of curiosity, experimenting and learning, not in actual code. Obviously in actual code you would use z.empty(). --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jun 14 06:36AM On Sun, 2016-06-12, Alf P. Steinbach wrote: ... > most all standard containers) you can use the misleadingly named member > function `empty` to check whether it's empty. Contrary to what the name > indicates, it does not empty the collection. It just checks. It's a matter of point of view. I don't find it misleading but rather natural ... or at least in line with the standard library naming conventions in general. ... > auto is_empty( std::vector<Item> const& v ) > -> bool > { return v.empty(); } We've had empty() for around 25 years; I don't think it's helpful to introduce an alias. Not if more than one person sees the code, anyway. This on the other hand is one thing I sometimes wish for, since I tend to want to negate the empty() check: if (!foobar.empty()) ... // hard to spot the negation if (not foobar.empty()) ... // few use the 'not' alias if (foobar.non_empty()) ... // better /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| "Öö Tiib" <ootiib@hot.ee>: Jun 14 04:44AM -0700 On Tuesday, 14 June 2016 09:36:54 UTC+3, Jorgen Grahn wrote: > It's a matter of point of view. I don't find it misleading but rather > natural ... or at least in line with the standard library naming > conventions in general. Hmm. Are you sure about naming "conventions" of standard library? What is correct by those "conventions"? Is it 'vector::get_allocator()' or 'vector::allocator()'? Is it 'vector::capacity()' or 'vector::get_capacity()'? Feels there are no such "conventions". We typically expect functions to be requests of activities in imperative programming language therefore usage of word that is both verb and adjective ('empty') for function name in meaning of that adjective is misleading. Frank way of naming such function would be 'is_empty'. > > { return v.empty(); } > We've had empty() for around 25 years; I don't think it's helpful to > introduce an alias. Not if more than one person sees the code, anyway. That is entirely another question if it is worth to try to repair such minor legacy cosmetic defects in standard library or not. I do not think that it is. > This on the other hand is one thing I sometimes wish for, since I > tend to want to negate the empty() check: > if (!foobar.empty()) ... // hard to spot the negation That depends on how your code editor colors the operators. > if (not foobar.empty()) ... // few use the 'not' alias These aliases are made like inbuilt macros so one can declare rvalue reference 'foo' like that: auto and foo = get_foo(); > if (foobar.non_empty()) ... // better But also likely not worth it. Lot of developers (possibly majority) write one of those instead: if (foobar.size()) ... // the reality if (0 < foobar.size()) ... // the reality if (foobar.size() != 0) ... // the reality I suspect that it is so (at least partially) because 'empty' is such a bad name. ;-) |
| Wouter van Ooijen <wouter@voti.nl>: Jun 14 05:49PM +0200 > programming language therefore usage of word that is both verb and > adjective ('empty') for function name in meaning of that adjective is > misleading. Frank way of naming such function would be 'is_empty'. I agree 100%. I teach my students that a predicate should always contains a verb like is, has, contains, includes, etc. The other function (the one that makes something empty) should probably be called make_empty(). Wouter "Objects? No Thanks!" van Ooijen |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 14 05:36PM +0200 On 13.06.2016 22:09, Vir Campestris wrote: > Forgiven. > That might explain why I get them in groups for a few days, then not for > a while. :) Cheers!. - Alf |
| Ralf Goertz <me@myprovider.invalid>: Jun 14 10:31AM +0200 Hi after upgrading gcc from version 4.8.5 to version 5.3.1 I thought I could get rid of boost's regex-implementation (boost version 1.54.0) and use the one provided by gcc (it didn't work with gcc before version 4.9 AFAIK). However, this turned out to be a problem because those two implementations behave differently: #include <regex> #include <boost/regex.hpp> #include <iostream> #include <string> int main() { std::string s="\\needs_another_backslash"; std::string reg("^\\\\"); std::string rep("\\\\"); std::regex sr(reg); boost::regex br(reg); std::cout<<"string before replacement:\n"<<s<<std::endl<< "std::regex_replace:\n"<<std::regex_replace(s,sr,rep)<<std::endl<< "boost::regex_replace:\n"<<boost::regex_replace(s,br,rep)<<std::endl; return 0; } The output of that program is: string before replacement: \needs_another_backslash std::regex_replace: \\needs_another_backslash boost::regex_replace: \needs_another_backslash It seems as if boost treats the '\' in a replacement string specially whereas gcc does not. According to http://www.cplusplus.com/reference/regex/regex_replace/ the magical character for backreference etc. in the replacement string is '$'. So I tend to think that gcc is right. However, in other programs (like vim e.g.) it is '\'. So boost might have a point in treating '\' specially. So who is right? Ralf |
| Juha Nieminen <nospam@thanks.invalid>: Jun 14 06:09AM > I leave it up to the IDE to identify overrides. This is more reliable. How exactly would the IDE know if a function is supposed to override the same function in the base class if you don't tell it? --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| scott@slp53.sl.home (Scott Lurndal): Jun 13 11:36PM >> } > Nowhere is »str« being assigned to above, > so it can be declared as »const«. Seems a bit pedantic on your part, you could simply have pointed out that his attemped assignment was incorrect as it is clear from the function name what his intent was. >> // use case 1 -- won't compile >> translateInPlaceAndPrint ("Good Morning!"); Regardless, K. Frank shouldn't expect the lifetime of the temp string object to extend beyond the function call in his example #1, so it would be pointless for the compiler to allow it. |
| 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