- "Death to C, ++" - 9 Updates
- implicit conversions and parameter packs - 4 Updates
| Jerry Stuckle <jstucklex@attglobal.net>: Aug 04 11:01PM -0400 On 8/4/2017 5:26 PM, Mr Flibble wrote: > So as you can see I am correct and you are wrong: Java uses pointers; > deal with it. > /Flibble No, you don't understand what they are saying. C++ has both references and pointers. Java references act like C++ references. What happens under the covers - which is what they are talking about - is of no importance. Let's see you set a Java "pointer" to 0x12345678. If it's a pointer, you can do it. If it's a reference, you cannot. Deal with it. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Aug 04 11:03PM -0400 On 8/4/2017 7:09 PM, Manfred wrote: >> used without that constant 'new' spam of Java): >> int a = '1'; >> char b = (char) a; You're correct in one respect. The Java references are more like handles than memory addresses. There is no requirement that they point to a memory location. They just have to identify the object they reference. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 05 05:28AM +0200 On 05.08.2017 05:01, Jerry Stuckle wrote: > What happens under the covers - which is what they are talking about - > is of no importance. Let's see you set a Java "pointer" to 0x12345678. > If it's a pointer, you can do it. If it's a reference, you cannot. Do you think you can do that with a Pascal pointer? Also, if God is so great an engineer, why did he mistakenly create the foreskin so that he had to ask humans to remove it themselves? Not to mention the appendix? Cheers!, & hth., - Alf |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 04 11:36PM -0500 > is of no importance. Let's see you set a Java "pointer" to 0x12345678. > If it's a pointer, you can do it. If it's a reference, you cannot. > Deal with it. Wrong again. The virtual machine spec deals with what happens under the covers and what I quoted from was the language spec so Java does use pointers; deal with it. /Flibble |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Aug 05 08:01AM On Thu, 2017-07-20, James Kuyper wrote: ... > features for everyone to become fully familiar with all of them in a > reasonable amount of time. Everyone seems to program in their own chosen > subset of C++, and to be confused by code which uses a different subset. I don't think the subsets themselves are the problem. There are dark corners of the C++ language, but they are to me neither important nor dangerous. But C++ allows you to choose from many different designs for the same problem, and there's no consensus about which one is best. You also get people with different backgrounds; C++ programmers who (like me) come from C and those who come from Java will have a hard time agreeing about anything. Also, the fashion-of-the-month ideas affects C++ more than C. Not that I believe there is a single way everyone thinks about C ... /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Jerry Stuckle <jstucklex@attglobal.net>: Aug 05 11:32AM -0400 On 8/4/2017 11:28 PM, Alf P. Steinbach wrote: >> is of no importance. Let's see you set a Java "pointer" to 0x12345678. >> If it's a pointer, you can do it. If it's a reference, you cannot. > Do you think you can do that with a Pascal pointer? I don't remember. I haven't done any Pascal in over 30 years. > Also, if God is so great an engineer, why did he mistakenly create the > foreskin so that he had to ask humans to remove it themselves? Who said it has to be removed? A lot of men still have their foreskins. > Not to mention the appendix? Which is now postulated to have a real purpose - a storage area for good microbes for the gut. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Aug 05 11:34AM -0400 On 8/5/2017 12:36 AM, Mr Flibble wrote: > covers and what I quoted from was the language spec so Java does use > pointers; deal with it. > /Flibble No, this happens under the covers. A Java reference is not necessarily a memory address. It is closer to a handle to the object (which also has the advantage of making the object relocatable). And once again - show me how you can set your Java "pointer" to 0x12345678. Deal with it. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Chris Ahlstrom <OFeem1987@teleworm.us>: Aug 05 11:24AM -0400 Alf P. Steinbach wrote this copyrighted missive and expects royalties: > Also, if God is so great an engineer, why did he mistakenly create the > foreskin so that he had to ask humans to remove it themselves? Heh. -- A banker is a fellow who lends you his umbrella when the sun is shining and wants it back the minute it begins to rain. -- Mark Twain |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 05 07:33PM +0100 On 05/08/2017 16:34, Jerry Stuckle wrote: >> /Flibble > No, this happens under the covers. The quote was from the language spec not the JVM spec so the *language* uses pointers. A Java reference is not necessarily > a memory address. It is closer to a handle to the object (which also > has the advantage of making the object relocatable). How it is implemented "under the hood" is irrelevant as far as high level language abstractions are concerned and the abstraction Java uses is the pointer. > And once again - show me how you can set your Java "pointer" to 0x12345678. You seem to be confusing Java pointers with C/C++ pointers. Pointers from one language can have a subset of the features of pointers of another language. Nobody claimed you could set a Java pointer to a physical address but you can set it to point at an object or you can set it to null. > Deal with it. As well as being fractally wrong you are also fractally obtuse. Deal with it. /Flibble |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Aug 05 10:32AM +0200 I have the problem that implicit conversion, e.g. for CV qualifiers do not always work with parameter packs. The following code demonstrates the problem: #include <cstring> #include <cstdio> #include <cerrno> using namespace std; template <typename ...ARGS> struct MessageTemplate { const char* Text; constexpr MessageTemplate(const char* text) : Text(text) {} void print(ARGS... a) const { printf(Text, a...); } }; template <typename ...ARGS> void printMessage(const MessageTemplate<ARGS...> msg, ARGS... a) { printf(msg.Text, a...); } static const MessageTemplate<const char*, const char*> OPENFAILED("Failed to open file '%s': %s"); const char* filename = "Does not exist"; int main() { FILE* f = fopen(filename, "r"); if (f == NULL) { // works OPENFAILED.print(filename, strerror(errno)); // does not work printMessage(OPENFAILED, filename, strerror(errno)); return 1; } // ... return 0; } The strerror function returns char* rather than const char* (for compatibility reasons). When passed to the member function print() the implicit conversion to const char* takes place while when calling the free function printMessage() it does not. I get a compiler error (gcc 4.8.4) test3.cpp: In function ´int main()´: test3.cpp:29:55: error: no matching function for call to ´printMessage(const MessageTemplate<const char*, const char*>&, const char*&, char*)´ printMessage(OPENFAILED, filename, strerror(errno)); ^ test3.cpp:29:55: note: candidate is: test3.cpp:16:6: note: template<class ... ARGS> void printMessage(MessageTemplate<ARGS ...>, ARGS ...) void printMessage(const MessageTemplate<ARGS...> msg, ARGS... a) ^ test3.cpp:16:6: note: template argument deduction/substitution failed: test3.cpp:29:55: note: inconsistent parameter pack deduction with ´const char*´ and ´char*´ printMessage(OPENFAILED, filename, strerror(errno)); ^ The same applies to other implicit conversions like int -> long. Why does it not work in this case? And is there a work around other than casting every argument to the exact type on any invocation? Marcel |
| Barry Schwarz <schwarzb@dqel.com>: Aug 05 08:19AM -0700 On Sat, 05 Aug 2017 10:32:09 +0200, Marcel Mueller >Why does it not work in this case? >And is there a work around other than casting every argument to the >exact type on any invocation? In the first case, the compiler knows that OPENFAILED is an instance of the template with two const pointers. The compiler does not have to create a function named print. That function was already created when OPENFAILED was defined. Since there is an implicit conversion from char* to const char*, the compiler has no problem performing the conversion. If, as an example, you change the argument from strerror(errno) to errno, you will not get the no matching function error you receive in the second case. Instead you will get an incompatible argument error since OPENFAILED.print cannot accept an integer as the second argument. In the second case, the same typename (ARGS) is used for both template parameters in the declaration of printMessage. The presence of OPENFAILED as the fist argument of the function call forces the ARGS to be <const char*, const char*> for both parameters. The compiler cannot use this template to generate an instance of the function since the arguments corresponding to parameter a do not both have type const char*. Changing the third argument as described above would produce the same message. It has nothing to do with the existence, or not, of an implicit conversion. If you change the template from ARGS and ARGS to ARGS1 and ARGS2 and use ARGS2 for parameter a, the compiler error disappears. -- Remove del for email |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Aug 05 06:42PM +0200 On 05.08.17 17.19, Barry Schwarz wrote: > an implicit conversion. If you change the template from ARGS and ARGS > to ARGS1 and ARGS2 and use ARGS2 for parameter a, the compiler error > disappears. Hmm, doesn't this disable the type check? Just tested, it does. With two distinct parameter packs you can pass whatever you want, e.g. errno. This will crash the program. So it is not an option. OK I could work around this by forwarding the call to MessageTemplate::print, but this is not an option either as it requires a member function for every future function that deals with the template and the matching parameters. (This is the idea behind the scenes, to have different implementations.) Marcel |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 05 07:52PM +0200 On 05.08.2017 10:32, Marcel Mueller wrote: > I have the problem that implicit conversion, e.g. for CV qualifiers do > not always work with parameter packs. It's not about parameter packs, it's just about template argument deduction. The only implicit conversions that are applied are Derived -> Base, because that's logically an IS-A relationship. > // ... > return 0; > } Here's a much simpler example: template< class Type > struct Type_carrier {}; template< class Arg > void foo( Type_carrier<Arg>, Arg ) {} auto main() -> int { foo( Type_carrier<bool const>{}, bool{} ); //! Nyet, ambiguous! } You might say, WTF!?, doesn't it /understand/ that a `bool` can be used where a `bool const` is expected, huh? It doesn't. > [snip] > And is there a work around other than casting every argument to the > exact type on any invocation? The usual workaround for this kind of problem is to just let the interface's argument type be unconstrained, and convert explicitly in the implementation the way that you want it, like this: template< class Type > struct Type_carrier {}; template< class Arg > void foo_impl( Type_carrier<Arg>, Arg ) {} template< class Arg1, class Arg2 > void foo( Type_carrier<Arg1> t, Arg2 a ) { foo_impl<Arg1>( t, a ); } auto main() -> int { foo( Type_carrier<bool const>{}, bool{} ); } Cheers!, - ALf |
| 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