- Difference between array and pointer - arguments - 1 Update
- mixing compilers (g++ but Intel others)? - 14 Updates
- Difference between array and pointer - arguments - 1 Update
- expected identifier before 'this'? - 6 Updates
- Not fixing the type of a non-type template parameter - 3 Updates
| ram@zedat.fu-berlin.de (Stefan Ram): May 02 03:02PM >A more generic version could be: >template<std::size_t N> >void foo(char (&a)[N]) { ... } Yeah, Herb Sutter on 2015-09-22 said/wrote (CppCon day 2): »Don't use array-to-pointer decay.«. And »use array_view«. |
| Jerry Stuckle <jstucklex@attglobal.net>: May 01 09:08PM -0400 On 5/1/2016 7:08 PM, Ian Collins wrote: >>> citing evidence. >> And you are not keen on admitting you're wrong. > Where was he wrong? Because he said it couldn't be done. And now he's trying to change the rules. It doesn't work. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: May 01 09:14PM -0400 On 5/1/2016 6:15 PM, David Brown wrote: > Usenet posters if I could supply a copy of the HPC compiler (I couldn't, > as I was unable to get a response from the copyright holders when I > asked for permission). And you're just proving once again you are nothing more than a pedantic troll. I can find compilers which don't even support ANSI C - much less any later standard. Just because you are using outdated and unsupported software means nothing. > Now you are beginning to get the hang of it! However, the endian.c > program is totally irrelevant for cross-compiling. One day, perhaps, > you will open your mind enough to learn something new. You said nothing about cross-compiling. But once again, rather than admit you are wrong, you try to change the rules. But that's what trolls do. It doesn't work. >> line. > Most do, especially modern ones, - but some don't. It's really quite > simple. And which CURRENTLY SUPPORTED ones don't? > And of course you "solution" wouldn't work on any of them. But then once again I gave you an alternative - which you conveniently ignore because you won't admit you're wrong. >> standard - it is part of the compiler operation. That is not defined by >> the standard. > Correct - and thus your method fails to fulfil the challenge. And exactly which of the C standards did I violate? The answer is - NONE. But then you can't admit you are wrong. And changing the rules doesn't work. > implementation-independent way using nothing but what is required by the > standards? After all, you agree that running programs is not defined by > the standard. I agreed that passing a parameter to the compiler is not covered by the standard. But it also does not violate any standard. If it does, show which one. > I suppose it would have been helpful if I had made this clearer in the > challenge - I thought it was obvious. No, you made a challenge and I gave you an answer. You can't change the rules after the fact. But you try to do that rather than admit you are wrong - which is what trolls do. >> you'll keep trying instead of admitting I showed you how to do something >> you claimed couldn't be done. >> And that's why you'd never make it as a consultant. You would have been much better off just admitting you were wrong. Your continued attempts to change the rules and/or ignore other suggestions I made just makes you look like a fool. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Ian Collins <ian-news@hotmail.com>: May 02 02:15PM +1200 On 05/02/16 13:08, Jerry Stuckle wrote: >> Where was he wrong? > Because he said it couldn't be done. And now he's trying to change the > rules. Where? Not in this thread. -- Ian Collins |
| Ian Collins <ian-news@hotmail.com>: May 02 02:24PM +1200 On 05/02/16 13:14, Jerry Stuckle wrote: > You said nothing about cross-compiling. But once again, rather than > admit you are wrong, you try to change the rules. But that's what > trolls do. David said "There is no implementation-independent way to do this in C or C++". Cross compilers are implementations. -- Ian Collins |
| Jerry Stuckle <jstucklex@attglobal.net>: May 01 11:30PM -0400 On 5/1/2016 10:15 PM, Ian Collins wrote: >> Because he said it couldn't be done. And now he's trying to change the >> rules. > Where? Not in this thread. No, over on c.l.c where the thread started. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: May 01 11:32PM -0400 On 5/1/2016 10:24 PM, Ian Collins wrote: >> trolls do. > David said "There is no implementation-independent way to do this in C > or C++". Cross compilers are implementations. Cross-compilation was not part of the original requirement. But you wouldn't know, would you? You're too interested in trying to prove me wrong to accept the fact I solved the problem. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Ian Collins <ian-news@hotmail.com>: May 02 04:12PM +1200 On 05/02/16 15:32, Jerry Stuckle wrote: >> David said "There is no implementation-independent way to do this in C >> or C++". Cross compilers are implementations. > Cross-compilation was not part of the original requirement. Implementation-independent was part of the requirement and cross compilers are implementations. Therefore the proposed solution doesn't meet the original requirement. -- Ian Collins |
| Gareth Owen <gwowen@gmail.com>: May 02 07:51AM +0100 > Cross-compilation was not part of the original requirement. But you > wouldn't know, would you? No one is interested in proving you wrong. Everyone but you is aware that this has already been accomplished. Now they're just having fun watching you twist in the wind. > You're too interested in trying to prove me wrong to accept the fact I > solved the problem. Unless the you have a TI C2000 in which case you need a *similar but different* piece of code. |
| Jerry Stuckle <jstucklex@attglobal.net>: May 02 09:11AM -0400 On 5/2/2016 12:12 AM, Ian Collins wrote: > Implementation-independent was part of the requirement and cross > compilers are implementations. Therefore the proposed solution doesn't > meet the original requirement. Show where it violates the C standard. And cross-compilation, by definition, is implementation specific. It is not part of the C standard, and not supported by all compilers. But that was not in the original rules. You are also just trying to change the rules rather than admit I'm right. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: May 02 09:13AM -0400 On 5/2/2016 2:51 AM, Gareth Owen wrote: > No one is interested in proving you wrong. Everyone but you is aware > that this has already been accomplished. Now they're just having fun > watching you twist in the wind. Then why are people trying to change the rules *after the fact*? I'm not twisting in the winds. I'm just standing by the solution to the rules *as given*. But I know there are a bunch of trolls here who refuse to admit I'm right. >> solved the problem. > Unless the you have a TI C2000 in which case you need a > *similar but different* piece of code. So, adapt as necessary. About the only code you can get to work without change across all processors and all compilers is "Hello World". And that may not even work in all cases. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Gareth Owen <gwowen@gmail.com>: May 02 02:38PM +0100 > Then why are people trying to change the rules *after the fact*? I'm > not twisting in the winds. I'm just standing by the solution to the > rules *as given*. Nobody believes this except you. > So, adapt as necessary. The requirements where that you didn't have to "adapt as necessary", depending on the platform or compiler. That was the whole point of the exercise. > About the only code you can get to work without change across all > processors and all compilers is "Hello World". So you walk back your claims that the code works across all compilers and platforms? > And that may not even work in all cases. Nobody believes this except you. |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: May 02 02:52PM +0100 >> solved the problem. > Unless the you have a TI C2000 in which case you need a > *similar but different* piece of code. Or anyone running the Unysis MCP C implementation where short (and indeed all the other integer types) have 9 non-value padding bits. Or on a PDP-11 which is mixed endian. This whole exchange is absurd. Using a union to examine the representation of a value is the standard way to do this and had Jerry just said that this standard solution is a sound engineering compromise for the vast majority systems anyone cares about, that would be the end of it. -- Ben. |
| David Brown <david.brown@hesbynett.no>: May 02 04:16PM +0200 On 02/05/16 15:52, Ben Bacarisse wrote: > just said that this standard solution is a sound engineering compromise > for the vast majority systems anyone cares about, that would be the end > of it. The union method (suitably corrected) is a standard way to handle run-time detection of endianness. But sometimes you want compile-time detection. The common ways of doing this are to rely on compiler pre-processor symbols (either explicitly, or via something like boost), to rely on knowledge of the actual targets in use (often you know this), or to use something like autoconfig for native code. All of these are practical and sound engineering, and all are commonly known - as are their limitations. The weird thing was Jerry's claim that he had a marvellous implementation-independent, universal compile-time solution providing an ideal answer - and that anyone who says otherwise is "stoopid", "would never make it as a consultant", and is a troll. Originally, I had genuinely thought that there was a chance (a small one, but a chance nonetheless) that he had a trick that I didn't know about here. |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: May 02 03:58PM +0100 > On 02/05/16 15:52, Ben Bacarisse wrote: <snip> > Originally, I had genuinely thought that there was a chance (a small > one, but a chance nonetheless) that he had a trick that I didn't know > about here. I didn't. I thought it was a "bar bet" based on enough vague terms to permit a helper program a la autoconf. That view makes everything computable at compile time, so I don't think it makes sense to use the term like that, but I hate arguing over what someone meant. I knew what *you* meant by a compile-time test and that it did not include a separate program. In that vein (of tricks that might allow it), there is a curious fact that might be of interest. Multi-character constants are totally implementation defined, but it's been my experience that, in practice, they reflect endianness so you can write '\x01\02' == 0x102 (or == 0x201) as a compile-time test. With a more complex expression you also test for longer types in case int has a different endianness to short. I've never used this in rel code since there is no guaranteed that is works but I don't recall any implementation where it wouldn't. It would be fun if anyone reading this who has access to odd C compilers could try it out. -- Ben. |
| Cholo Lennon <chololennon@hotmail.com>: May 02 11:37AM -0300 On 04/28/2016 08:44 PM, JiiPee wrote: >> 'a' retains its quality as a reference to an array of char of size 4, >> and it will refuse to compile if passed a char array of any other size. > interesting.. good to know A more generic version could be: template<std::size_t N> void foo(char (&a)[N]) { ... } To avoid code duplication due to multiple instantiations of foo (for every array size) you could forward foo to an internal function: void internal_foo(char* a, std::size_t size); template<std::size_t N> void foo(char (&a)[N]) { internal_foo(a, N); } Regards -- Cholo Lennon Bs.As. ARG |
| "Heinz-Mario Frühbeis" <Div@Earlybite.individcore.de>: May 02 08:47AM +0200 Hi, here I'm using a class within a class, or better, I want to use a class within a class in this way: class Test{ private: class Test1{ public: Test *mTest; Test1(Test *vTest){ mTest = vTest; } }; Test1 mTest1(this); // <--- here is this error }; One explanation is: expected identifier before 'this' And another is: expected ',' or '...' before 'this' And to get me a little more confused..., this is compiling: class Test{ private: class Test1{ public: Test *mTest; Test1(Test *vTest){ mTest = vTest; } }; Test1 mTest1(); // <--- no error anymore? }; What is wrong? What is right? Regards Heinz-Mario Frühbeis |
| Ian Collins <ian-news@hotmail.com>: May 02 07:21PM +1200 On 05/02/16 18:47, Heinz-Mario Frühbeis wrote: > } > }; > Test1 mTest1(this); // <--- here is this error To initialise a non static member, that would have to be Test1 mTest1 {this}; -- Ian Collins |
| "Heinz-Mario Frühbeis" <Div@Earlybite.individcore.de>: May 02 09:59AM +0200 Am 02.05.2016 um 09:21 schrieb Ian Collins: >> Test1 mTest1(this); // <--- here is this error > To initialise a non static member, that would have to be > Test1 mTest1 {this}; This is compiling, thank you, thank you very much! But, this is raising warnings and (naturally) another issue: /media/.../ida_login/c_idasection.h:163: Warnung: non-static data member initializers only available with -std=c++11 or -std=gnu++11 [enabled by default] c_Areas mAreas{this}; ^ /media/.../ida_login/c_idasection.h:163: Warnung: extended initializer lists only available with -std=c++11 or -std=gnu++11 [enabled by default] c_Areas mAreas{this}; ^ Here, I'm using QT Creator 3.0.1 Based on QT 5.2.1 (from my About dialog). And on this site <http://stackoverflow.com/questions/16948382/how-to-enable-c11-in-qt-creator> I can read 'use CONFIG += c++11', but that isn't working for me... But ok so far, thanks again and with ragards Heinz-Mario Frühbeis |
| Reinhardt Behm <rbehm@hushmail.com>: May 02 04:11PM +0800 Heinz-Mario Frühbeis wrote: > Here, I'm using QT Creator 3.0.1 Based on QT 5.2.1 (from my About dialog). > And on this site > <http://stackoverflow.com/questions/16948382/how-to-enable-c11-in-qt- creator> > I can read 'use CONFIG += c++11', but that isn't working for me... Your qmake seems to be too old for this. Use instead or something similar: QMAKE_CXXFLAGS += -std=gnu++11 . -- Reinhardt |
| "Heinz-Mario Frühbeis" <Div@Earlybite.individcore.de>: May 02 01:01PM +0200 Am 02.05.2016 um 10:11 schrieb Reinhardt Behm: > Use instead or something similar: > QMAKE_CXXFLAGS += -std=gnu++11 > . No, sir, its not working. What is working is, if I declare as 'new': Test1 *mTest1; And e.g. in the constructor-function: this->mTest1 = new Test1(this); ... But thanks. Regards Heinz-Mario Frühbeis |
| "Heinz-Mario Frühbeis" <Div@Earlybite.individcore.de>: May 02 01:25PM +0200 Am 02.05.2016 um 13:01 schrieb Heinz-Mario Frühbeis: >> Use instead or something similar: >> QMAKE_CXXFLAGS += -std=gnu++11 >> . BREAK BREAK BREAK - TIMEOUT :) Oh, man, I wrote Test1 mTest1(this);, instead of Test1 mTest1{this};. Exuse me, sir! So, yes, it is working now! Thank you very much, sir. Regards Heinz-Mario Frühbeis |
| Juha Nieminen <nospam@thanks.invalid>: May 02 07:08AM Non-type template parameters can be used for example like this: template<int N> class Test { ... }; However, this fixes that non-type parameter to be of type int. Is it in any way possible to make the instantiating code decide what that type actually is? In other words, rather than the template itself, it's the insantiating code that decides whether it's an int, and unsigned, or something else. In other words, these would be different: Test<5> test1; Test<5U> test2; Test<5LL> test3; --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| Ondra Holub <ondra.holub@post.cz>: May 02 01:02AM -0700 Dne pondělí 2. května 2016 9:09:05 UTC+2 Juha Nieminen napsal(a): > Test<5> test1; > Test<5U> test2; > Test<5LL> test3; I do not know any nice way. You can do this: template<typename T, T VALUE> struct X { static const T Value = VALUE; }; To make it easier, you can define wrapping macro: #define MAKE_X(val) X<std::decay<decltype(val)>::type, (val)> MAKE_X(20) x1; MAKE_X('a') x2; MAKE_X(L'a') x3; MAKE_X(0ULL) x4; std::cout << sizeof(x1.Value) << '\n'; std::cout << sizeof(x2.Value) << '\n'; std::cout << sizeof(x3.Value) << '\n'; std::cout << sizeof(x4.Value) << '\n'; For integral types it should work in C++11. |
| Ondra Holub <ondra.holub@post.cz>: May 02 01:07AM -0700 Dne pondělí 2. května 2016 9:09:05 UTC+2 Juha Nieminen napsal(a): > Test<5> test1; > Test<5U> test2; > Test<5LL> test3; Of course, std::decay is not needed, just #define MAKE_X(val) X<decltype(val), (val)> should be enough :-) |
| 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