Wednesday, May 3, 2017

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

Andrey Karpov <karpov2007@gmail.com>: May 03 12:34AM -0700

> the hair I've lost?
 
> Or ... what does it do for me that makes it worth my approaching you
> through the "Contact us" link and inquiring as to the price?

I spread the word about static analysis in general and about PVS-Studio analyzer in particular. My mission is to show that static analyzers may be useful. That is what I am doing, but you would probably agree that it would be strange to do it using a different tool as an example, without speaking about PVS-Studio.
 
We have no license to individual developers. An article on this topic: https://www.viva64.com/en/b/0320/
 
We sell the analyzer to the development teams and the price request is a common practice. For example, Coverity does the same thing. We can provide the prices in various currencies and for teams of various sizes. Therefore, the question of licensing is always discussed by e-mail.
legalize+jeeves@mail.xmission.com (Richard): May 03 09:50PM

[Please do not mail me a copy of your followup]
 
Andrey Karpov <karpov2007@gmail.com> spake the secret code
 
>I spread the word about static analysis in general and about PVS-Studio
>analyzer in particular. [...]
 
Please do continue spreading the word!
 
Static analysis tools are wonderful additions to the C++ developer's
toolbox. Use as many of them as you can is my consistent advice.
Each tool has it's own strengths and weaknesses and they don't always
turn up the same issues.
 
To get your feet wet you can try some free tools:
 
Adding Static Analysis to Your C++ GitHub Repository
<https://legalizeadulthood.wordpress.com/2014/12/07/adding-static-analysis-to-your-c-github-repository/>
 
Visual Studio 2017 Community Edition includes improved static analysis
including experimental support for the C++ Core Guidelines.
<http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines>
 
I ran this on one of our production code bases (3D subdivision surface
modeler, ~700 Klocs) and it found a gaggle of potential NULL
dereference errors. I'm in the process of fixing those. Finding
these through manual testing would have been prohibitively tedious and
exhausting.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
woodbrian77@gmail.com: May 02 07:45PM -0700


> https://meetingcpp.com/index.php/newsreader/items/c-user-group-meetings-in-april-2017.html
 
> I'm not sure if I'll do this more than one time. I'm willing
> to travel overseas if that's where the interest is.
 
http://meetingcpp.com/index.php/newsreader/items/c-user-group-meetings-in-may-2017.html
 
That page says there's a new user group in Minneapolis. To the best of my knowledge
they haven't met yet and it doesn't look like they have a meeting planned yet.
I'm not sure how long it will take for them to get going, but in the meantime, I'm
happy to travel to your location.
 
Brian
Ebenezer Enterprises - "For G-d so loved the world that He gave His one and
only Son, that whoever believes in Him shall not perish but have eternal life." John 3:16
 
http://webEbenezer.net
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 03 06:38PM +0100

On 05/04/2017 03:59, woodbrian77@gmail.com wrote:
 
Subject: std::variant<Dublin, Jerusalem, Melbourne, Prague, Austin, ...>
 
Using a variant to hold different cities is egregious. All cities are of
the same type: "city".
 
This is similar to the common mistake of not preferring composition over
inheritance: it would also be wrong to have a "Dublin" class derived
from a "City" class.
 
/Flibble
kushal bhattacharya <bhattacharya.kushal4@gmail.com>: May 02 10:59PM -0700

On Monday, May 1, 2017 at 8:56:01 PM UTC+5:30, Chris M. Thomasson wrote:
> std::unique_lock<std::mutex> lock(*ptr);
> }
> _____________________________
 
I was looking for this exact stuff i found it thnks :)
Bonita Montero <Bonita.Montero@gmail.com>: May 03 07:27PM +0200

> std::unique_lock<std::mutex> lock(*ptr);
 
Or with C++17's class template deduction:
 
std::unique_lock lock( *ptr );
fl <rxjwg98@gmail.com>: May 02 07:58PM -0700

Hello,
 
I have the below code snippet from "C++ Primer" 4th edition. It is seen that
ip is deleted inside the destructor, but 'use' has no such deletion.
I don't find the reason on the web. I see pointer ip is the same with 'use'
on memory usage here.
 
Could you tell me that?
 
Thanks a lot
 
 
////////////////////
/* smart pointer class: takes ownership of the dynamically allocated
* object to which it is bound
* User code must dynamically allocate an object to initialize a HasPtr
* and must not delete that object; the HasPtr class will delete it
*/
//private class for use by HasPtr only
class U_Ptr {
friend class HasPtr;
int *ip;
size_t use;
U_Ptr(int *p): ip(p), use(1) { }
~U_Ptr() { delete ip; }
};
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: May 03 05:26AM +0200

On 03-May-17 4:58 AM, fl wrote:
> I don't find the reason on the web. I see pointer ip is the same with 'use'
> on memory usage here.
 
> Could you tell me that?
 
`delete ip;` does the following:
 
If `ip` is not a nullpointer, then
{
1. Destroy the object that `ip` points to
For an `int` pointee this is a no-op, but for an object of class
type it generally involves executing that object's destructor.
2. Deallocate the memory that the object occupied.
This is like cancelling a reservation of seats in a cinema or plane.
It lets others reserve and use those seats. Or memory block.
}
 
These actions do not make sense for an `int`, only for a pointer.
 
 
> U_Ptr(int *p): ip(p), use(1) { }
> ~U_Ptr() { delete ip; }
> };
 
This code is ungood in many ways:
 
• It's not a good idea to allocate an `int` dynamically. The overhead of
dynamic allocation is extreme compared to basic operations like `int`
assignment. Copying an `int` has nearly zero cost.
 
• It's a DIY solution where `std::shared_ptr` or `std::unique_ptr` would
be extremely much more appropriate.
 
• It fails to take charge of copying.
 
• The names do not indicate the purpose of anything.
 
• Everything `private` with `HasPtr` class as a friend, indicates that
this should be part of `HasPtr`, a nested `struct` there.
 
But regarding the last point, rather this class should not exist at all:
one should use a standard library smart pointer unless it can't do the
job. And if a standard library smart pointer was used, instead of this
class, that would still be wrong-ish because single `int` values simply
should not be dynamically allocated.
 
Cheers & hth.,
 
- Alf
Paavo Helde <myfirstname@osa.pri.ee>: May 03 06:27AM +0300

On 3.05.2017 5:58, fl wrote:
> U_Ptr(int *p): ip(p), use(1) { }
> ~U_Ptr() { delete ip; }
> };
 
It is not the pointer what is deleted here, the pointer 'ip' resides
inside the objects of class U_Ptr and cannot be "deleted" in any way
separately, whatever that would mean.
 
The statement 'delete ip;' instead assumes that the pointer points to
some dynamically allocated object in memory, destroys that object and
releases its memory (or alternatively, if the value of ip is nullptr, it
does nothing). In either case, it has no effect to ip itself.
 
hth
Paavo
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)