Thursday, October 22, 2015

Digest for comp.lang.c++@googlegroups.com - 16 updates in 6 topics

taylor@audulus.com: Oct 21 08:24PM -0700

On Tuesday, October 20, 2015 at 6:17:55 PM UTC-7, Nobody wrote:
> needs to exist for as long as *something* references it and (ideally) no
> longer than that, but there's no easy way of determining what could
> reference it.
 
Cool. Makes sense.
 
So what would you recommend for ensuring clients of this API can't create
dangling pointers? For example, I were to wrap this out to Python, I'd
have to ensure the client can't create a dangling pointer.
legalize+jeeves@mail.xmission.com (Richard): Oct 22 05:11PM

[Please do not mail me a copy of your followup]
 
taylor@audulus.com spake the secret code
 
>So what would you recommend for ensuring clients of this API can't create
>dangling pointers? For example, I were to wrap this out to Python, I'd
>have to ensure the client can't create a dangling pointer.
 
In my opinion, you can guard against some things, but people who are
determined to write code that is abusive can't be stopped. Strive for
the former and don't waste any brain cycles on the latter.
 
There's a bunch of stuff in the new C++ Core Guidelines being proposed
by Bjarne Stroustrup and Herb Sutter with contributions from all over
the community on how to guard against lifetime errors. Some of this
may help you, but when exposing C++ to a garbage collected language
like python, it may not be as relevant.
 
<https://github.com/isocpp/CppCoreGuidelines>
 
CppCon 2015: Bjarne Stroustrup "Writing Good C++14"
<https://www.youtube.com/watch?v=1OEu9C51K2A>
 
CppCon 2015: Herb Sutter "Writing Good C++14... By Default"
<https://www.youtube.com/watch?v=hEx5DNLWGgA>
--
"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>
asetofsymbols@gmail.com: Oct 22 01:53PM -0700

Richard wrote:
><https://github.com/isocpp/CppCoreGuidelines>
 
The problems he speak are already
solved for me, in some code, using
one malloc allocator that allow
check for leaks at end of
program, and one free function
that see if some write
is in the 2 borders of memory
returned (and see if that pointer
is right to be free)
I not use in the C++
new or delete
nor I understand well them
taylor@audulus.com: Oct 22 02:25PM -0700

On Thursday, October 22, 2015 at 10:11:28 AM UTC-7, Richard wrote:
 
> In my opinion, you can guard against some things, but people who are
> determined to write code that is abusive can't be stopped. Strive for
> the former and don't waste any brain cycles on the latter.
 
Well, if a user can crash my app because they misused the scripting API,
then that's a bug. That's why I'd like the code to be safe.
 
> <https://www.youtube.com/watch?v=1OEu9C51K2A>
 
> CppCon 2015: Herb Sutter "Writing Good C++14... By Default"
> <https://www.youtube.com/watch?v=hEx5DNLWGgA>
 
I appreciate you mentioning that. I've been watching those videos intensely the
past few days :)
David Brown <david.brown@hesbynett.no>: Oct 22 09:31AM +0200

On 21/10/15 21:20, Lynn McGuire wrote:
 
> ...
 
> #include LATEST_DECODE_METHOD
 
> and this worked fine in Microsoft Visual Studio 2005.
 
That's legal, but almost certainly a bad idea IMHO. It makes it more
difficult to figure out what is being included and at what point in the
program - you have to trace through other preprocessor stuff such as
macros. That's a pain for human readers - and it could be an issue with
automated tools too since the tools have to run a full cpp preprocessor
in order to identify the include file graph. Obviously compilers will
have no problem - perhaps some editors, documentation tools, automatic
build systems, etc., will have trouble or be less efficient when faced
with calculated includes.
 
Of course I don't know anything about your project except what you have
written here, so maybe there are particular reasons for using this
organisation. But I would be tempted to use something like:
 
// Files that had #include LATEST_DECODE_METHOD
#include "latest_decode_method.h"
 
 
// In latest_decode_method.h
#include "decodeVer14.h"
 
These keeps things neat and clear in the main code, but lets you easily
change the decoder version in a single place.
Lynn McGuire <lmc@winsim.com>: Oct 22 04:10PM -0500

On 10/22/2015 2:31 AM, David Brown wrote:
> #include "decodeVer14.h"
 
> These keeps things neat and clear in the main code, but lets you easily
> change the decoder version in a single place.
 
That would work also. But, I've got 20,000 files in my project. File minimization is a goal of mine. My sandbox is 12 GB and growing.
 
Thanks,
Lynn
Prroffessorr Fir Kenobi <profesor.fir@gmail.com>: Oct 22 08:54AM -0700

W dniu czwartek, 22 października 2015 01:25:38 UTC+2 użytkownik Ramine napisał:
 
> https://www.youtube.com/watch?v=GUYfqlAEn1k
 
> Thank you,
> Amine Moulay Ramdane.
 
i want to sare with you this words - fuck you preposterous spammer and abuser..
 
to some fellows here, this lame ramine
may try to cheat you his posts are not spam
but this is really a especially devestating
spam (as he is not able on any talk he uses
this group to flood his really unresponsible and most probably extremally antiproductive lunaticity with a strong ability to zombiac drain and kill the hosting group )
 
there is one moderately good way of resolve this abuser problem: delete its productions
without reading as quick as possible and go one to teh real matter, not devoting you brain cells to this lunacy - or youre poisoned
 
[i added few words on it here as i get
a bit pissed of by this devastating spamer,]
woodbrian77@gmail.com: Oct 22 09:25AM -0700

Prroffessorr,
 
Please don't swear here.
 
