| Victor Bazarov <v.bazarov@comcast.invalid>: Oct 29 08:04AM -0400 On 10/28/2015 5:36 PM, Paul wrote: > Is there any way of ascertaining (other than looking it up) whether objects are in the standard namespace? For example, INT_MIN from the <climits> header is not in the std namespace but cout from <iostream> is in the std namespace. > How could one deduce that beforehand to avoid compile errors from writing std::INT_MIN? > Is the rule that functions from header files are in the std namespace > but variables from header files are not in the std namespace? Or is > it subtler? Or something else I haven't thought of? If you know that it's a macro you can only use #ifdef {macroname}, otherwise when the compiler gets to it, the name has already been substituted with its meaning. If it's an object (like 'cout'), you could try taking its address and wrap it in a SFINAE definition/declaration (nothing on the top of my head, though). V -- I do not respond to top-posted replies, please don't ask |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 29 12:40PM On Wed, 2015-10-28, Paul wrote: > namespace but variables from header files are not in the std > namespace? Or is it subtler? Or something else I haven't thought > of? What problem are you trying to solve? To mistype and have the compiler correct you, that's not such a great burden[0]. "assert" and anything in CAPITALS are macros, the rest is in std -- I think that's a pretty good rule of thumb. /Jorgen [0] Gone are the days of batch programming where you'd get the compilation error on paper the next morning ... -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Vir Campestris <vir.campestris@invalid.invalid>: Oct 29 09:28PM On 28/10/2015 21:36, Paul wrote: > Is there any way of ascertaining (other than looking it up) whether objects are in the standard namespace? For example, INT_MIN from the <climits> header is not in the std namespace but cout from <iostream> is in the std namespace. > How could one deduce that beforehand to avoid compile errors from writing std::INT_MIN? > Is the rule that functions from header files are in the std namespace but variables from header files are not in the std namespace? Or is it subtler? Or something else I haven't thought of? I know no rule. But in this case couldn't you use std::numeric_limits<int>::min() ? Andy |
| "Öö Tiib" <ootiib@hot.ee>: Oct 29 04:03AM -0700 On Wednesday, 28 October 2015 17:01:11 UTC+2, David Brown wrote: > auto get_fun(int arg) { > return make_function_pointer(arg); > } The feature is not that great since implicit return value type is allowing us to omit important property. That is somewhat like implicit int of C was. Also we often want to declare functions before defining those (in header) and there what Juha wrote looks best: auto get_fun(int arg) -> double (*)(double); |
| David Brown <david.brown@hesbynett.no>: Oct 29 01:43PM +0100 On 29/10/15 12:03, 嘱 Tiib wrote: > Also we often want to declare functions before defining those (in header) > and there what Juha wrote looks best: > auto get_fun(int arg) -> double (*)(double); Replacing the return type entirely with auto has the same pros and cons as using auto in general. It is convenient for complicated types, but omits information that might be useful to the programmer and reader. It makes code more flexible (especially for templates), but reduces the possibilities for type-based error checking. And clearly it can't work without the function definition (i.e., it will not work in non-defining declarations). It's a feature - you can use it if it helps, and avoid it if it does not help. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 29 10:04PM +0100 On 10/28/2015 2:25 PM, Juha Nieminen wrote: [snip] > auto get_fun(int arg) -> double (*)(double) > vs. the old way: > double (*get_fun(int))(double) Also, old way Longwinded_class_name::name_of_type Longwinded_class_name::foo( name_of_type arg ) { ... } versus auto Longwinded_class_name::foo( name_of_type arg ) -> name_of_type { ... } One less qualification (of the return type), which is also more consistent, plus more easily recognized fixed placement of the function name. However, some people use a formatting convention where the function name has fixed placement also with the old syntax. Cheers, - Alf |
| "Öö Tiib" <ootiib@hot.ee>: Oct 29 02:13AM -0700 > You want to say is not possible > define operator as one of these > symbols? It is simple. If you are programmer then anything is possible to do. It does not matter what others want or don't want to say. C++ standard defines only usage of most of the ASCII characters but that does not matter for programmer. Lets say you have code: auto a = white_chess_rook( x, y ); With some operator overloading tricks you can turn it into: auto a = x *white_chess_rook* y; Then you can change the text editor to automatically show/use '♖' instead of '*white_chess_rook*' like that: auto a = x ♖ y; As result compiler still gets what is required by standard and you get to see and to use your odd characters that you want and we do not need to modify the programming language. From my keyboard it is not too convenient to type characters like that white chess rook character and the whole eye-candy leaves me indifferent so I do not want your editor. |
| asetofsymbols@gmail.com: Oct 29 02:24AM -0700 You not think enough... |
| asetofsymbols@gmail.com: Oct 29 02:27AM -0700 Yes I not think enough too |
| asetofsymbols@gmail.com: Oct 29 03:54AM -0700 Öö Tiib wrote: > You want to say is not possible > define operator as one of these > symbols? It is simple. If you are programmer then anything is possible to do. It does not matter what others want or don't want to say. C++ standard defines only usage of most of the ASCII characters but that does not matter for programmer. Lets say you have code: auto a = white_chess_rook( x, y ); With some operator overloading tricks you can turn it into: auto a = x *white_chess_rook* y; Then you can change the text editor to automatically show/use '♖' instead of '*white_chess_rook*' like that: auto a = x ♖ y; As result compiler still gets what is required by standard and you get to see and to use your odd characters that you want and we do not need to modify the programming language. From my keyboard it is not too convenient to type characters like that white chess rook character and the whole eye-candy leaves me indifferent so I do not want your editor. _________ Excuse me you are right I think is possible modify the macro sys to handle a=x♖y; case |
| asetofsymbols@gmail.com: Oct 29 04:11AM -0700 %operatorDefine ♖ f Possibly a=x♖(z♖z); case too in a=f(x, (f(z,z))) too |
| David Brown <david.brown@hesbynett.no>: Oct 29 01:33PM +0100 On 29/10/15 10:13, Öö Tiib wrote: > auto a = white_chess_rook( x, y ); > With some operator overloading tricks you can turn it into: > auto a = x *white_chess_rook* y; One can do even better than that. Make the operator overloading tricks so that you are using "* do_white_chess_rook *", and then have: #define white_chess_rook * do_white_chess_rook * Then you can write: auto a = x white_chess_rook y; > From my keyboard it is not too convenient to type characters like > that white chess rook character and the whole eye-candy leaves me > indifferent so I do not want your editor. #include <cmath> #include <iostream> template<class T> class DoPowerer { T x_; public : constexpr DoPowerer(T x) : x_(x) {}; template<class U> friend constexpr U operator*(const DoPowerer<U> dp, const U y); }; class Powerer { template<class T> friend constexpr DoPowerer<T> operator*(const T x, const Powerer p); }; template<class T> constexpr DoPowerer<T> operator*(const T x, const Powerer p __attribute__((unused)) { return DoPowerer<T>(x); } template<class T> constexpr T operator*(const DoPowerer<T> dp, const T y) { return std::pow(dp.x_, y); } static constexpr const Powerer powerer; #define power *powerer* int main() { std::cout << "6 power 3 = " << (6 power 3) << std::endl; std::cout << "2.0 power 0.5 = " << (2.0 power 0.5) << std::endl; } So now "power" is somewhat like a new operator. And once gcc gets extended identifiers (clang has them from 3.3 onwards), you can write: #define ↑ *powerer* and then you get to write 2 ↑ 10 instead of std::pow(2, 10). Whether or not you think this is a good thing, is a different matter. |
| bleachbot <bleachbot@httrack.com>: Oct 25 07:33PM +0100 |
| 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