- How to output from c to excel & word - 3 Updates
- Soul in the Quran - 3 Updates
- Does God exists ? - 2 Updates
- You will say that God doesn't exist - 2 Updates
- Variadic template and arguments by value - 9 Updates
- Variadic template and arguments by value - 4 Updates
- Multi-compare operators - 1 Update
- CppCon/Tool-time - 1 Update
| davebalagizi@gmail.com: Sep 27 12:29PM -0700 Hello members am Ricky I would like to get advice how to make a report using excel or word I.e output from my file in c. Am using codes blocks IDE thanks.it is a small database |
| Ian Collins <ian-news@hotmail.com>: Sep 28 07:36AM +1200 > Hello members am Ricky I would like to get advice how to make a > report using excel or word I.e output from my file in c. Am using > codes blocks IDE thanks.it is a small database Output to a CSV or rich text file file, import into whatever you like. -- Ian. |
| David Brown <david.brown@hesbynett.no>: Sep 27 09:41PM +0200 On 27/09/18 21:36, Ian Collins wrote: >> report using excel or word I.e output from my file in c. Am using >> codes blocks IDE thanks.it is a small database > Output to a CSV or rich text file file, import into whatever you like. I strongly recommend LibreOffice rather than MS Office here - it is /far/ better at dealing with text import such as csv, tsv, etc. Of course, the other way to handle the problem is to drop C. If you've got data in a database, use LibreOffice (or, if you are richer and slightly masochistic, MS Access) to read from the database and generate the reports you want. |
| Horizon68 <horizon@horizon.com>: Sep 27 11:52AM -0700 Hello.... Read this: Soul in the Quran: Read more here: https://www.al-islam.org/resurrection-maad-quran-ayatullah-ibrahim-amini/soul-quran Thank you, Amine Moulay Ramdane. |
| "Öö Tiib" <ootiib@hot.ee>: Sep 27 12:02PM -0700 On Thursday, 27 September 2018 21:52:39 UTC+3, Horizon68 wrote: > Hello.... Hey, stop that not topical spamming, Amine. If you need then post your ideas to philosophy groups like alt.atheism and such. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 27 03:09PM -0400 On 9/27/2018 2:52 PM, Horizon68 wrote: > Hello.... > Read this: https://www.biblegateway.com/passage/?search=John+1&version=KJV https://www.biblegateway.com/passage/?search=John+14%3A15-31&version=KJV "If you love me, keep my commandments, and I will pray the Father, and he shall give you another Comforter, that he may abide with you for ever; even the spirit of truth; whom the world cannot receive, because it sees him not, neither knows him: but you know him, for he dwells with you, and shall be in you." Jesus seeks a close, personal, intimate relationship with us ... because He loves us. "He that has my commandments, and keeps them, he it is that loves me: and he that loves me shall be loved of my Father, and I will love him, and will manifest myself to him." https://www.biblegateway.com/passage/?search=1%20John%204:13--5:5 Read these things, and learn from them. Try another English translation if the King James is too difficult to understand. But once you get the gist from the other translation, come back to the KJV and pick up on subtlety and nuance. -- Rick C. Hodgin |
| Horizon68 <horizon@horizon.com>: Sep 27 11:06AM -0700 Hello.... Does God exists ? You will say that God doesn't exist, but read the following(read especially about the following study where two per cent exhibited full awareness with explicit recall of "seeing" and "hearing" events – or out-of-body ) Read more here: https://www.independent.co.uk/news/science/life-after-death-largest-ever-study-provides-evidence-that-out-of-body-and-near-death-experiences-9780195.html Thank you, Amine Moulay Ramdane. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 27 02:19PM -0400 On 9/27/2018 2:06 PM, Horizon68 wrote: > Hello.... > Does God exists ? It's interesting to read scientific articles about what happens after the heart stops beating... but let me tell you the truth. We are all eternal beings. We were created by God in God's own image and likeness. We rebelled against God and we live in the world sown by that rebellion (called 'sin' which is basically just doing something other than what God said). We are all going to spend eternity somewhere. The whole message of the Bible is that God loves you, wants you to still be a part of His creation in eternity, and has made the way out of the final punishment required for an eternal being who will not let go of that rebellion. Jesus came to the Earth to give us that way out. He came to take on our sin (and the resulting punishment for what we did) upon Himself. He did this purposefully, consciously, but choice, be- cause He is God and wants us to be with Him where He is in Heaven. All who come to Him asking forgiveness of their sin are forgiven and they will enter into eternity alive after leaving this world. All who reject Him will face the punishment of their own sin, re- sulting in their being cast into an eternal prison, the eternal equivalent of "life imprisonment for heinous crimes" we see here on Earth. ----- Make no mistake about it. You are comprised of a soul, a body, and a spirit. Your body in this world is not the only you. You are more than that. Your soul is under condemnation, your spirit is dead because of sin, and your body is in corruption (it gets old, gets sick, degrades, has weaknesses, etc.). What God offers us is a full restoration to what He intended be- fore sin entered in and destroyed everything. He offers us for- giveness, a second chance, a way back. He doesn't do this for the angels, though they are greater than we are here in this world. I urge you all to read the Bible objectively, to approach it not as something to be mocked, but as something to be pondered. Read what it teaches you about God, about man, about the sin na- ture of man, about salvation, about damnation, and about eternal life and Heaven. See if you can truly find a flaw with what it teaches. See if you can honestly say it doesn't resonate deeply with you within your core, deep down in your soul. It does that because God has placed it there for all who will be saved, for all who will hear His voice, for all who will leave this world without fear, know- ing where they're going. > Thank you, > Amine Moulay Ramdane. Jesus will forgive you too, Amine. Do you want eternal life? Or do you want to remain in rebellion against God? -- Rick C. Hodgin |
| Horizon68 <horizon@horizon.com>: Sep 27 10:40AM -0700 Hello, Read this: You will say that God doesn't exist, but read the following(read especially the outer body experience of the 57-year old man below): "A University of Southampton study has revealed that people could still experience consciousness for up to three minutes after the heart stops beating. The study interviewed 2,060 patients from Austria, USA and the UK who have all suffered a cardiac arrest. The Express reports that 40% could recall some form of awareness after being pronounced clinically dead. One 57-year old man seemed to confirm an outer body experience by recalling everything that was going on around him with eerie accuracy while he was technically dead." Read more here: https://www.dailystar.co.uk/news/latest-news/516195/university-southampton-study-science-life-death-hell-heaven Thank you, Amine Moulay Ramdane. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 27 01:57PM -0400 On 9/27/2018 1:40 PM, Horizon68 wrote: > You will say that God doesn't exist, but read the following(read especially > the outer body experience of the 57-year old man below): It's interesting to read scientific articles about what happens after the heart stops beating... but let me tell you the truth. We are all eternal beings. We were created by God in God's own image and likeness. We rebelled against God and we live in the world sown by that rebellion (called 'sin' which is basically just doing something other than what God said). We are all going to spend eternity somewhere. The whole message of the Bible is that God loves you, wants you to still be a part of His creation in eternity, and has made the way out of the final punishment required for an eternal being who will not let go of that rebellion. Jesus came to the Earth to give us that way out. He came to take on our sin (and the resulting punishment for what we did) upon Himself. He did this purposefully, consciously, but choice, be- cause He is God and wants us to be with Him where He is in Heaven. All who come to Him asking forgiveness of their sin are forgiven and they will enter into eternity alive after leaving this world. All who reject Him will face the punishment of their own sin, re- sulting in their being cast into an eternal prison, the eternal equivalent of "life imprisonment for heinous crimes" we see here on Earth. ----- Make no mistake about it. You are comprised of a soul, a body, and a spirit. Your body in this world is not the only you. You are more than that. Your soul is under condemnation, your spirit is dead because of sin, and your body is in corruption (it gets old, gets sick, degrades, has weaknesses, etc.). What God offers us is a full restoration to what He intended be- fore sin entered in and destroyed everything. He offers us for- giveness, a second chance, a way back. He doesn't do this for the angels, though they are greater than we are here in this world. I urge you all to read the Bible objectively, to approach it not as something to be mocked, but as something to be pondered. Read what it teaches you about God, about man, about the sin na- ture of man, about salvation, about damnation, and about eternal life and Heaven. See if you can truly find a flaw with what it teaches. See if you can honestly say it doesn't resonate deeply with you within your core, deep down in your soul. It does that because God has placed it there for all who will be saved, for all who will hear His voice, for all who will leave this world without fear, know- ing where they're going. > Thank you, > Amine Moulay Ramdane. Jesus will forgive you too, Amine. Do you want eternal life? Or do you want to remain in rebellion against God? -- Rick C. Hodgin |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Sep 27 12:58AM +0100 On Mon, 24 Sep 2018 20:35:31 -0000 (UTC) > }; > Both look like an "universal reference" situation, but apparently > the second isn't? 'foo' is a template function whereby each 'T' is a deduced type and so comprises a "universal" (in standard-speak "forwarding") reference. The constructor 'C' is not a template function and it does not perform type deduction (at least in C++11/14, and I don't think that C++17 class template argument deduction magically converts your rvalue references to forwarding references). |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Sep 27 12:58AM +0100 On Mon, 24 Sep 2018 18:49:18 -0000 (UTC) > auto instance = instantiate(a, b, c); > } > //-------------------------------------------------------- It compiles because a, b and c are lvalues. This means that the 'instantiate' function deduces 'Types...' as of type 'int&...' . This means that (i) the 'instance' object is instantiated as of type MyClass<int&, int&, int&>, and (ii) the MyClass constructor for that object is, by reference collapsing, instantiated as constructor MyClass(int&, int&, int&), which thereby takes lvalues as its arguments. |
| Juha Nieminen <nospam@thanks.invalid>: Sep 27 05:32AM > type deduction (at least in C++11/14, and I don't think that C++17 > class template argument deduction magically converts your rvalue > references to forwarding references). If I understand this correctly, what you say there may be technically correct, but I think it's a bit confusing and misleading. You make it sound like there's some special meaning to the foo() function being a template function vs. the C() constructor not being itself a template function (but still depending on template parameters). I don't think there's such a special distinction. As if some special magic is being applied in the former case but not the latter. What's happening is that the C() constructor parameters are whatever was specified by the calling code as 'T'. If the calling code instantiated the class as, for example, C<int, int, int>, then the constructor simply ends up being C(int&&, int&&, int&&), and thus only rvalues can be given to it. If the class had been, somehow, instantiated as C<int&, int&, int&>, then the constructor would end up as being C(int& &&, int& &&, int& &&), which collapses to C(int&, int&, int&), and thus only lvalues can be given to it. For it to work as some sort of "universal constructor", the class would need to be instantiated with template types that are either value types or references, depending on the kind of parameter you want to give the constructor. Although, in a sense, there may be a special meaning to a templated function in particular, when it uses an "rvalue-reference" syntax in its parameters. In this situation the templated type is automatically made to be of reference or non-reference type depending on whether the parameter you are giving to it is an lvalue or an rvalue. This happens automatically when you don't explicitly specify the template parameter types. With the class you have to explicitly specify the template parameter types, so it becomes more complicated. (Is it even possible?) |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Sep 27 11:02AM +0100 On Thu, 27 Sep 2018 05:32:08 -0000 (UTC) > function (but still depending on template parameters). > I don't think there's such a special distinction. As if some special > magic is being applied in the former case but not the latter. I was answering here your non-rhetorical question "Both look like an "universal reference" situation, but apparently the second isn't?". I was explaining that you are correct that "the second isn't" in as non-confusing and direct a way as I could. I answered the other point you make below in my accompanying posting of 23:58:09Z: I was intending you to read them together. The overarching issue is that for there to be a forwarding reference, the function doing the forwarding must be a template function so that reference-collapsing can take place. That is basically it: so there is some "special magic". One consequence is that virtual functions cannot use forwarding. I think it was a mistake to implement forwarding through template function type deduction and reference-collapsing: that seems to me to be an unnecessary mixing of concerns. But it is what C++ does. For what it is worth I also think it is highly confusing to the beginner that the function: template<typename T> void foo(T&&); deduces T to be 'int&' when the function is passed an int lvalue argument and to be 'int' when the function is passed an int rvalue argument. It is not how this works when passed a lvalue template<typename T> void foo(T&); When that is passed an int lvalue it deduces T to be 'int'. > the class as, for example, C<int, int, int>, then the constructor simply > ends up being C(int&&, int&&, int&&), and thus only rvalues can be given > to it. Yes. > then the constructor would end up as being C(int& &&, int& &&, int& &&), > which collapses to C(int&, int&, int&), and thus only lvalues can be > given to it. Also yes (see my other posting). > need to be instantiated with template types that are either value types > or references, depending on the kind of parameter you want to give the > constructor. But in practice you probably don't want to instantiate an object of type C<int&, int&, int&> just because the object is intialized by lvalues. Assuming a case where the C class keeps the initializing ints as member data, you probably want to instantiate an object of type C<int, int, int> whether or not it is initialized with lvalues or rvalues. You probably also want to have a forwarding constructor if C might be instantiated for non-fundamental types as well as ints. The normal way to do both of those is to make the constructor a template function so that it can do forwarding. > automatically when you don't explicitly specify the template parameter > types. With the class you have to explicitly specify the template parameter > types, so it becomes more complicated. (Is it even possible?) I don't understand your question. With C++11/14 you do have to explicitly state the types for which a class template is instantiated. With C++17 there is the option of class template argument deduction. |
| "Öö Tiib" <ootiib@hot.ee>: Sep 27 04:39AM -0700 On Thursday, 27 September 2018 13:02:31 UTC+3, Chris Vine wrote: > through template function type deduction and reference-collapsing: that > seems to me to be an unnecessary mixing of concerns. But it is what C++ > does. Technically compiler generates a family of overloads there, family size grows in exponential relation to number of forwarded parameters and if that is virtual function then all are "used" and each must exist and needs entry in vtable of each derived class. Invisible drain of resources. So we are required to explicitly write all overloads of virtual functions that we need. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Sep 27 01:55PM +0100 On Thu, 27 Sep 2018 04:39:03 -0700 (PDT) > and if that is virtual function then all are "used" and each must > exist and needs entry in vtable of each derived class. Invisible > drain of resources. I agree that that problem lies behind the reason why virtual functions cannot be templated.[1] And you make a good point that because of that, virtual functions could not have been used for generic forwarding anyway. > So we are required to explicitly write all overloads of virtual > functions that we need. If a function has multiple arguments any of which could be rvalues or lvalues there is of course an explosion of lvalue/rvalue permutations which you have to write overloads for. I have wondered whether we could not have had a '&&&' qualifier to indicate something which could be an lvalue or rvalue along these lines: void foo(Car&&&, Bus&&&, Train&&&); // lvalues or rvalues and to have a compiler intrinsic to enable the actual lvalue/rvalue-ness to be obtained further down the call chain to determine whether the objects could be moved from. This would seem to allow multi-argument specific-type forwarding to be used with virtual functions as well. For generic forwarding the equivalent could have been this, with no need for special template deduction rules or reference collapsing rules: template <typename T> void foo(T&&&); // lvalue or rvalue template <typename T> void foo(T&&); // rvalue only template <typename T> void foo(T&); // lvalue only There may be problems with this - I imagine it was thought about - but anyway it won't now happen because C++ has gone down a different route. With C++, for perfect forwarding either you use explicit overloading or you use template functions and reference collapsing. Chris [1] In fact because in the template function signature 'template <typename T> foo(T)' the number of types which can match T is unbounded, the complexity for a templated virtual function would I think be infinite without the compiler carrying out whole program analysis. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Sep 27 03:28PM +0200 On 27.09.2018 13:39, Öö Tiib wrote: > exist and needs entry in vtable of each derived class. Invisible > drain of resources. So we are required to explicitly write all > overloads of virtual functions that we need. That's an argument against templating of virtual functions, not against argument forwarding in itself. It seems to have an assumption of /static type checking/. But if one is satisfied with dynamic type checking, then argument forwarding is quite doable for a virtual function. To examine it more closely I think we should be clear on what argument forwarding MEANS in this context. Is it just forwarding a set of actual arguments, e.g. a virtual function that gets an argument pack as arguments, and calls an overloaded free function F with those arguments? And that can be overridden to e.g. also log this call? That's not so difficult with dynamic type checking, one can e.g. use a sequence of `std::any` instances. -------------------------------------------------------------------------- #include <any> using std::any, std::any_cast; #include <iostream> using std::cout, std::endl; #include <string> using std::string; #include <iterator> using std::begin, std::end; template< class T > using p_ = T*; template< class T > using r_ = T&; class Base { public: // Here nothing is known about types of arguments, or their number, in // a derived class override. virtual void foo( p_<const any> first, p_<const any> beyond ) const = 0; template< class... Args > void pass_to_foo( const Args&... args ) const { const any arg_list[]{ args... }; foo( begin( arg_list ), end( arg_list ) ); } }; class Derived: public Base { public: void foo( p_<const any> first, p_<const any> beyond ) const override { for( auto p = first; p != beyond; ++p ) { if( p->type() == typeid( int ) ) { cout << "int arg: " << any_cast<int>( *p ) << "." << endl; } else if( p->type() == typeid( string ) ) { cout << "string arg: \"" << any_cast<string>( *p ) << "\"." << endl; } else { throw "Uh oh, an argument of a type not supported in Derived."; } } } }; auto main() -> int { using namespace std::literals; r_<const Base> o = Derived(); o.pass_to_foo( "The answer is "s, 0b0101010 ); } -------------------------------------------------------------------------- But, do you also or alternatively require that the top-level call's expression category - lvalue, xvalue or rvalue - for each argument, should be recreated? More involved & difficult, I'd say. Because even the standard library's statically type checked forwarding doesn't manage to do that 100%: -------------------------------------------------------------------------- #include <iostream> using std::cout, std::endl; #include <string> using std::string; #include <utility> using std::forward; template< class E > struct Expression_category{ static auto s() -> string { return "prvalue"; } }; template< class E > struct Expression_category<E&>{ static auto s() -> string { return "lvalue"; } }; template< class E > struct Expression_category<E&&>{ static auto s() -> string { return "xvalue"; } }; #define EC( e ) Expression_category<decltype(( e ))>::s() template< class... Args > void foo( Args&&... args ) { const string msgs[] = { (args + " as an " + EC( forward<Args>( args ) ) )... }; for( string const& m : msgs ) { cout << m << endl; } } auto lval( const string& s ) -> const string& { return s; } auto xval( string&& s ) -> string&& { return move( s ); } auto prval( string s ) -> string { return move( s ); } auto main() -> int { string l = "An lvalue expression!"; string x = "An xvalue expression!"; string p = "A prvalue expression!"; cout << EC( lval( l ) ) << endl; cout << EC( xval( move( x ) ) ) << endl; cout << EC( prval( p ) ) << endl; cout << endl; cout << "Calling foo:" << endl; foo( lval( l ), xval( move( x ) ), prval( p ) ); } -------------------------------------------------------------------------- Output with MinGW g++ 7.3: lvalue xvalue prvalue Calling foo: An lvalue expression! as an lvalue An xvalue expression! as an xvalue A prvalue expression! as an xvalue ... where the last two lines are the same expression category. Not sure how to deal with that even on its own. Cheers!, - Alf |
| "Öö Tiib" <ootiib@hot.ee>: Sep 27 08:52AM -0700 On Thursday, 27 September 2018 16:28:38 UTC+3, Alf P. Steinbach wrote: > argument forwarding is quite doable for a virtual function. > To examine it more closely I think we should be clear on what argument > forwarding MEANS in this context. With forwarding I meant we hypothetically want to accept any arguments (lvalue, xvalue, or prvalue) to our callable. It matters to us are those safe to move from, unsafe to move from (but mutable) or impossible to move from (since immutable). Often we just want to forward that to things that our hypothetical callable calls. And all the point of perfection is to do least amount of copies or moves on the way. > function F with those arguments? And that can be overridden to e.g. also > log this call? That's not so difficult with dynamic type checking, one > can e.g. use a sequence of `std::any` instances. I suspect that this throws our baby (efficiency of templates) away with washing water (any) here. But on the other hand option to have JIT compiling and mutable hashtables of members instead of fixed vtable of class for to have virtual function templates but not to pay for what we don't use is also perhaps too lot to request. ;) > should be recreated? More involved & difficult, I'd say. Because even > the standard library's statically type checked forwarding doesn't manage > to do that 100%: Yes, but that is likely not a problem when prvalue (movable from) is turned into xvalue (also movable from) by forwarding. |
| "Öö Tiib" <ootiib@hot.ee>: Sep 27 10:08AM -0700 On Thursday, 27 September 2018 15:55:59 UTC+3, Chris Vine wrote: > cannot be templated.[1] And you make a good point that because > of that, virtual functions could not have been used for generic > forwarding anyway. Yes, my point was that even when implementation does full program analysis of all potential yo-yo of virtual calls then what we face can be still quite a combination explosion. Also I can't imagine manually writing unit tests for such stuff. :D > anyway it won't now happen because C++ has gone down a different > route. With C++, for perfect forwarding either you use explicit > overloading or you use template functions and reference collapsing. I have thought about it in other way. On one hand the "by RVO" ("OUT") parameter passing is actually unavailable, we have really to return into that hidden parameter. On other hand there are by value ("SINK-IN"), by reference ("IN-OUT"), by rvalue reference ("MOVE-IN") and by reference to const ("IMMUTABLE-IN") parameters. So if we could leave the choice between "SINK-IN", "MOVE-IN" and "IMMUTABLE-IN" parameters up to implementation to choose and optimize then we would just have two types of parameters ("IN" and "IN-OUT") left and all the concern about move, copy or forward gone. ;) |
| ram@zedat.fu-berlin.de (Stefan Ram): Sep 27 12:34AM >corresponding function call argument is an lvalue, the type "lvalue >reference to the type of the argument" is used in place of the type >of the argument for deduction. This quotation from N4762 says something similar to the text quoted above, which was not quoted from N4762: |If P is a forwarding reference and the argument is an lvalue, |the type "lvalue reference to A" is used in place of A for |type deduction. N4762 12.9.2.1 Deducing template arguments from a function call [temp.deduct.call] p3 s4 >>apparently the second isn't? >Yes, because the second template does not directly precede >the function. The quotation from N4762 for this: |A forwarding reference is an rvalue reference to a |cv-unqualified template parameter that does not represent a |template parameter of a class template N4762 12.9.2.1 Deducing template arguments from a function call [temp.deduct.call] p3 s3 ("represent" might be vague above. Maybe they should use "is not" instead of "does not represent"?) (However, when one has a class template and uses a type inferred as a type argument as discussed in this thread, the resulting behavior resembles a forwarding reference to some extend.) >MyClass( int & &&, int & &&, int & && ) {} >and, IIRC, this is reduced to >MyClass( int &, int &, int & ) {} Not sure where to get this from, but I believe it might be: |If P and A are function types that originated from |deduction when taking the address of a |function template (12.9.2.2) or when deducing template |arguments from a function declaration (12.9.2.6) and |Pi and Ai are parameters of the top-level |parameter-type-list of P and A, respectively, Pi is adjusted |if it is a |forwarding reference (12.9.2.1) and Ai is an lvalue |reference, in which case the type of Pi is changed to be the |template parameter type (i.e., T&& is changed to simply T). N4762 12.9.2.5 Deducing template arguments from a type [temp.deduct.type] p10 But the use of "forwarding reference" is too special in there, because this happens with all rvalue parameters. E.g., main.cpp #include <iostream> #include <ostream> #include <string> using namespace ::std::literals; template< typename T >struct C { static void f( T && no_forwarding_reference ) { ::std::cout << __PRETTY_FUNCTION__ << '\n'; no_forwarding_reference = 1; } }; int main() { int n {}; ::C< int& >::f( n ); ::std::cout << n << '\n'; } transcript static void C<T>::f(T&&) [with T = int&] 1 |
| ram@zedat.fu-berlin.de (Stefan Ram): Sep 27 12:45AM >>and, IIRC, this is reduced to >>MyClass( int &, int &, int & ) {} >Not sure where to get this from, but I believe it might be: Or is it: |If a typedef-name (9.1.3, 12.1) or a decltype-specifier |(9.1.7.2) denotes a type TR that is a reference to a type |T, an attempt to create the type "lvalue reference to cv TR" |creates the type "lvalue reference to T", while an attempt to |create the type "rvalue reference to cv TR" creates the type TR. 9.2.3.2 References [dcl.ref] p6 ? Not sure whether a template parameter is a typedef-name or a decltype-specifier! |
| ram@zedat.fu-berlin.de (Stefan Ram): Sep 27 12:32PM >Not sure whether a template parameter is a typedef-name >or a decltype-specifier! It's a typedef-name! |A type-parameter whose identifier does not follow an ellipsis |defines its identifier to be a typedef-name (if |declared without template) or template-name (if declared with |template) in the scope of the template declaration. N4762 12.1 Template parameters [temp.param] p3 s1 |
| ram@zedat.fu-berlin.de (Stefan Ram): Sep 27 01:51PM Below one can find a function template spezialization for f and a plain overload for g. (As I would call them, I am not sure whether these are correct designations.) Is there any difference in meaning or effect? main.cpp #include <iostream> #include <ostream> template< typename T >void f( T ){ ::std::cout << "unknown" << '\n'; } template<> void f( double ){ ::std::cout << "double" << '\n'; } template< typename T >void g( T ){ ::std::cout << "unknown" << '\n'; } void g( double ){ ::std::cout << "double" << '\n'; } int main() { f( 100 ); f( 1.0 ); g( 100 ); g( 1.0 ); } transcript unknown double unknown double |
| bitrex <user@example.net>: Sep 26 09:29PM -0400 On 09/22/2018 01:50 PM, Christian Gollwitzer wrote: > I think he wanted to mean it the proposed meaning with short circuiting > on the second comparison. For floating point, it would do this if the > "false" is replaced by either -Inf or NaN. * Ya something like that :) > * I don't recall how to create thise special things from C++, why aren't > they accepted as floating point literals like this, instead of > std::mumble<ugly_template>::infinity() ? This should return false if the set is not a strict monotonic-increasing ordering, and the greatest element if it is, with C++11-compliant one-line constexprs. It seems correct but I haven't thoroughly tested maybe y'all could double-check it for errors: #include <iostream> template <typename T> constexpr auto compare(T a) -> decltype(a) { return a; } template <typename T> constexpr auto compare(T a, T b) -> decltype(compare(a > 0 ? (a < b ? b : false) : (a < b ? a : false))) { return compare(a > 0 ? (a < b ? b : false) : (a < b ? a : false)); } template <typename T> constexpr auto compare(T a, T b, T c) -> decltype(compare((compare(a, b)) ? compare(b, c) : false)) { return compare((compare(a, b)) ? compare(b, c) : false); } template <typename T, typename... Rest> constexpr auto compare(T a, T b, T c, Rest... rest) -> T { return compare(compare(a, b), c, compare(rest...)); } int main() { /* Bad Fib */ std::cout << compare(1, 2, 3, 5, 8, -13, 21, 34, 55) << std::endl; /* Good Fib */ std::cout << compare(1, 2, 3, 5, 8, 13, 21, 34, 55) << std::endl; } |
| Tim Rentsch <txr@alumni.caltech.edu>: Sep 26 04:35PM -0700 >> This reasoning is flawed in several respects. However since >> the subject is off-topic I will say nothing further. > I wasn't intending to harm anyone. [...] It wasn't your reasoning I was talking about. IMO there is nothing wrong with your asking if someone would be willing to give the talk/demo in your place because you have decided not to go, no matter what your reasons for not going are. If you knew of some specific information that might change someone's mind about going and didn't disclose it then I might have a different reaction, but AFAICS that is not the case here. Whether your reasoning for not going makes sense to me or not, that has no bearing (IMO, in case that needs saying) on the okayness of your asking if someone else will go in your place. |
| 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