| Daniel <danielaparker@gmail.com>: Aug 10 12:11PM -0700 On Wednesday, August 9, 2017 at 5:15:00 PM UTC-4, Mr Flibble wrote: > First page of documentation for my C++ GUI/game lib, neoGFX (coming soon): > http://neogfx.io/wiki/index.php/NeoGFX_C%2B%2B_Code_Naming_Convention (1) for (auto const& g : iGrades) total += g; should be for (auto g : iGrades) total += static_cast<char>(g); (2) << static_cast<char>(s.average_grade() + 'A') should be << (static_cast<char>(s.average_grade()) + 'A') Daniel |
| Daniel <danielaparker@gmail.com>: Aug 10 12:18PM -0700 On Wednesday, August 9, 2017 at 5:15:00 PM UTC-4, Mr Flibble wrote: > First page of documentation for my C++ GUI/game lib, neoGFX (coming soon): > http://neogfx.io/wiki/index.php/NeoGFX_C%2B%2B_Code_Naming_Convention What is your definition for an interface class? Pure virtual functions only? tags? Daniel |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 10 09:56PM +0200 On 10.08.2017 21:11, Daniel wrote: > should be > for (auto g : iGrades) > total += static_cast<char>(g); I bet Mr Flibble was the victim of editing here. Marshall Cline once gave me the advice to do as he did with the FAQ's examples for the FAQ book: compile them all, no matter how trivial. So, good catch, as they say, but instead of the `static_cast` I'd rather fix the `enum` definition, e.g. replace enum class grade with struct Grade { enum Enum { which fixes the one thing that was ungood about C++03 enumerations, namely lack of qualification of value names, without dragging in the new ungoodness of C++11 enumerations, namely lack of implicit conversion to integer values. Also I'd use `auto const` rather than just `auto`: that's a nice possibility with range based `for`, and I think it deserves to be used by default, only leaving off the `const` when that has a /purpose/. > << static_cast<char>(s.average_grade() + 'A') > should be > << (static_cast<char>(s.average_grade()) + 'A') Eagle eyes! :) Cheers!, - Alf |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 10 09:23PM +0100 On 10/08/2017 20:56, Alf P. Steinbach wrote: >> should be >> << (static_cast<char>(s.average_grade()) + 'A') > Eagle eyes! :) Fixed the issues *my* way; thanks. /Flibble |
| "Öö Tiib" <ootiib@hot.ee>: Aug 10 01:37PM -0700 On Thursday, 10 August 2017 00:15:00 UTC+3, Mr Flibble wrote: > First page of documentation for my C++ GUI/game lib, neoGFX (coming soon): > http://neogfx.io/wiki/index.php/NeoGFX_C%2B%2B_Code_Naming_Convention It wasn't likely meant as demo of algorithms but with your average_grade algorithm grades A, B, B, B will give A as average. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 10 09:44PM +0100 On 10/08/2017 21:37, Öö Tiib wrote: >> http://neogfx.io/wiki/index.php/NeoGFX_C%2B%2B_Code_Naming_Convention > It wasn't likely meant as demo of algorithms but with your average_grade > algorithm grades A, B, B, B will give A as average. This is OK as Mr Flibble's average grade is not A so will making coding mistakes. /Flibble |
| "R.Wieser" <address@not.available>: Aug 10 08:02PM +0200 Hello all, This is sort of a of continuation of my previous question, as it regards the same object. I would like to use a virtual destructor for a pure virtual class (no code in the vc++ program), but have no idea about the/its side-effects. Like who is responsible for freeing the objects memory in case a virtual destructor is executed. The reason I'm asking is because in my case the external object releases its own memory, and having the vc++ program try to do it again would probably not end well ... The same goes for the "delete(object)" command. I assume it its, apart from zeroing-the object variable after the method call returns, fully equivalent to "object->~object();", but am not at all sure of it. I have googled, but I only seem to be able to find pages talking about derived classes, which is most certainly not how I'm using it. So, in the case of a virtual destructor, who is responsible for/does the releasing of the objects allocated memory ? And are there other (side) effects I should be aware of ? Regards, Rudy Wieser |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 10 07:04PM +0100 On 10/08/2017 19:02, R.Wieser wrote: > Hello all, > This is sort of a of continuation of my previous question, as it regards the > same object. Why are you using VC++2008? VS2015 is fine and it is free. /Flibble |
| scott@slp53.sl.home (Scott Lurndal): Aug 10 06:14PM >in the vc++ program), but have no idea about the/its side-effects. >Like who is responsible for freeing the objects memory in case a virtual >destructor is executed. The 'delete' verb in C++ will (if not overloaded), first call any destructor(s) for the object, then release the storage of the object back to the storage pool/heap. One cannot delete an abstract class (since one cannot instantiate it), so the destructor will never be called and no memory will be free'd. |
| "R.Wieser" <address@not.available>: Aug 10 09:51PM +0200 Scott, > The 'delete' verb in C++ will (if not overloaded), first call any > destructor(s) for the object, then release the storage of the > object back to the storage pool/heap. That was what I was afraid of. Its going to try to delete some allocated memory that doesn't exist anymore (already free'd by the external object). And thats apart from the problem that it has no idea *how* that memory was allocated, so its possible it handles it wrongly too ... > One cannot delete an abstract class (since one cannot instantiate it), > so the destructor will never be called and no memory will be free'd. Phew! I guess I should count my blessings there. No chance of (c|t)rashing the VC++ program. On the other hand, you *can* have a purely virtual destructor, but it *can't* be executed by means normally ment to call it ? Thats rather odd. I mean, if defining default destructor virtually does not bring any benefits, why even do so / allow it ? Yes, I'm not nice. I really try to think about what people tell me. And than I'm to much of a "need to know" person to let common curtesy stop me from expressing my doubts. Sorry. And by the way, you're mistaken. I just declared the standard destructor as "virtual __stdcall ~ExternalObject();" and used "delete(TheObject)", and lo and behold, the designated code in the external plugin was called. Alas, *without* a 'this' reference (the value 0x1 appeared in its place) as the first argument (contrary to what the "__stdcall" does on other virtual methods mind you). ECX was loaded with the correct 'this' reference though. On the other hand, calling "delete(object)" on an object which does *not* have a (virtual) destructor crashes the VC++ program ... And aint I nice here though: not only am I replying, I even feed back the knowledge I've gained. :-) Regards, Rudy Wieser -- Origional message: Scott Lurndal <scott@slp53.sl.home> schreef in berichtnieuws do1jB.118956$114.36519@fx15.iad... > "R.Wieser" <address@not.available> writes: > >Hello all, > >This is sort of a of continuation of my previous question, as it regards the > >same object. > >I would like to use a virtual destructor for a pure virtual class (no code > >Like who is responsible for freeing the objects memory in case a virtual > >destructor is executed. > The 'delete' verb in C++ will (if not overloaded), first call any destructor(s) |
| "R.Wieser" <address@not.available>: Aug 10 08:03PM +0200 David, > I am not looking for a discussion - Good. Neither am I. Regards, Rudy Wieser -- Origional message: David Brown <david.brown@hesbynett.no> schreef in berichtnieuws omhtun$9gk$1@dont-email.me... |
| "R.Wieser" <address@not.available>: Aug 10 08:28PM +0200 Scott, > Ask for free advice, and you get what you pay for. If only! I do not mind getting *no* answers, its the "you asked something, now we have the right to reply with *anything*, no matter how unrelated" that mostly gets to me. > And please, please, use the canonical Usenet posting > style with correct attributions. Which one are you, the catholic or the protestant ? :-( I'm here to talk shop about some (V)C++ programming, not to listen to a few blown-up egos trying to assert themselves. Deal with other peoples different interpretations of the Usenet "rules" (Yes, I've read them). Or don't. Not really my problem. Regards, Rudy Wieser -- Origional message: Scott Lurndal <scott@slp53.sl.home> schreef in berichtnieuws jT0jB.352230$AG1.205258@fx42.iad... |
| 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