- Implicit conversion error with conversion operator - 1 Update
- I have just revolutionized computing - 2 Updates
- EXAMPLE - 1 Update
- Virtual functions - 1 Update
| Andrey Tarasevich <andreytarasevich@hotmail.com>: Apr 26 12:59PM -0700 On 4/23/2018 2:58 AM, Juha Nieminen wrote: > const Foo foo = Bar(); > //------------------------------------------------------------ > When I try to compile it with (a recent version of) clang, I get the error: Implicit conversion sequences in C++ are allowed include at most _one_ user-defined conversion. In your initialization above you are expecting _two_ user-defined conversions to take place: Bar-to-Coords and Coords-to-Foo. This is not allowed. -- Best regards, Andrey Tarasevich |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 26 06:12PM +0200 Am 25.04.2018 um 02:30 schrieb Sky89: > and bound and unbound and they are suited for Real-time systems. > I will sell them to Google or/and to Microsoft or/and to other software > companies.. You must have megalomania. No one needs your tiny algorithms. Google and MS can implement them in half a day less buggy than you. |
| James Moe <jimoeDESPAM@sohnen-moe.com>: Apr 26 11:25AM -0700 On 04/25/2018 01:55 PM, Alf P. Steinbach wrote: >> ROTL! > Rolling on the laughter? What? It is difficult to type and roll at the same time. ROTFL. -- James Moe jmm-list at sohnen-moe dot com Think. |
| Tim Rentsch <txr@alumni.caltech.edu>: Apr 26 09:47AM -0700 > But I suppose you must /switch/ between them, not keep them all in > your head at once. The code should help the reader to stay at one > layer of abstraction at a time. Good analogy. I don't think of levels/layers of abstraction and levels of detail as exactly the same thing, but the basic idea is the same: the scope under consideration must be kept small enough so we can hold it all in our head at once; then when we're done understanding this function, we can switch to looking at a different function. |
| Tim Rentsch <txr@alumni.caltech.edu>: Apr 26 09:34AM -0700 Tiib writes: > I think that example illustrates well what is the core issue of > your disagreement. I see that both of you talk correctly about > somewhat overlapping terms. Hmmm, maybe. See below. > Note now that also "template specialization" is term usually used > in specific to C++ manner. I meant it specifically in the C++ sense. It didn't occur to me that anyone would take it any other way. > generic type". Some of that is resolved in several other > programming languages (that have generics or templates but also > have dynamic types) dynamically. Whether something is resolved statically or dynamically doesn't affect what kind of polymorphism is involved. We might say "ad hoc polymorphic generics", to contrast with "ad hoc polymorphic functions" (ie, overloading). The distinction between generics and functions says what kinds of /things/ are polymorphic, but that doesn't change what kind of /polymorphism/ is involved. > In general programming we can say if it is "ad hoc > polymorphism", "parametric polymorphism" or "subtype > polymorphism". Yes, if it is one of those. There are other kinds of polymorphism. > static or dynamic, but that also leaves reasons behind > those choices unclear. Feels like difference in semantic > constraints, look and feel, basically matter of taste. I think you may have missed what I was trying to say earlier. I'm not saying the difference between static binding and dynamic binding is unimportant. Obviously it is important. My point though is that it lies on an independent axis from what kind of polymorphism is involved. If a virtual function call can be resolved statically (which sometimes happens), we still call it subtype polymorphism. Similarly, if we see m[2] = 7; and m[k] = 7; we don't call one assignment "static indexing" and the other assignment "dynamic indexing". They are both just indexing, with staticness/dynamicness on an independent axis. > "run-time". Because of that local focus to actual reality we > talk about "static polymorphism" and "dynamic polymorphism" > in C++. At some level this influence is what I've been trying to point out. In the C++ community there seems to be a tendency to use C++-centric terminology, without much weight given to how terminology is used in the larger community. If that is true there is no reason for anyone to be offended by it - it's just an observation. The discussion though somehow managed to get deflected into other areas. |
| 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