- open source SVG library for C++ or C - 2 Updates
- Understanding virtual destructor - 22 Updates
- Why do we need a killfile? Insanity. - 1 Update
| "Öö Tiib" <ootiib@hot.ee>: Oct 08 06:07AM -0700 On Friday, 7 October 2016 18:05:21 UTC+3, Mr Flibble wrote: > because we know evolution is a fact and evolution falsifies the Old > Testament and, because it is predicated on the Old Testament being true, > the New Testament. This is sort of all-or-nothing logic. In reality something written in Bible may be is correct and something may be is incorrect. We do not have independent records or archeological evidences about kings named Saul, David or Solomon living in Jerusalem nor their kingdoms and conquests. So it may be there were no such kings. That does not mean that Jerusalem does not exist. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 08 07:06AM -0700 Öö Tiib wrote: > This is sort of all-or-nothing logic. In reality something written > in Bible may be is correct and something may be is incorrect... You are correct. That is what happens in this world. That is our understanding. What I am trying to teach you is that we are limited in our ability to understand things because of sin, and what sin did to us by making us spiritually dead. When sin entered in and death through sin, we didn't die in our body, but spiritually we did die. This limits us to only having OUR input given to us by our natural senses. Our existence is then completely blind to spiritual matters, and to such an extent that a demon could walk up and enter your body and you'd be unaware of it. You'd just think you were feeling a particular way, or were born a certain way. You would not be able to tell that the way you feel is the result of the intruder influence, rather than your own self. And if someone like me told you that it was the result of an unseen intruder influence, you'd laugh me to shame. It's why I can't teach you these things, but can only repeat what He has taught us to you so that if you are seeking the truth, He will affirm within you by giving you the understanding of His own teaching through my words, yet in a way you can understand. Because of sin, all people are born blind to spiritual matters. Satan takes advantage of that and influences you spiritually, manipulating your feelings, thoughts, emotions, beliefs, influences, so that you will follow his guidance into more sin and more harm to yourself and other people. Jesus came to set us free from death. He does this by taking our sin away so we are no longer spiritually dead, and we can then no longer be blind to spiritual matters, but rather God speaks to us to teach us truth and falseness. We can then know Satan's attacks and turn away from them and call them out, even teaching others. But, it's not possible to know any of this without God first drawing a person from within to be able to know it. He flips the switch. He makes the change. He enables truth to be known, so that we can see our sin, repent, ask forgiveness, and be saved. Then, and only then, through faith, by the spirit, can we then know with certainty the things which cannot otherwise be known in this world. Then do we have proof, and it's not even hard to see or understand, as it is spiritually discerned and is simply known, just as easily as us knowing what warm sunlight feels like on our face, or the haunting fragrance of fresh cut violets. The spirit gives us the ability to know that which the flesh could not know. http://www.biblehub.com/kjv/hebrews/11-1.htm 11 Now faith is the substance of things hoped for, the evidence of things not seen. http://biblehub.com/kjv/1_corinthians/2-14.htm 14 But the natural man receiveth not the things of the Spirit of God: for they are foolishness unto him: neither can he know them, because they are spiritually discerned. You must be born again (of the spirit). Nicodemus didn't understand this either. But because he sought the truth, God opened up his understanding and he later received and buried the body of Jesus: http://biblehub.com/kjv/john/3.htm Just seek the truth. God will do the rest. All yoiu have to do is set your full focus on the truth, honestly desiring to know it, even if you don't know what it might be. Best regards, Rick C. Hodgin |
| Mr Flibble <flibble@i42.co.uk>: Oct 08 01:29AM +0100 On 08/10/2016 00:02, JiiPee wrote: > ~Shape(); > int b; > }; Do you have a Square class too? If so it should be derived from a Rectangle class not a Shape class. /Flibble |
| Jerry Stuckle <jstucklex@attglobal.net>: Oct 07 08:38PM -0400 On 10/7/2016 7:02 PM, JiiPee wrote: > Circle # > # > ########## Both a and b will be deleted. However, the destructor for b will be called, but not the Shape (and therefore the destructor for a). It's not a problem with int values - but if it were an object such as a String, it could create a memory leak. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| JiiPee <no@notvalid.com>: Oct 08 01:52AM +0100 On 08/10/2016 01:29, Mr Flibble wrote: > Do you have a Square class too? If so it should be derived from a > Rectangle class not a Shape class. > /Flibble ? why you asking this? :) |
| JiiPee <no@notvalid.com>: Oct 08 01:56AM +0100 On 08/10/2016 01:38, Jerry Stuckle wrote: > the destructor for b will be > called, but not the Shape (and therefore the destructor for a). what do you mean? b does not have a destructor. Also the Shape -class destructor will be called. Not sure what you say ("but not the Shape")... |
| JiiPee <no@notvalid.com>: Oct 08 02:03AM +0100 On 08/10/2016 01:38, Jerry Stuckle wrote: > b will be deleted so whatever type b is (even if it is an object) it will be deleted but its destructor will not be called? |
| Ian Collins <ian-news@hotmail.com>: Oct 08 02:11PM +1300 On 10/ 8/16 12:02 PM, JiiPee wrote: > { > public: > ~Shape(); I assume this should be ~Circle(): > delete s; > now Shape destructor should be virtual obviously. But what happens if I > do not make it virtual: does int b; be deleted? The Circle object will be deleted, ~Circle() will be called, but not ~Shape(). -- Ian |
| Jerry Stuckle <jstucklex@attglobal.net>: Oct 07 09:16PM -0400 On 10/7/2016 8:56 PM, JiiPee wrote: >> called, but not the Shape (and therefore the destructor for a). > what do you mean? b does not have a destructor. Also the Shape -class > destructor will be called. Not sure what you say ("but not the Shape")... b has a constructor, but for an int, it does nothing. But sorry, I meant Circle's destructor would not be called. That's what I get for being in a hurry. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Oct 07 09:17PM -0400 On 10/7/2016 9:03 PM, JiiPee wrote: >> b will be deleted > so whatever type b is (even if it is an object) it will be deleted but > its destructor will not be called? That is correct. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Oct 07 09:18PM -0400 On 10/7/2016 9:11 PM, Ian Collins wrote: >> do not make it virtual: does int b; be deleted? > The Circle object will be deleted, ~Circle() will be called, but not > ~Shape(). Ian, that's where I was also long due to being in a hurry. Shape's destructor will be called, because the program is deleting a Shape. But Circle's destructor will not be called. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 08 03:28AM +0200 On 08.10.2016 01:02, JiiPee wrote: > delete s; > now Shape destructor should be virtual obviously. But what happens if I > do not make it virtual: does int b; be deleted? Formally it's Undefined Behavior, and that means that anything or nothing may happen. In practice a compiler is unlikely to detect the UB and then make the program do Nasty Things™ in that case. Instead the ordinary code for a `delete` expression is likely to be executed, under the invalid assumption that the object to be deleted is of most derived class `Shape`. Since a `Shape` object is of smaller size than the actual `Circle` object, this might foul up things with respect to the memory allocator. Or not: it depends on how the implementation stores the sizes of allocated objects, or not, and it depends on whether the memory block that would have been allocated for a `Shape` would be the same size as for a `Circle`. In the common case where it's the memory manager that keeps track of block size for all dynamically allocated objects, the code is likely to just work. That is one possible effect of Undefined Behavior. > Am I correct that when > creating s (s = new Circle();) then it consists of two parts: Shape part > and Circle part and they are separate "units". They're not separate: they're very much adjoined, and in some cases parts of a derived class may be intermingled with parts of a base class. > So when I destroy s only > the Shape part of the object will be destroyed but all the Circle part > will stay in memory (leaks)? is this how it is? No no no. :) There's one allocated block of memory. It may or may not be correctly dellocated, depending on the C++ implementation. Before that only the `Shape` destructor will be executed, since it's not virtual. Cheers & hth., - Alf |
| JiiPee <no@notvalid.com>: Oct 08 02:39AM +0100 On 08/10/2016 02:16, Jerry Stuckle wrote: > b has a constructor, but for an int, it does nothing. but you were talking about destructors. does int also have a destructor? |
| JiiPee <no@notvalid.com>: Oct 08 02:40AM +0100 On 08/10/2016 02:17, Jerry Stuckle wrote: >> so whatever type b is (even if it is an object) it will be deleted but >> its destructor will not be called? > That is correct. oh ok, this was a bit new to me.. never thought of this. sometimes good to think deeper :) |
| JiiPee <no@notvalid.com>: Oct 08 02:41AM +0100 On 08/10/2016 02:11, Ian Collins wrote: >> public: >> ~Shape(); > I assume this should be ~Circle(): yes, copy-paste error |
| JiiPee <no@notvalid.com>: Oct 08 02:53AM +0100 On 08/10/2016 02:28, Alf P. Steinbach wrote: > Formally it's Undefined Behavior, and that means that anything or > nothing may happen. Ok, you got me a bit confused as Jerry said that b would be deleted. hmmm... so you are saying its not certain. So basically this is a bug/error and in theory crash the program. >> and Circle part and they are separate "units". > They're not separate: they're very much adjoined, and in some cases > parts of a derived class may be intermingled with parts of a base class. ok, good. this is what I really wanted to know. So they can be mixed. Then it makes sense that not part of the memory cannot be deleted, but its all or nothing. >> will stay in memory (leaks)? is this how it is? > No no no. :) > There's one allocated block of memory. ok and the memory manager does not know which part belongs to Shape and which to Circle. > It may or may not be correctly dellocated, depending on the C++ > implementation. so this means b might be left hanging in the memory ( a leak). |
| JiiPee <no@notvalid.com>: Oct 08 02:54AM +0100 On 08/10/2016 01:38, Jerry Stuckle wrote: > Both a and b will be deleted. hmm, but now Alf is saying it can be an undefined behaviour..... which would mean b is not necessary deleted in the worst case scenario... ? Please check Alf s post |
| mark <mark@invalid.invalid>: Oct 08 04:16AM +0200 On 2016-10-08 03:28, Alf P. Steinbach wrote: >> do not make it virtual: does int b; be deleted? > Formally it's Undefined Behavior, and that means that anything or > nothing may happen. C++14, 5.3.5 Delete [expr.delete]: <<< In the first alternative (delete object), if the static type of the object to be deleted is different from its dynamic type, the static type shall be a base class of the dynamic type of the object to be deleted and the static type shall have a virtual destructor or the behavior is undefined. ... > In practice a compiler is unlikely to detect the UB and then make the > program do Nasty Things™ in that case. The detection is possible in quite a few cases. I'm not nearly as optimistic as you about the compiler not doing Nasty Things. E.g. it might come to the invalid conclusion that certain objects cannot alias and make optimizations based on that (compilers use undefined behavior extensively to enable optimizations). |
| legalize+jeeves@mail.xmission.com (Richard): Oct 08 04:03AM [Please do not mail me a copy of your followup] "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> spake the secret code >Formally it's Undefined Behavior, and that means that anything or >nothing may happen. I like it when undefined behavior means gcc invokes nethack. -- "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> |
| Bo Persson <bop@gmb.dk>: Oct 08 09:48AM +0200 On 2016-10-08 03:53, JiiPee wrote: >> There's one allocated block of memory. > ok and the memory manager does not know which part belongs to Shape and > which to Circle. The memory manager knows nothing about objects, it only handles blocks of memory (bytes). >> It may or may not be correctly dellocated, depending on the C++ >> implementation. > so this means b might be left hanging in the memory ( a leak). No. It might happen that the memory manager only handles some block sizes, like 8 or 16 bytes minimum. In that case both your types will have the same size allocated. Then it "works". Or it might be the memory manager that (by some magic) knows the sizes of all allocated memory blocks. Then it can always deallocate them properly. Or it might be the compiler that tells it to deallocate sizeof(Shape) bytes. Then the heap will likely be damaged, and the Bad Things will happen shortly after. Bo Persson |
| Jerry Stuckle <jstucklex@attglobal.net>: Oct 08 06:08AM -0400 On 10/7/2016 9:39 PM, JiiPee wrote: > On 08/10/2016 02:16, Jerry Stuckle wrote: >> b has a constructor, but for an int, it does nothing. > but you were talking about destructors. does int also have a destructor? Yes, it does. Conceptually, all objects in C++ have destructors, just like all objects have constructors. In the case of an int, it does nothing. But the concept is still there. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Oct 08 06:11AM -0400 On 10/7/2016 9:54 PM, JiiPee wrote: > hmm, but now Alf is saying it can be an undefined behaviour..... which > would mean b is not necessary deleted in the worst case scenario... ? > Please check Alf s post b is always deleted, because the containing object is deleted. Bit its destructor is not called. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| JiiPee <no@notvalid.com>: Oct 08 11:24AM +0100 On 08/10/2016 11:11, Jerry Stuckle wrote: >> Please check Alf s post > b is always deleted, because the containing object is deleted. Bit its > destructor is not called. ok, so the memory manager have no error in knowing the size of the object to delete even though we delete it via the base class pointer? So it will always delete the same size of memory block whether we delete via the base class pointer or via the derived class pointer? So the undefined behaviour has nothing to do with deleting the objects memory block? |
| "Öö Tiib" <ootiib@hot.ee>: Oct 08 05:04AM -0700 On Saturday, 8 October 2016 04:53:19 UTC+3, JiiPee wrote: > Ok, you got me a bit confused as Jerry said that b would be deleted. > hmmm... so you are saying its not certain. > So basically this is a bug/error and in theory crash the program. Of course it may crash the program. It is not even some "theoretical" crash that in practice never happens. Quite similar example that crashes with gcc: #include <iostream> struct Shape { ~Shape() {}; int a; }; struct Grape { virtual // <- erase or comment it out and the program will crash ~Grape() {}; int g; }; struct Crashy: public Shape, public Grape { int n; }; int main() { Grape* g = new Crashy(); delete g; // <- it will crash here std::cout << "quod erat demonstrandum\n"; } > ok, good. this is what I really wanted to know. So they can be mixed. > Then it makes sense that not part of the memory cannot be deleted, but > its all or nothing. That is so when objects do not contain member objects that further manage more dynamic memory on their own. For example 'std::vector' member. > > It may or may not be correctly dellocated, depending on the C++ > > implementation. > so this means b might be left hanging in the memory ( a leak). No. It *is* undefined behavior. Compiler usually does not produce diagnostics (but may) and does not refuse to compile it (but may) and does produce running executable (but may not). When that executable is ran then what happens may differ by compiler version or compiling options and may be predictable or may be is not predictable. That all may be painful and may waste time of everybody so deliberately invoking undefined behavior for some effect may be considered as sabotage by your colleagues. |
| eccofonic@charter.net: Oct 07 07:38PM -0500 On Mon, 26 Sep 2016 05:47:16 -0700 (PDT), "Rick C. Hodgin" >Being good isn't enough. Being great isn't enough. Being the best person >you can possibly be isn't enough. Why? <more nonsense snipped> I like the theory the next guy has about you... "narcissistic personality disorder". Yeah buddy, you're certified nuts.... over 2500 posts deleted in the c group. I wonder how much in this one? <filter activated> |
| 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