Tuesday, February 14, 2017

Digest for comp.lang.c++@googlegroups.com - 17 updates in 7 topics

Andrey Karpov <karpov2007@gmail.com>: Feb 13 10:30PM -0800

> but have you run PVS on the source of the X Window System?
 
No, we haven't checked X Windows System yet. Here is the full list of articles about projects that we have checked by this moment: http://www.viva64.com/en/inspections/
legalize+jeeves@mail.xmission.com (Richard): Feb 14 07:46PM

[Please do not mail me a copy of your followup]
 
Andrey Karpov <karpov2007@gmail.com> spake the secret code
 
>No, we haven't checked X Windows System yet. Here is the full list of
>articles about projects that we have checked by this moment:
>http://www.viva64.com/en/inspections/
 
Cool.
 
If you want a real torturous pile of code, try iterated dynamics :)
<https://github.com/legalizeadulthood/iterated-dynamics>
 
It has a long heritage as a 16-bit DOS application and I know it has
many suspicious things in it. I've tried to clean up as much as I
could, but there always seems to be more :).
--
"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: Feb 13 07:01PM -0800

On Monday, February 13, 2017 at 2:06:39 PM UTC-6, Christiano wrote:
> stroutrup's book ( ISBN-13: 978-0321992789 ) very relevant and I decided
> to do a scan and post here:
 
> http://imgur.com/FPkvQ91
 
 
I hope you wrote to the author and publisher and got their
permission to post that.
 
 
Brian
scott@slp53.sl.home (Scott Lurndal): Feb 14 01:43PM

>changed can be a huge advantage in large programs.
 
>• The class definition gets larger. Consequently, it can be harder to
>find the members among the member function definitions.
 
And this is the key argument!
 
>read. We rarely inline a function that consists of more than one or two
>expressions
></quote>
 
Actually, it's been the practice of projects that I've worked on
since 1989 to not put member function bodies in the class declaration
_even if they should be inline_, but rather to place the member
function bodies following the class declaration in the same header file
using the 'inline' keyword.
Wouter van Ooijen <wouter@voti.nl>: Feb 14 07:19PM +0100

Op 14-Feb-17 om 14:43 schreef Scott Lurndal:
 
>> • The class definition gets larger. Consequently, it can be harder to
>> find the members among the member function definitions.
 
> And this is the key argument!
 
Yes, way back when the source was the interface documentation. Nowadays
we have documentation generators (extracter/formatters would be a better
term) that generate something that is much better readable, so that key
argument is no longer valid.
 
In my experience (but YMMV) I find the code *more* readable when the
implementation is in the header file.
 
Wouter "Objects? No Thanks!" van Ooijen
scott@slp53.sl.home (Scott Lurndal): Feb 14 01:39PM


>That's not the same thing - the above uses pow(), because FLT_RADIX
>does not have to be 2. And it's its an exponential function, not a
>logarithm.
 
"something like" in this case means call 'pow' directly in
a constexpr function. It will be evaluated at compile time.
Robert Wessel <robertwessel2@yahoo.com>: Feb 14 08:02AM -0600

On Tue, 14 Feb 2017 13:39:03 GMT, scott@slp53.sl.home (Scott Lurndal)
wrote:
 
>>logarithm.
 
>"something like" in this case means call 'pow' directly in
>a constexpr function. It will be evaluated at compile time.
 
 
It would have to be an custom version of pow(), one presumably limited
to integer arguments, that would be implemented as a constexpr
function. pow() itself, is not, AFAIK, valid in a constexpr function.
scott@slp53.sl.home (Scott Lurndal): Feb 14 05:30PM


>It would have to be an custom version of pow(), one presumably limited
>to integer arguments, that would be implemented as a constexpr
>function. pow() itself, is not, AFAIK, valid in a constexpr function.
 
$ cat /tmp/a.cpp
#include <float.h>
#include <math.h>
 
constexpr double omega(void) { return pow(FLT_RADIX, DBL_MANT_DIG) - 1; }
 
int
main(int argc, const char **argv, const char **envp)
{
double o = omega();
 
return (int)o;
}
 
$ g++ -std=c++11 -o /tmp/a /tmp/a.cpp
$
ram@zedat.fu-berlin.de (Stefan Ram): Feb 14 03:31AM

>auto ff = []{};
>what's the type of (+ff), and what's the type of (*ff) ?
 
void (*)()
void ()
 
here (gcc).
 
>And what is happening under the hood for `+' and `*' ?
 
The operand of the unary + operator shall have arithmetic,
unscoped enumeration, or pointer type. So, (+ff) is a
possible constraint violation, because we cannot prove
that the closure type has the required properties?
 
The operand of the unary * operator shall have arithmetic,
unscoped enumeration, or pointer type. So, (*ff) is a
possible constraint violation, because we cannot prove
that the closure type has the required properties?
ram@zedat.fu-berlin.de (Stefan Ram): Feb 14 03:43AM

>unscoped enumeration, or pointer type. So, (*ff) is a
>possible constraint violation, because we cannot prove
>that the closure type has the required properties?
 