Brian
Ebenezer Enterprises
http://webEbenezer.net
Prroffessorr Fir Kenobi <profesor.fir@gmail.com>: Oct 22 09:51AM -0700

> Prroffessorr,
 
> Please don't swear here.
 
fuck off
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 22 07:57PM +0200

> Prroffessorr,
 
> Please don't swear here.
 
Uhm, he's not a professor. He's a troll. Probably the same as Mr. Ramine.
 
I've given up my some-years-ago effort of killfiling all the trolls.
There was no end to it, and it turned out to be problematic with the
part-time trolls, those who are good contributors part of the time, even
some with high standing in their work environment, and trolling part of
the time, depending on context and who's involved etc. (i.e. treating
the group variously as technical and as a social playground, depending
on their whims and preferences). So given that I failed I won't
recommend killfiling to you, but maybe just note who's good and who's
bad and use that in your brainware (not to say brianware) filtering.
 
 
Cheers & hth.,
 
- Alf
woodbrian77@gmail.com: Oct 22 01:19PM -0700

On Thursday, October 22, 2015 at 12:58:09 PM UTC-5, Alf P. Steinbach wrote:
> > Prroffessorr,
 
> > Please don't swear here.
 
> Uhm, he's not a professor. He's a troll. Probably the same as Mr. Ramine.
 
He's a potty mouth. That's the only thing I know
for sure.
 

> some with high standing in their work environment, and trolling part of
> the time, depending on context and who's involved etc. (i.e. treating
> the group variously as technical and as a social playground, depending
 
From what I can tell the group has been "C++ and
beyond" before that was the name of a conference.
 
 
Code Owl <codeowl@gmail.com>: Oct 21 09:57PM -0700

Hi there,
 
Basically I have created a simple C++ Static Library and linked it to a simple Console Application following the steps here:
https://msdn.microsoft.com/en-us/library/ms235627.aspx
 
All this worked as expected.
 
Then I added a second class (.cpp and .h) to the static library and I can not get that to link into the console app. The static library builds successfully but the console app throws the following error when I attempt to build it:
 
fatal error C1083: Cannot open include file: 'MyMathFuncs2.h': No such file or directory
 
Yet that file does exist, and it is in the same dir as the header that does work.
 
I have tried Clean, Rebuild of the console app and then re-adding in the new header and it still fails with the same error. Strangely if I delete the original class and header from the static library and then build the console app with a reference to the original class it builds successfully... even though the header doesn't exist.
 
What am I doing wrong here?
 
See full details of what I did here:
http://stackoverflow.com/questions/33258674/why-wont-my-simple-c-console-app-see-my-simple-c-static-library-headers-in
 
Thank you for your time,
 
Scott
Paavo Helde <myfirstname@osa.pri.ee>: Oct 22 12:42AM -0500

Code Owl <codeowl@gmail.com> wrote in
> when I attempt to build it:
 
> fatal error C1083: Cannot open include file: 'MyMathFuncs2.h': No such
> file or directory
 
Looks like you have messed something up. I even looked at the
stackoverflow page - yup, MyMathFuncs2 is a class name, not a header file
name. The header file name is MathFuncsLib2.h.
 
A tip: when you post problems here or elsewhere, include only the
relevant full set of *non-working* code. Currently on the stackoverflow
page you have listed a complete working solution (not needed) and a
partial non-working solution (most important bits missing), this is not
helpful.
 
Cheers
Paavo
Code Owl <codeowl@gmail.com>: Oct 22 12:46AM -0700

Paavo,
 
Great advise mate, I will take it on board. In fact I just redid the stack overflow question with screen shots of all the classes and an attachment of the VS solution... However in the process of doing such detailed documentation of the problem I found the cause of the issue!!
 
I had originally created the static lib project in the wrong location, so I removed it from the project and then copied it to another location (the same dir as the solution) and the added the existing project at the new location back into the solution. The problem was that the reference in the console application was still pointing to the original copy of the project no longer linked to the solution, and this is why my console app was not aware of changes I was making to the project linked to the solution.
 
Thanks again for your input mate ;-)
 
Regards,
 
Scott
bleachbot <bleachbot@httrack.com>: Oct 22 02:11AM +0200

Ramine <ramine@1.1>: Oct 21 08:13PM -0700

Hello...
 
 
I was thinking more and more...
 
And now i have come to an interesting subject...
 
Perhaps you will ask me a question as this:
 
Amine, why have you invented your new scalable distributed reader-writer
mutex, and why have you not simply used transactional memory like: Intel
TSX or others..
 
Answer:
 
You have to know that transactional memory is an general purpose
optimistic mechanism, other than that in case of conflicts it can
rollback in a lockfree manner.. so this not good because it can cause
starvation and also it's not energy efficient.
 
But my new scalable distributed reader-writer mutex can be configured
easily to be starvation-free and to be energy efficient using my
scalable RWLockX that is energy efficient because it doesn't spin-wait
but uses my portable SemaMonitor and portable event objects.
 
So all in all my scalable distributed reader-writer mutex is still
an interresting synchronisation mechanism to use, and also my new
algorithm of a scalable reader-writer mutex takes care of false-sharing
and it is now sequential consistent and like in Seqlock or RCU , my new
scalable distributed reader-writer mutex doesn't use any atomic
operations and/or StoreLoad style memory barriers on the reader side, so
it's very fast and scalable..but you have to use the define's option
TLW_RWLockX or the define's option TRWLockX inside the defines1.inc file
for that.
 
 
You can download it from:
 
https://sites.google.com/site/aminer68/scalable-distributed-reader-writer-mutex
 
 
 
Thank you for your time.
 
 
Amine Moulay Ramdane.
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)