- How to call the unary "::"? - 3 Updates
- Function Objects - 3 Updates
- How to call the unary "::"? - 4 Updates
- some experiments with type names - 2 Updates
- Returning Function Pointers - 2 Updates
| ram@zedat.fu-berlin.de (Stefan Ram): May 02 02:39PM How to call the »::« in ::std::cout ? The second »::« is the binary "scope resolution operator", but is the first unary one also called "scope resolution operator"? A recent draft calls it "unary scope operator" in 3.4.3p4, but "global :: scope resolution operator" in the note of 8.3p1. It seems both designations are used only once in whole draft, so there does not seem to have been taken great care to give this operator a consistent and proper name, although we should value the normative text higher than the text of a note and thus call it "unary scope operator". |
| ram@zedat.fu-berlin.de (Stefan Ram): May 02 04:28PM You can declare a variable thus int i; , although »int« is a type name, the compiler did not accept typename int i; , but it did accept typename ::std::string s; , however, it did not accept class ::std::string s; because ::std::string is typedef, it is not a class, but it would accept class a_class a; if »a_class« is a proper class. Do you know a type from the standard library that actually /is/ a class? (not a template or a typedef) (I really am looking for such a class to use it in my tutorial.) Applications: you can use this to observe via an error message whether a type name is primitive, typedeffed or a real class. Exercise: (I have not done this myself and don't know if it's possible). Define a template so that ::std::cout << printkind< int >::value << '\n'; ::std::cout << printkind< ::std::string >::value << '\n'; ::std::cout << printkind< a_class >::value << '\n'; prints: primitive typedeffed class , or, even better, without the need for »::value«. . |
| ram@zedat.fu-berlin.de (Stefan Ram): May 02 10:14PM When Herb Sutter revised his definition of a class for complex numbers for C++11, he did not make the constructors constexpr, although it seems that this could have been possible and there were comments that suggested this to him. What do you think why he did not use »constexpr« at the beginning of the constructors and some member functions? Could there be any drawback of using »constexpr«, when it is possible? Should we use »constexpr« in front of every constructor or function where its possible? (Ok, it might become part of the public interface and then it might be difficult to change the interface later when, for some reason, the constructor or function cannot be implemented as constexpr any longer.) |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: May 02 07:48AM On Fri, 2015-05-01, Victor Bazarov wrote: > the stack", but you will most probably be mistaken. A few bytes on the > stack can mean *any* amount on the heap, as well. > Just a thought... Yes, I was almost about to mention that. In the end I was unsure why the OP wanted to know. The lifetime aspect is more important than anything else about this, but I think others got that message through. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| "Öö Tiib" <ootiib@hot.ee>: May 02 12:07PM -0700 On Saturday, 2 May 2015 10:48:28 UTC+3, Jorgen Grahn wrote: > In the end I was unsure why the OP wanted to know. The lifetime > aspect is more important than anything else about this, but I think > others got that message through. Such questions are possibly because in C++ there are so lot of syntax that feels like low level optimization-oriented tinkering. Things like 'inline', 'register', pointers, references, 'std::move', all those copy and move constructors, assignments etc. That may easily leave impression that C++ code is somehow in control how the compiler matches it to instructions, registers, stack and heap of underlying platform. |
| Paavo Helde <myfirstname@osa.pri.ee>: May 02 05:00PM -0500 Öö Tiib <ootiib@hot.ee> wrote in > impression that C++ code is somehow in control how the compiler > matches it to instructions, registers, stack and heap of underlying > platform. Sure it is. A large portion of C++ users are relying on its zero-overhead and maximum performance promises. And for sure, if the performance issues are critical, the programmer needs to write the code which performs best. This appears to be still a bit deterministic, so yes, C++ code is somewhat in control. For example, rvalue references and std::move specifically fixed a gap in an area which prevented achieving maximum performance in certain high-level programming style. It is under the control of the programmer to use or not use this style. If C++ would at some point fail to follow the zero-overhead principle, a porton of programmers and programs would move away to some other language to retain the maximum performance (to Fortran or C, possibly to something else branched off from C++ (D?)). Cheers Paavo |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: May 02 06:00PM +0200 On 02.05.15 16.39, Stefan Ram wrote: > ? The second »::« is the binary "scope resolution operator", > but is the first unary one also called "scope resolution > operator"? I would do so. > to give this operator a consistent and proper name, although > we should value the normative text higher than the text of a > note and thus call it "unary scope operator". Well, a slash in a path name may also be at the start of a path to denote the root and no one gave him another name in that context. Marcel |
| Ian Collins <ian-news@hotmail.com>: May 03 07:56AM +1200 Stefan Ram wrote: > How to call the »::« in > ::std::cout The superfluous scope resolution operator? -- Ian Collins |
| Victor Bazarov <v.bazarov@comcast.invalid>: May 02 04:58PM -0400 On 5/2/2015 3:56 PM, Ian Collins wrote: >> How to call the »::« in >> ::std::cout > The superfluous scope resolution operator? In this case, probably. In general, it's not superfluous if it helps the compiler to distinguish a global symbol from a local one: int i = 42; int main() { double i = .14159; ::i = 666; } V -- I do not respond to top-posted replies, please don't ask |
| "Öö Tiib" <ootiib@hot.ee>: May 02 02:15PM -0700 On Saturday, 2 May 2015 23:59:13 UTC+3, Victor Bazarov wrote: > >> How to call the »::« in > >> ::std::cout > > The superfluous scope resolution operator? :) > double i = .14159; > ::i = 666; > } Actually the front :: is good for indicating that a generally useful name (like 'rename', 'open', 'CreateFile' etc.) is meant as a global name not local name. It is fine for clarity even when there are no such name in local scope because it may make sense to use same name locally. A programmer who creates and hides cryptic names like 'i' or even some well-known library cryptic global names (like 'std', 'freopen' or 'snprintf') in more local scope deserves beating up and out. It is anyway complication, confusion and headache to read the code that practices such name-hiding so it should be rewritten not guarded against. |
| Paavo Helde <myfirstname@osa.pri.ee>: May 02 01:47PM -0500 ram@zedat.fu-berlin.de (Stefan Ram) wrote in news:type-name-20150502181607 > Do you know a type from the standard library that actually > /is/ a class? (not a template or a typedef) > (I really am looking for such a class to use it in my tutorial.) I feel sorry for your students who need to waste their time to learning useless garbage like unnecessary leading :: and unnecessary 'class' and 'typename' usage. > Exercise: (I have not done this myself and don't know if > it's possible). Feeling even more sorry ... |
| "Öö Tiib" <ootiib@hot.ee>: May 02 12:49PM -0700 On Saturday, 2 May 2015 19:28:26 UTC+3, Stefan Ram wrote: > would accept > class a_class a; > if »a_class« is a proper class. It is well-formed also when 'a_class' is 'struct', but several compilers will warn about it. > Do you know a type from the standard library that actually > /is/ a class? (not a template or a typedef) Lets be curious and check what typedef the 'std::string' is? It is required to be (in 'std' namespace): typedef basic_string<char> string; So lets see further what is the mysterious 'basic_string'? It is required to be such a thing: template < class charT , class traits = char_traits<charT> , class Alloc = allocator<charT> class basic_string; Wow, a 'class' template. So we may type: class std::basic_string<char> s1; Since further research about 'std::char_traits' and 'std::allocator' shows that these are class templates as well we may type: class ::std::basic_string<char, class ::std::char_traits<char>, class ::std::allocator<char> > s2; and that declaration must be equal with: std::string s2; However ... don't you have something more basic to teach your students about software development? The allocators and character traits are rather advanced topic. One may work for years in C++ shop and not care about those. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: May 02 08:17AM On Fri, 2015-05-01, Ben Bacarisse wrote: > written by a C programmer because it's C! (There's a fair bit of > evidence that the posted code is C not C++ though one can rarely be 100% > sure.) It's allowed, I think, to be a bit annoyed by decent C code being posted to a C++ group. Speaking of that, it could be more interesting for the OP to rewrite the example as idiomatic C++ code. Functors (lambdas?) stored in a std::map maybe, std::for_each ... The things you learn by doing that are more useful than function pointers. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: May 02 11:52AM +0100 >> sure.) > It's allowed, I think, to be a bit annoyed by decent C code being > posted to a C++ group. Oh, yes, sure, but that's not the fault of the programmer who wrote the code that got posted! By the way, it's not particularly good C code either -- get_oper fails to return a value in some cases, and I don't know why anyone would choose to write the declaration without a typedef, particularly since the function type is needed in more than one place. > the example as idiomatic C++ code. Functors (lambdas?) stored in a > std::map maybe, std::for_each ... The things you learn by doing that > are more useful than function pointers. Good idea. I just did that out of interest and I'll post mine if the OP has a stab at it. -- Ben. |
| 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