Thursday, September 24, 2015

Digest for comp.lang.c++@googlegroups.com - 18 updates in 4 topics

jacobnavia <jacob@jacob.remcomp.fr>: Sep 24 07:09PM +0200

ForwardPool.cpp:97:4: Delete called on 'CForwardBlock' that is abstract
but has non-virtual destructor
 
???
That looks like chinese to me.
 
What could be all about?
 
while(true)
{
CForwardBlock* p=m_disk_pool.Get();
 
if(p==NULL) {break;}
else
{
InterlockedDecrement(&m_disk_pool_size);
p->freeit();
delete p; <<<<<<<<<<<<<here
}
}
 
The definition of that class looks like this
 
class CForwardBlock
{
char* p_buf;
mlong m_size; //this is the current size of buffer
mlong m_pos; //this is the current position in buffer
mlong m_max_size;
 
public:
 
 
 
CForwardBlock(mlong size)
{
m_max_size=size;
m_pos=0;
m_size=0;

}
void init() {p_buf = getBuffer(m_max_size);}
 
 
void freeit() {freeBuffer(p_buf);}
~CForwardBlock()
{
}
 
// ...
Melzzzzz <mel@zzzzz.com>: Sep 24 07:28PM +0200

On Thu, 24 Sep 2015 19:09:02 +0200
> {
> }
 
> // ...
 
It should have at least one pure virtual function. Deleting through
pointer to such class is undefined behavior if destructor is not
virtual, I think. Good thing is that you got compiler error instead...
Melzzzzz <mel@zzzzz.com>: Sep 24 07:34PM +0200

On Thu, 24 Sep 2015 19:28:58 +0200
 
> It should have at least one pure virtual function. Deleting through
> pointer to such class is undefined behavior if destructor is not
> virtual, I think. Good thing is that you got compiler error instead...
 
To be more precise deleting anything through pointer to base class is
undefined if destructor in base class is not virtual.
bartekltg <bartekltg@gmail.com>: Sep 24 08:44PM +0200

On 24.09.2015 19:09, jacobnavia wrote:
> {
> }
 
> // ...
 
 
 
Do you have here any virtual function? If yes, you probably
want to write delivered class, and use an object of this class...
using polymorphism (I mean by base-class pointer). In this case,
only the destructor of the base class will be called.
To avoid this your destructor should be virtual.
 
http://stackoverflow.com/questions/1123044/when-should-your-destructor-be-virtual
 
bartekltg
 
 
 
Martin Shobe <martin.shobe@yahoo.com>: Sep 24 01:47PM -0500

On 9/24/2015 12:09 PM, jacobnavia wrote:
> but has non-virtual destructor
 
> ???
> That looks like chinese to me.
 
An abstract class is one that contains at least one pure virtual
function. The important consequence here is that it can only be created
as the base class of another class. When you destroy an instance of a
class, the destructor called needs to be the one for the most derived
class. In this case, because it's abstract, it can't be CForwardBlock.
Since the destructor is not virtual, the destructor for CForwardBlock is
called and not the one that should be.
 
To fix it, you should make the destructor virtual.
 
Martin Shobe
jacobnavia <jacob@jacob.remcomp.fr>: Sep 24 09:09PM +0200

Thanks for all these answers. I will try to fix this by doing as
required: make a virtual destructor.
 
That would imply that all classes that inherit from it should define a
destructor... Will the compiler warn me if there is a class that
inherits from that class and hasn't defined its destructor?
 
Thanks to all
Christopher Pisz <nospam@notanaddress.com>: Sep 24 02:15PM -0500

On 9/24/2015 12:09 PM, jacobnavia wrote:
> {
> }
 
> // ...
 
Consult the documentationfor CForwardBlock, whatever that is.
It looks like some MFC-esk poopy written by someone who has no notion of
RAII.
 
The error is coming from some part of CFowardBlock that you left out. It
probably has a pure virtual function and was made to be derived from.
 
Why in the world you need a seperate init and freeit method is not
apparent. Why not allocate in the constructor and release in the
deconstructor? This class will leak as is, if an exception is thrown.
 
You also didn't show what m_disk_pool's type is or what it's get method
returns.
 
 
--
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---
Martin Shobe <martin.shobe@yahoo.com>: Sep 24 02:25PM -0500

On 9/24/2015 2:09 PM, jacobnavia wrote:
 
> That would imply that all classes that inherit from it should define a
> destructor... Will the compiler warn me if there is a class that
> inherits from that class and hasn't defined its destructor?
 
No, because the compiler will supply a default one. You should only need
to define a destructor for those classes that need to do something other
than just destroy it's sub-objects.
 
Martin Shobe
Melzzzzz <mel@zzzzz.com>: Sep 24 09:43PM +0200

On Thu, 24 Sep 2015 21:09:36 +0200
 
> That would imply that all classes that inherit from it should define
> a destructor... Will the compiler warn me if there is a class that
> inherits from that class and hasn't defined its destructor?
 
You don't have to define destructor in derived classes.
 
jacobnavia <jacob@jacob.remcomp.fr>: Sep 24 11:00PM +0200

Le 24/09/2015 21:15, Christopher Pisz a écrit :
 
> Consult the documentationfor CForwardBlock, whatever that is.
 
That's very easily done. Thanks. No documentation.
 
> It looks like some MFC-esk poopy written by someone who has no notion of
> RAII.
 
Maybe, if you say so, I would agree if I knew what "MFC-esk" could mean
in a Unix environment with gcc as compiler...
 
 
> The error is coming from some part of CFowardBlock that you left out. It
> probably has a pure virtual function and was made to be derived from.
 
It has many virtual functions, yes.
 
> Why in the world you need a seperate init and freeit method is not
> apparent. Why not allocate in the constructor and release in the
> deconstructor? This class will leak as is, if an exception is thrown.
 
Yes, I thought C++ would use that but the people that wrote that didn't.
I can't tell you their reasons, and your reasons look reasonable at
first sight. But first sights do not count here. Maybe there was a
reason, I do not know.
 
> You also didn't show what m_disk_pool's type is or what it's get method
> returns.
 
It is a Fifo template,
 
template<class T, class P, int LenLn2>
class FifoBase
 
and one of the template's method is
 
...
T *Get();
 
 
Mmmmm that brings us not a lot more near the solution but...
Christopher Pisz <nospam@notanaddress.com>: Sep 24 04:22PM -0500

On 9/24/2015 4:00 PM, jacobnavia wrote:
>> RAII.
 
> Maybe, if you say so, I would agree if I knew what "MFC-esk" could mean
> in a Unix environment with gcc as compiler...
 
I mean naming classes "C<somename>" as if the prefix of C does something
special for it. CFile, CSocket, CSnuffleupogus, etc. They also love
manual reference counting that makes bugs. Maybe the practice came from
somewhere else before MFC, I dunno, but it is silly. You'll also see
increment this and decrement that all over the place, usually without
concern for what situations it will actually increment to decrement
correctly...which brings us to RAII. Write a test in your compiler where
you create something that is a CFowardBlock and throw an exception after
you create it. Put a breakpoint on the call that frees the buffer. Did
it get freed or did it leak?
 
 
 
--
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---
mathieu <mathieu.malaterre@gmail.com>: Sep 24 06:55AM -0700

I am reading the C++ wikimedia page:
 
https://en.wikipedia.org/wiki/C%2B%2B_Standard_Library
 
The introduction starts with:
 
[...]
The C++ Standard Library also incorporates 18 headers of the ISO C90 C standard library ending with ".h", but their use is deprecated.
[...]
 
I must have been living under a rock: I did not know this was being deprecated. Any reference on this ? and why ?
 
Thanks.
Paavo Helde <myfirstname@osa.pri.ee>: Sep 24 10:01AM -0500

mathieu <mathieu.malaterre@gmail.com> wrote in
> standard library ending with ".h", but their use is deprecated. [...]
 
> I must have been living under a rock: I did not know this was being
> deprecated. Any reference on this ? and why ?
 
This is straight from Annex D in C++ 2003 and later (possibly also
earlier) standards which among other things is listing these C headers
and which is also referenced by the wikipedia article:
 
"These are deprecated features, where deprecated is defined as: Normative
for the current edition of the Standard, but not guaranteed to be part of
the Standard in future revisions."
 
As to why, then I guess the main reason is that these headers pollute the
global namespace and may conflict with the same names defined by the C
implementations (e.g. ::abs() truncating its argument to an integer).
 
Cheers
Paavo
Anand Hariharan <mailto.anand.hariharan@gmail.com>: Sep 24 09:01AM -0700

On Thursday, September 24, 2015 at 10:01:36 AM UTC-5, Paavo Helde wrote:
 
> As to why, then I guess the main reason is that these headers pollute the
> global namespace and may conflict with the same names defined by the C
> implementations (e.g. ::abs() truncating its argument to an integer).
 
http://stackoverflow.com/a/13040283
 
C++11 extended latitude to the library implementers to put those names in the global namespace. So C++03 had it right, then C++11 loosened it quite a bit. Will they consider slowly tightening it back to where they started?
Bo Persson <bop@gmb.dk>: Sep 24 09:52PM +0200

On 2015-09-24 18:01, Anand Hariharan wrote:
 
> http://stackoverflow.com/a/13040283
 
> C++11 extended latitude to the library implementers to put those names in the global namespace. So C++03 had it right, then C++11 loosened it quite a bit. Will they consider slowly tightening it back to where they started?
 
Not likely. The rules were loosened because most of the major
implementations failed in this regard.
 
 
Bo Persson
Jorgen Grahn <grahn+nntp@snipabacken.se>: Sep 24 10:48AM

On Wed, 2015-09-23, Richard wrote:
> about things like identifier names or whitespace, but more about
> things like RAII, communicating your intent more clearly through code
> and so-on.
 
Unfortunately, you can disagree about those things too. (I think I'm
more or less on Stroustrup's wavelength, except I don't use
inheritance a lot.)
 
> I discovered quite a few ideas in there that I would like to adopt and
> they weren't ideas I'd heard of before, so it's not the same-old
> same-old rehashed once again.
 
Lesson: I should start by reading what's there. I already cloned the
repository, so ...
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
legalize+jeeves@mail.xmission.com (Richard): Sep 24 05:00PM

[Please do not mail me a copy of your followup]
 
Jorgen Grahn <grahn+nntp@snipabacken.se> spake the secret code
 
>Unfortunately, you can disagree about those things too. (I think I'm
>more or less on Stroustrup's wavelength, except I don't use
>inheritance a lot.)
 
IMO inheritance is overused in any language that supports it. I think
people often confuse OOP to mean "it's all about inheritance".
 
>> same-old rehashed once again.
 
>Lesson: I should start by reading what's there. I already cloned the
>repository, so ...
 
Some things I saw for the first time that I liked:
 
- a template class not_null<T*> to clearly indicate that this is a raw
pointer that should never be null
 
- a template class owner<T*> to indicate that having this raw pointer
means ownership and not access through indirection.
 
Using these allows automated tools to discover misuse of these raw
pointers. Determining the intended semantics of raw pointers has
always been difficult to automate.
--
"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>
Robert Baer <robertbaer@localnet.com>: Sep 23 10:25PM -0700

Skybuck Flying wrote:
> Entity. "
 
> Bye,
> Skybuck.
With 1024x768 screen:
 
"Please use a wider window to browse cybergrandchallenge.com"
 
All else black, NO "contest" info.
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.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)