- Template friend function not compiling (full working code example) - 3 Updates
- static vector (c style) - 15 Updates
- Doesn't "explicit" mean explicit? - 2 Updates
| JiiPee <no@notvalid.com>: Jan 22 08:20PM Sorry for last time not providing full code. Now I paste here the full code so you can test the error yourself. I have GCC 4.8, debug build, C++11 on, Windows XP. Error message: "error: declaration of 'operator*' as non-function". So I tried to add a simple multiplication function as a friend. And it to be template function. But it conflicts with the other multiplication function. It works if I commend out the other * operator (see the code). Any idea how to fix this? thanks Full console based code which does not compile: #include <iostream> using namespace std; template <typename T> class Vector2D2; template <typename T> Vector2D2<T> operator * (const T& pointXY, const Vector2D2<T>& point); template <typename T> class Vector2D2 { public: // if I commend this out the code compiles with no problems Vector2D2 operator * (const Vector2D2& point) const { return *this; } friend Vector2D2<T> operator* <> (const T& pointXY, const Vector2D2<T>& point); int y; private: T b; }; template <typename T> Vector2D2<T> operator* (const T& pointXY, const Vector2D2<T>& point) { Vector2D2<T> cc; cc.b = point.b * pointXY; return cc; } int main() { Vector2D2<double> jj, mm; mm = 3.0 * jj; std::cout<<mm.y; return 0; } |
| Paavo Helde <myfirstname@osa.pri.ee>: Jan 22 03:07PM -0600 > std::cout<<mm.y; > return 0; > } As I said before, you need to tell the computer the friend operator* is not from the closest scope (class Vector2D2), but from another scope. Unfortunately, just adding "::" for global scope does not work as this gets merged to the preceding token (Vector2D2<T>). One solution might be to put the operator* in a namespace (all custom C++ code ought to be in a namespace anyway, so this should not a problem). The following at least compiles with g++ (but crashes the MSVC++ compiler ;-): Probably there are other cleaner solutions... #include <iostream> using namespace std; namespace abc { template <typename T> class Vector2D2; template <typename T> Vector2D2<T> operator * (const T& pointXY, const Vector2D2<T>& point); template <typename T> class Vector2D2 { public: // if I commend this out the code compiles with no problems Vector2D2 operator * (const Vector2D2& point) const { return *this; } friend Vector2D2<T> abc::operator*<>(const T& pointXY, const Vector2D2<T>& point); int y; private: T b; }; template <typename T> Vector2D2<T> operator* (const T& pointXY, const Vector2D2<T>& point) { Vector2D2<T> cc; cc.b = point.b * pointXY; return cc; } } // namespace abc using namespace abc; int main() { Vector2D2<double> jj, mm; mm = 3.0 * jj; std::cout<<mm.y; return 0; } |
| JiiPee <no@notvalid.com>: Jan 22 09:35PM On 22/01/2015 21:07, Paavo Helde wrote: > are other cleaner solutions... > friend Vector2D2<T> abc::operator*<>(const T& pointXY, const > Vector2D2<T>& point); Yesss! Wow. Thanks a lot !! you saved hours of my time. Now I can continue with the project :). I have all these classes in ct-namespace, so I just added ct:: and it worked straight away. Need to study this also properly... kind of new to me. |
| jak <please@nospam.tnx>: Jan 14 10:24PM +0100 Il 14/01/2015 19:42, Paavo Helde ha scritto: >> main() { f(); } > If you want more and better feedback it is a good idea to provide > compilable examples. ok. I will keep your words as a treasure for the next time. thank you. > questions nobody can answer them! > Cheers > Paavo In truth I had trouble figuring out who I answered and if answered me. So I abandoned the browser and used a program that would manage newsgroups with trees. This is because Here there is the strange habit that when you talk to a person, the answer comes from another person. The impression is ugly. You feel a prey in the middle of a pack of wolves. |
| legalize+jeeves@mail.xmission.com (Richard): Jan 15 11:16PM [Please do not mail me a copy of your followup] Ian Collins <ian-news@hotmail.com> spake the secret code >> mentality even in the newsgroup it enrages me and I must say something. >Those dinosaurs would be (and possible still are!) having the same >arguments on C projects. That mentality transcends language boundaries. And the whole thing is silly unless you have performance measurements to back up your assertions. Otherwise, it's all just wishful thinking. I'm all in favor of doing things efficiently. I work in graphics and efficiency matters for these kinds of systems. However, armchair pontificating about efficiency or obsessing about single bytes or function calls is not how you get the efficiency that matters. If you care about efficiency and want to be real about it, then I suggest this book: "The Software Optimization Cookbook: High Performance Recipes for IA-32 Platforms", 2nd Edition by Richard Gerber, Aart J. C. Bik, Kevin Smith, Xinmin Tian <http://amzn.to/1xuccG9> It's from 2005, but the discussion is still relevant today because it mostly boils down to proper care and feeding of the data and instruction caches on a CPU. When game developers scream "no virtual functions!" that is their simplistic takeway from the real advice of "keep your cache hot". The latter is what you need to remember, not simplistic bugaboos about particular language features. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| Melzzzzz <mel@zzzzz.com>: Jan 15 12:53PM +0100 On 14 Jan 2015 19:14:11 GMT > I see C++ as a language which fixes the obvious flaws in C -- and I > see C as a crippled and, in 2015, unnecessary (but not useless) > dialect of C++. Hm, lot of programs are written in C. According to TIOBE, C is most popular language, more so than C++. One thing that keeps me program in C++ is that it has great compatibility with C and therefore very well interfaced with C libraries while also keeping higher level code which is less lines. I use C++ mainly because I have to write less lines of code. Power of C++ over C is in less lines of code to do same thing , IMO ;) I mean easier to abstract things... |
| jak <please@nospam.tnx>: Jan 14 06:31PM +0100 > } > #this code here not compile > #and I think should not compile Perhaps does not compile because the example I have not left the various files included: #include <stdio> #include <string> #include <iostream> using namespace std; I have not included them because I saw that nobody does this. ...or because the main function is absent but it is only written in this way: main() { f(); } However I can assure you that what I have written compiles and runs. I'm using the compiler of visual studio express 2013. > #the copy string algo is wrong > #the static is not good used etc forgive me for my english, but this part is not clear for me > #[at last for compiler I use] > #people question on some macro ----- > #difficult what it is 100% plain > #easy it is not matter the language > #one write What can I answer you? In reality what I would like to ask you is much more complicated then I try to cut the problem into smaller pieces and understand something of each piece. :( you could see with your own eyes how difficult it was for me get answers to simple questions. regards. |
| jak <please@nospam.tnx>: Jan 15 03:16PM +0100 Il 15/01/2015 00:59, Christopher Pisz ha scritto: >>>>>> [Please do not mail me a copy of your followup] >>>>>> jak <please@nospam.tnx> spake the secret code >>>>>> <m90pk2$1sg$1@speranza.aioe.org> thusly: ... > bastard would not learn new tricks. When I see any trace of that > mentality even in the newsgroup it enrages me and I must say something. > In summary, don't be sorry. Stop the c-style coding instead. First of all I would like for you to be clear that I am one Italian and I am trying to respond to you in English: You talked in your speech about your working path. Okay. I'd like you to understand that if I am here with questions, the reason is because I do not want to put limits to my knowledge about programming. I would like to let you know that my programming experience with C language is quite vast. I was writing drivers for linux and demons when his name was xenix. yet no one had thought to remove the cobwebs from the code of it and give it a new name. I know of other OOP languages like c-sahrp, for example. But now, unfortunately, people have asked me to fix a program written in C++, so you can see that the real problem is not the programming language but the head of those who use it. :-) |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 15 07:25AM On Thu, 2015-01-15, jacob navia wrote: >> had made such a mess that the company could not get rid of him for fear >> that no one could ever figure out the secret lucky charms encoder rings >> he had littered the code with. You're falsifying what he wrote, which was: > the company could not get rid of him for fear that no one could ever > figure out the secret lucky charms encoder rings he had littered the > code with. So *plonk*. For good, this time. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Louis Krupp <lkrupp@nospam.pssw.com.invalid>: Jan 14 08:36AM -0700 On Wed, 14 Jan 2015 02:53:44 -0800 (PST), asetofsymbols@gmail.com wrote: >#can identify one piece of that >#file contain space for that >#string... The keyword "static" is "overloaded." This might help explain it better than I can: http://www.cprogramming.com/tutorial/statickeyword.html Louis |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 15 07:04AM On Wed, 2015-01-14, Christopher Pisz wrote: > On 1/14/2015 3:38 PM, jak wrote: ... > those people. I truly do. I cannot fathom how many man hours were wasted > and how much money customers were charged, because some old stubborn > bastard would not learn new tricks. I haven't had /exactly/ your experience, but I've seen enough to find what you're saying believable. Sadly. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| jacob navia <jacob@spamsink.net>: Jan 15 08:00AM +0100 Le 15/01/2015 00:59, Christopher Pisz a écrit : > had made such a mess that the company could not get rid of him for fear > that no one could ever figure out the secret lucky charms encoder rings > he had littered the code with. The 15/01/2035 00:59, we spoke about him in the cafeteria. John: What was his name? David: Who? The C++ coder? I think it was Pisz, Christopher Pisz. Why? John: Ahh that old guy? I remember seeing him at the cafeteria, always talking about C++ and why HyperBasic was wrong all along... I think he couldn't adapt to the new coding standards the company has to support... David: Yes, I remember, he would always have arguments to the point spit was flying through the air and the veins in foreheads looked like they were going to burst. He would scream and yell "Efficiency!" and other irrelevant stuff. I mean, who cares about that now? John: Well, he came from the time when HyperBasic wasn't even conceivable, it would have taken a computer of that time a whole DAY to print hello world in HyperBasic. Yes, he was completely outdated that guy. It was a good decision to fire him. David: Anyway, I prefer young people for programming. They never knew about programming languages, and HyperBasic restricted english input comes naturally to their generation that has grown up with computers since they were born. All those old hands that needed a computer language are now obsolete thanks goodness. John: Yes, anyone can be a programmer now, HyperBasic will understand any instructions in a few miliseconds using the new generation quantum machines. Programming is finished as a profession. John and David: Yes, that's the way of the future! ... the future of youth is old age Christopher. I wish you a long life. |
| Christopher Pisz <nospam@notanaddress.com>: Jan 14 05:59PM -0600 On 1/14/2015 3:38 PM, jak wrote: > opposite. I also think that you were very unlucky to have to put your > hands in the code who have written clueless. > regards As an intelligent creature, I like to think that I learn from experience, as all human beings should, while the political correctness movement would have us believe such things are terrible (judgement!). I would only believe it to be "unlucky" had it been one project, or two projects, or one person, or two people, or even a handful of either. The case is that in 20 years, I've moved around quite a bit, I've worked with hundreds of people and on at least 20 significant projects. While I am not trying to toot my horn, I am trying to say that I have a more than adequate sample size to draw such a conclusion at least to the point where it is worth voicing. I am not pulling 80% out of my ass. I literally sat with the bug trackers, read through the bug reports, the back and forth, and the solutions, for thousands of tickets and in 80% of the cases it pointed to C style code. I kept track out of the need to prove that firing said C-style coder was worthwhile. In 4 of the 5 places I did this, there was _one_ and only _one_ C style coder on a C++ team. Usually an old man that had been there for years and years, which had made such a mess that the company could not get rid of him for fear that no one could ever figure out the secret lucky charms encoder rings he had littered the code with. These guys would always have arguments to the point spit was flying through the air and the veins in foreheads looked like they were going to burst. They would scream and yell "Efficiency!" I hate working with those people. I truly do. I cannot fathom how many man hours were wasted and how much money customers were charged, because some old stubborn bastard would not learn new tricks. When I see any trace of that mentality even in the newsgroup it enrages me and I must say something. In summary, don't be sorry. Stop the c-style coding instead. |
| Melzzzzz <mel@zzzzz.com>: Jan 15 03:51PM +0100 On 1/15/15 3:16 PM, jak wrote: I was writing drivers for linux and demons when his name was > xenix. Hahahahhahahha ;) |
| jak <please@nospam.tnx>: Jan 15 07:28PM +0100 Il 15/01/2015 15:51, Melzzzzz ha scritto: > I was writing drivers for linux and demons when his name was >> xenix. > Hahahahhahahha ;) (rofl) |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 15 07:17AM On Thu, 2015-01-15, 嘱 Tiib wrote: > written in C#. On the other hand the code of Python interpreter for > example I like, despite it is C. It is not language's fault that > programmer does not care about readability and robustness. I don't think anyone argues that you cannot use C well[0]: the problem here was people using C++ as if it was (more or less) C. /Jorgen [0] Well, not in this part of this thread, anyway. -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| David Brown <david.brown@hesbynett.no>: Jan 15 09:23AM +0100 On 14/01/15 20:14, Jorgen Grahn wrote: > I see C++ as a language which fixes the obvious flaws in C -- and I > see C as a crippled and, in 2015, unnecessary (but not useless) > dialect of C++. C++ fixes /some/ of the obvious flaws in C, but not all - and like any system that is big, complex and powerful, it has flaws of its own. IMHO, the true power of C++ is the same as with any other programming language - you aim to understand it and find a good balance of the features that suit your needs and abilities for the work at hand. Understanding the C subset and background is part of that, but so are other C++ features. You should use C++ features where they improve on the code compared to C-style features - but equally one should not avoid a C-style array just because it happens to look like C code! C is in no way a "crippled" language, and it is not unnecessary - but it has remained largely static since C99. Tools have changed and improved, but the language is mostly the same - and that is one of its key advantages. If I write modern C++, I need to make sure I have a very recent compiler that supports the features - and anyone working with the code has to have learned the new features. But if I write good, clear, modern C code, it will compile on anything, and any C programmer can work with it. C++ has been getting many more features over time - and that is an advantage for C++. You can write neater, clearer, faster, and safer code with C++11 than with C++03, and C++14 and C++17 continue to improve the language. So while I see that there is steadily more scope for the use of C++ in traditional C domains (such as in an increasing proportion of embedded development), C is far from "crippled" or "unnecessary". |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 14 07:14PM On Wed, 2015-01-14, Christopher Pisz wrote: >> Il 12/01/2015 21:16, Melzzzzz ha scritto: >>> On Mon, 12 Jan 2015 17:09:43 +0000 (UTC) >>> legalize+jeeves@mail.xmission.com (Richard) wrote: ... >> A C compiler does not compile those lines of code while a C++ compiler >> can. He tells lies. He probably wanted to say that he does not like that >> way of writing code because it is too similar to the C code Probably it's not the /similarity/ per se, but the waste ... why not use the tools available to you? They're decades old, so not having time to learn them is a poor excuse. > The true downfall of C++ is C. Power my arse. > 80% of the bugs I encounter in bug trackers stem from C-style code from > people with that mentality whom refuse to move on. If you want to go philosophical, the true power of C++ is to understand C, accept its good and bad sides, and move on using C++, while keeping the good aspects of C in mind. I see C++ as a language which fixes the obvious flaws in C -- and I see C as a crippled and, in 2015, unnecessary (but not useless) dialect of C++. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| red floyd <no.spam@its.invalid>: Jan 15 01:56PM -0800 On 1/15/2015 10:58 AM, DSF wrote: > Error: readdirs.cpp(287,32):Ambiguity between > 'FBaseString<wchar_t>::FBaseString(unsigned int)' and > 'FBaseString<wchar_t>::FBaseString(wchar_t)' Also, in this case, explicit is a red herring. The issue is that your compiler is apparently not creating a distinct type for wchar_t, but using a typedef of some unsigned type. |
| Victor Bazarov <v.bazarov@comcast.invalid>: Jan 15 05:50PM -0500 On 1/15/2015 4:56 PM, red floyd wrote: > Also, in this case, explicit is a red herring. The issue is that your > compiler is apparently not creating a distinct type for wchar_t, but > using a typedef of some unsigned type. Obviously, the same "unsigned int" for which it has a typedef for 'size_t'. I mean, on the close examination of the error message's penultimate line... V -- I do not respond to top-posted replies, please don't ask |
| 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