Overloaded operators obey the rules for syntax and
evaluation order, but the requirements of operand type and
value category are replaced by the rules for function call.
 
The closure type for a non-generic lambda-expression with no
lambda-capture has a conversion function to pointer to function.
 
So, in (+ff) and (*ff), this conversion function might be used,
and then it would be no constraint violation.
ram@zedat.fu-berlin.de (Stefan Ram): Feb 14 03:24PM

>>that the closure type has the required properties?
>I haven't tried this but `[]{}` has an implicit conversion to
>`void(*)()` so I think probably `*ff` should be valid.
 
Yes, as I then - a little bit later - also wrote in my
other post.
 
The above sentence with »shall« was a quotation from a
recent draft, and when it's read in isolation, it might be
deemed incomplete or misleading, because it does not mention
the possibility of an operand of class type. This possibility,
however was mentioned once for all operators in
a note at the start of the section about operators.
Shiyao Ma <i@introo.me>: Feb 13 06:27PM -0800

Hi,
given the following code:
 
auto ff = []{};
 
what's the type of (+ff), and what's the type of (*ff) ?
 
And what is happening under the hood for `+' and `*' ?
 
 
Shiyao
Shiyao Ma <i@introo.me>: Feb 13 11:29PM -0800

So to end my own question.
ff implicitly converts to pointer to function.
 
and the operator+ and operator* accepts function pointer.
Juha Nieminen <nospam@thanks.invalid>: Feb 14 11:19AM

> auto ff = []{};
 
A lambda that doesn't capture anything converts implicitly to a regular
function. However, I'm not sure you can assume those operators will work
if the lambda captures something (in which case its type will be some
compiler-specific internal type, possibly some kind of struct, or maybe
some kind of non-function pointer).
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 14 03:10PM +0100

On 14.02.2017 04:31, Stefan Ram wrote:
> unscoped enumeration, or pointer type. So, (*ff) is a
> possible constraint violation, because we cannot prove
> that the closure type has the required properties?
 
I haven't tried this but `[]{}` has an implicit conversion to
`void(*)()` so I think probably `*ff` should be valid.
 
 
Cheers!
 
- Alf
Jorgen Grahn <grahn+nntp@snipabacken.se>: Feb 14 06:31AM

On Sun, 2017-02-12, Prroffessorr Fir Kenobi wrote:
> driver maybe) .. i heard that this delay is even in a
> range of miliseconds (it means is quite big) [im not sure
> though as to this information and searching for more info]
 
Keep this in mind: sound travels arount 340 m in a second, i.e. 0.34 m
in a millisecond. You don't notice any delay in sound (from e.g. a
kid kicking a ball against a wall) unless you are something like 50 m
away.
 
I think a delay of many, many milliseconds in the driver would be fine.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
jared@hireclub.io: Feb 13 05:29PM -0800

Hello, I am looking for an outstanding Software Engineer with C++ on Unix expertise.
 
Please email me at jared@hireclub.io
 
Phantom Cyber just raised Series B capital, and is a very rapidly growing company. Their CEO, Oliver Freidrichs, is a "serial entrepreneur" who is highly respected in the security space. He's successfully taken two companies to acquisition, and this is his third go. They noticed a gap in security automation at enterprise companies, and have addressed this issue through automation. They have created automation within enterprise Security Operations Centers where they automate these companies data so that when an incident or event happens, that information is automatically prioritized and brought to the proper escalation level. Currently, this process is too manual.
 
This is a great opportunity for an engineer to join a rapidly growing company, which has 40 total employees. The company is located in Palo Alto and is well on the road to success.
 
Software Engineer - C/C++/Unix
Palo Alto, CA Engineering
 
Description
Phantom is building a fast paced team and looking to hire top engineering talent with exceptional expertise with Unix operating systems and C/C++ programming languages.
The candidate must have strong engineering discipline and an exceptional understanding of design patterns and multi-threaded high performance application architectures.
 
Responsibilities
• Design and implement highly scalable solutions and architectures using the most appropriate design patterns.
• Follow and use best Object Oriented design principles for a maintainable and extensible set of components.
• Implement modular and testable code: cleanly, efficiently, and with full unit testing capabilities.
• Implement modern algorithms for efficient computing tasks.
• Effectively interact with software development, QA, and release teams.
 
Skills and Qualifications
• 3+ years experience in C/C++ and Python
• Solid understanding of OS principles (especially Unix) and multi-threaded applications
• Solid understanding of RDBMS, Postgres and SQL
• Solid understanding of the development cycle of any software based product
• Solid understanding of network layers and network security fundamentals
• B.S. in Computer science, and/or related work experience.
 
Bonus skills
• Experience with Security technologies
• Experience with Mobile app development for Android and iOS
• Experience with virtualization and/or clustering systems
• Experience with security infrastructure equipment or software, SIEM, IPS, UTMs, etc.
• Experience in scripting skills in any scripting language (Python required, Shell, Tcl/Expect, etc)
• Network architecture skills
 
Please email me at jared@hireclub.io
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)