Thursday, June 14, 2018

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

Nikki Locke <nikki@trumphurst.com>: Jun 14 10:23PM

Available C++ Libraries FAQ
 
URL: http://www.trumphurst.com/cpplibs/
 
This is a searchable list of libraries and utilities (both free
and commercial) available to C++ programmers.
 
If you know of a library which is not in the list, why not fill
in the form at http://www.trumphurst.com/cpplibs/cppsub.php
 
Maintainer: Nikki Locke - if you wish to contact me, please use the form on the website.
nospam <nospam@nospam.invalid>: Jun 14 02:50PM -0400

> follow a page full of stock market movements on your phone. Or given this is
> a C++ forum, try using vi in a shell or eclipse on a phone. You'll soon get
> sick of it and wish for a large screen and a mouse.
 
there are people doing all of that on their tablet and even phone.
 
> Guess what? There's a reason some people have 32 inch monitors, sometimes 2
> or 3 of them to do their jobs.
 
some tasks might require multiple large displays, but the number of
such tasks is rapidly shrinking.
 
you are assuming that today's phones will never improve, that what
exists today is how it always will be.
 
that is a very, very bad assumption.
nospam <nospam@nospam.invalid>: Jun 14 02:50PM -0400


> Apple has been treading water since jobs died.
 
nonsense.
 
apple's market cap is roughly *four* times what it was when steve jobs
died.
nospam <nospam@nospam.invalid>: Jun 14 02:50PM -0400

In article <9jf2idhklihkh7kl5030osbece2vaofml8@4ax.com>, SilverSlimer
 
> Some people want to pay more for a computer with the expectation that
> the model will be lighter, more powerful, have better battery life or
> simply look prettier
 
true.
 
that's why there's a wide range of products in a wide range of prices.
 
no single product is ideal for everyone.
 
> but that is the smaller amount of people.
 
not true.
 
> >nevertheless, 15 years ago, they released a $499 mac mini.
 
> Which is basically useless if you don't pay additional money for the
> monitor, keyboard and mouse.
 
that's no different than for windows systems.
 
very few windows pcs are all-in-one imac style.
 
most pcs a box where the user needs to add a display, keyboard and
mouse.
 
the microsoft surface studio is an all-in-one, comes with a large
pivoting display and *starts* at $3000, nearly *twice* that of a
similar size imac:
<https://www.microsoft.com/en-us/p/surface-studio/8xcw9bbpvfv9?activetab
=pivot%3aoverviewtab>
 
imacs start at $1800 for a 27" (similar size to the surface studio) or
$1100 for a 21". not everyone needs a giant display.
 
is a large pivoting display worth the extra $1200?
for some people yes, for others no.
 
choice is good.
 
 
> >mobile is the future.
 
> Agreed, and Apple does very well in that category despite being
> _functionally_ inferior to its competition.
 
except that it's *not* functionally inferior.
 
> needs the customization options of Android and simply wants a machine
> which does everything they need to do on a daily basis... e-mail,
> browsing, media playback.
 
of course, not everyone is aware of what can be done with apple
products, blindly believing the myths.
nospam <nospam@nospam.invalid>: Jun 14 02:50PM -0400

In article <pfttpg$euj$1@dont-email.me>, Mayayana
 
> The problem with Apple isn't only price. They
> want to sell devices, not software.
 
completely false, but so what?
 
there is nothing wrong with selling devices and not software. a lot of
companies do exactly that.
 
> They want
> their devices locked down.
 
except that they aren't locked down.
 
it was *microsoft* who came out with windows 10s, which can only run
store apps. no such version of macos exists that *only* runs store
apps.
 
> They want their market
> to be consumer entertainment, not "productivity".
 
nonsense. numerous studies show mac users to be more productive.
 
> Their software development system isn't as open.
 
wrong again. not only is it more open, but it's based on open source
software.
 
> have the problem that it's a restricted, ninny-headed
> system with limited software and almost no
> hardware flexibility.
 
more ignorant bullshit.
 
> give up the reasons that you use a computer for
> anything beyond photo editing or online consumer
> services.
 
nonsense.
 
> lauded Jobs's genius for guessing what people
> wanted. But he never guessed what anyone
> wanted.
 
he guessed a lot better than most people did.
 
> superiority and noble intentions while he's
> building more diddle-devices with slave labor and
> perfecting the art of tax evasion.
 
nonsense.
 
> I don't think Apple is the place to look for
> anything healthy or useful in the future.
 
clearly.
nospam <nospam@nospam.invalid>: Jun 14 02:50PM -0400

In article <fodcfiFne66U2@mid.individual.net>, Ian Collins
 
> Neither is rebuilding every application if you choose to upgrade your
> OS. Neither is being unable to upgrade to a supported OS version
> because of legacy applications.
 
users don't rebuild apps. developers do, which is part of the price you
pay for quality software.
 
updating apps is easy, with many apps automatically updating
themselves. the user doesn't need to do much, if anything.
 
if the app hasn't been updated and no alternative exists, then whatever
that app did was not in high demand.
 
> the OS and good for developers like me with clients running multiple OS
> versions. All I had to do was build on the oldest supported version and
> know my stuff would work on all.
 
your apps are the lowest common denominator across all platforms.
 
that may work in certain cases but definitely not all. most people do
*not* have a wide variety of platforms and want to take full advantage
of everything their hardware can do.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jun 14 03:06PM -0400

On 6/14/2018 2:50 PM, nospam wrote:
> [snip; dr]
 
If you use your real name and sign your posts I'll communicate with
you.
 
--
Rick C. Hodgin
Ian Collins <ian-news@hotmail.com>: Jun 15 07:23AM +1200

On 15/06/18 02:03, Rick C. Hodgin wrote:
>> on all.
 
> The more I learn about Solaris the more impressed I am. Is the code
> base from Solaris (before it was closed up by Oracle) still available?
 
It lives on here: https://wiki.illumos.org/display/illumos/illumos+Home
 
--
Ian.
SilverSlimer <.m@nsn.s>: Jun 14 06:04PM -0400

On Thu, 14 Jun 2018 14:50:19 -0400, nospam <nospam@nospam.invalid>
wrote:
 
> include freezing, unexpected shutdowns, and touchscreen response
> issues. Reuters reported on the latest Consumer Reports reliability
> study, which was published on Thursday.
 
Sad to hear that it doesn't beat the iPad Pro.
Ian Collins <ian-news@hotmail.com>: Jun 15 07:42AM +1200

On 15/06/18 04:06, James Kuyper wrote:
 
> ....
>> None of the above claims TDD test to be the one and only specification.
 
> "*the* true requirements".
 
I've always interpreted that as the true requirements for that unit of
code. If that interpretation wasn't the case, acceptance tests wouldn't
be required, would they? It is certainly how Kent Beck presented them.
 
--
Ian.
Daniel <danielaparker@gmail.com>: Jun 14 01:44PM -0700

On Thursday, June 14, 2018 at 2:50:25 PM UTC-4, James Kuyper wrote:
 
> so I can learn something about TDD from the discussion
 
You're not going to learn much about TDD from the discussion in these posts
:-) I would suggest reading Robert Martin, he has the advantage of being
very clear. In Robert Martin's thinking, at least circa turn of the century,
tests *are* the specification, people who don't do unit tests for everything
really *can't* know that their code is correct. He doesn't resort to
ambiguity in the way that Ian Collins does, unlike Collins, he doesn't pull
his punches or back down. And in being clear, readers, or people having a
conversation with him, can form a clear opinion of exactly where they agree
with him and where they don't. And because he is a serious person, his
arguments have to be taken seriously, even when they seem extreme.
 
Of course you should also sample Kent Beck's Test- Driven Development: By
Example. There's nothing hard in it, a quick sample read will give you the
ideas. You need to do that if you want to form an opinion about it yourself.
 
Daniel
James Kuyper <jameskuyper@alumni.caltech.edu>: Jun 14 04:52PM -0400

On 06/14/2018 03:42 PM, Ian Collins wrote:
 
> I've always interpreted that as the true requirements for that unit of
> code. If that interpretation wasn't the case, acceptance tests wouldn't
> be required, would they?
 
I don't follow the reasoning behind that argument, possibly because it
reflects your use of concepts I'm unfamiliar with.
 
It seems to me to be perfectly normal for there to be requirements for a
given unit of code that are written in English, and cover an untestably
large set of possible test cases, a set that would require more time
than anyone can spare to test them (possibly more time than the current
lifetime of the universe). For instance, the requirements might specify
what the output of f(x) should be for all representable values of x,
where x is long double, on a machine where long double is 128 bits,
which means that 2^128 different test cases would need to be tested, in
order for the test to impose the same requirement as is specified by the
English text. It gets even worse if the function takes as few as two
arguments, and immensely worse if the function takes the entire contents
of a large file as input.
It also strikes me as normal to cope with such a situation by creating a
an acceptance test that, of necessity, can only test a small subset of
those possible cases. Passing such a test would not prove that the
English requirements have been met, but failing it would prove that they
had not been. Therefore, the test could not reasonably be interpreted as
specifying requirements equivalent to the "true requirements" described
in English. However, that wouldn't render the test any less important.
Daniel <danielaparker@gmail.com>: Jun 14 01:53PM -0700

On Thursday, June 14, 2018 at 4:44:40 PM UTC-4, Daniel wrote:
> You need to do that if you want to form an opinion about it yourself.
 
I would add that most TDD people will tell you that you can't have an
opinion about TDD unless you've tried TDD yourself. Robert Martin would
express that as "write about what you know, not about what you think." Not
being a TDD person myself, I don't fully buy that, but there it is.
 
Daniel
legalize+jeeves@mail.xmission.com (Richard): Jun 14 09:14PM

[Please do not mail me a copy of your followup]
 
Tim Rentsch <txr@alumni.caltech.edu> spake the secret code
 
>> On a side note, I'm curious what your thoughts are on this:
>> https://pdfs.semanticscholar.org/7745/5588b153bc721015ddfe9ffe82f110988450.pdf
 
>Another very interesting read. Keep those good links a comin'.
 
Meh. I only skimmed through the document due to lack of time, but the
cover sheet already told me something:
 
i) this "considered harmful" opinion is 15 years old
ii) the author seems to have an affinity for bureaucracy
 
Also, XP is not the same as TDD. Many people do TDD without doing XP.
 
From a friend of mine who did take the time to read it:
 
Subject: Re: "Extreme Programming Considered Harmful"
---------
XP led to (my comments in parenthesis):
 
? rework as a norm, (vs bug hunting and rewrite every five versions)
? error prone systems, (I never saw the evidence of this)
? non-maintainable systems, (maintainable meaning limited bug fixes?)
? frustrated staff, and (yeah, leadership was no longer able to blame
dev&qa)
? few heroes. (yep, no longer one guy staying up all night to fix
something)
 
Reviewing this 15 years later and none of his arguments hold. Not to
mention, only a few companies claim to still be doing XP and they are
successful.
--
"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>
legalize+jeeves@mail.xmission.com (Richard): Jun 14 09:29PM

[Please do not mail me a copy of your followup]
 
James Kuyper <jameskuyper@alumni.caltech.edu> spake the secret code
>encourage people to address each other's points directly, so I can learn
>something about TDD from the discussion other than the fact that some of
>you strongly believe in it, and the others do not.
 
I don't like characterizing adoption or aversion to TDD as a "belief".
For me, TDD isn't a "belief" akin to some magical spiritual mystical
thing of which I can convince noone else.
 
TDD is simply a way of working that made me more productive by reducing
the time between the creation of errors and the fixing of those same
errors. It didn't reduce my error rate, but it reduced the lifetime of
those errors by allowing me to identify them within seconds of making
the errors.
 
Maybe it won't make you more productive. You won't know until you try
it (properly) for a reasonable period of time, like 3-6 months. Like
any new way of working, you can't judge it from limited exposure
because it takes time to become proficient at the new way of working.
Just like an emacs user switching to vi won't be as effective in the
new environment right away, you need to spend some time doing strict
TDD to get the hang of it.
 
I say "strict TDD" and "try it (properly)" because for whatever reason
lots of people who try TDD for the first time in isolation without
guidance from a seasoned practitioner end up doing it incorrectly.
The failure modes are various, but in the end they didn't get the "real
experience" they got some degraded experience and ended up blaming TDD
for the result. It would be like trying to learn a martial art yourself
without a sensei and only from a book without ever having seen anyone
actually do it.
--
"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>
Paavo Helde <myfirstname@osa.pri.ee>: Jun 15 12:30AM +0300

On 14.06.2018 23:52, James Kuyper wrote:
> which means that 2^128 different test cases would need to be tested, in
> order for the test to impose the same requirement as is specified by the
> English text.
 
The unit test is meant to test the functionality of the given "unit". In
software this unit is typically a function or a class. If this function
calculates x+1 at some point, this does not mean that the unit test has
to verify that x+1 is calculated correctly for all 2^64 inputs. It is
assumed that the compiler and the hardware are capable of calculating
x+1 correctly for all the possible ranges of x values in this function.
If there are any unit tests for that these are developed and used by the
hardware manufacturers.
 
The same holds for anything other the test is using. It does not need to
test the functions the unit calls - these are supposed to have their own
unit tests somewhere else. It only needs to test if it passes valid
parameters to those functions. which is a much easier task.
 
So the complexity of the test is not in the range of 2^128, but rather
related to the cyclometric complexity of the function, which is much
more tractable. This is what makes the tests useful, covering e.g. 2^4
cases of 2^128 would be worthless, but covering 2^4 cases in a function
having 2^5 potential code branches and special parameter values is
already very useful.
 
Of course the tests cannot fully replace the requirements and the
design, but they can be helpful for maintaining those requirements and
designs.
Melzzzzz <Melzzzzz@zzzzz.com>: Jun 14 06:58PM


> Stroustrup did somewhere explain that 'this' is a reference that uses
> pointer's syntax because reference wasn't yet invented when 'this' was
> introduced into language.
 
What's wrong with pointers? At least you can check if this is null ;)
 
--
press any key to continue or any other to quit...
Paavo Helde <myfirstname@osa.pri.ee>: Jun 14 10:17PM +0300

On 14.06.2018 21:58, Melzzzzz wrote:
>> pointer's syntax because reference wasn't yet invented when 'this' was
>> introduced into language.
 
> What's wrong with pointers? At least you can check if this is null ;)
 
This check tends to get optimized away nowadays by some compilers.
Melzzzzz <Melzzzzz@zzzzz.com>: Jun 14 07:34PM

>>> introduced into language.
 
>> What's wrong with pointers? At least you can check if this is null ;)
 
> This check tends to get optimized away nowadays by some compilers.
 
Bah. That's nasty.
 
 
--
press any key to continue or any other to quit...
David Brown <david.brown@hesbynett.no>: Jun 14 09:40PM +0200

On 14/06/18 21:34, Melzzzzz wrote:
 
>>> What's wrong with pointers? At least you can check if this is null ;)
 
>> This check tends to get optimized away nowadays by some compilers.
 
> Bah. That's nasty.
 
Null pointer checks get optimised away if it is safe to optimise them
away. If the pointer could legally be null, the check is carried out -
if you've already demonstrated that it cannot possibly be null, the
check is skipped. That seems fair enough to me.
red floyd <dont.bother@its.invalid>: Jun 14 09:55AM -0700

On 6/14/2018 2:55 AM, Rosario19 wrote:
> }
 
> and the sys not automatic call it... this can be useful for doing
> arrays of type T using malloc
 
The other thing is that placement new is almost ALWAYS the wrong thing
to do. If all you are trying to do is allocate a T dynamically, then
just do
 
T* p = new T;
Rosario19 <Ros@invalid.invalid>: Jun 14 12:17PM +0200

i would like to write the Squfof function in C or C++, i see in
 
http://homes.cerias.purdue.edu/~ssw/squfof.pdf
 
http://guan.cse.nsysu.edu.tw/note/squfof.pdf
 
http://pari.math.u-bordeaux.fr/dochtml/scripts/squfof.gp.html
 
all these paper propose something it seems different in its
implementation, at my first seen
 
than i think one could use one 64 bit type, signed
for build the "form" f=(a,b,c) type [with a,b,c i64] (or struct) and
doing all
 
for sqrt() of one 64 bit signed integer, can i use the
long double sqrtl() ?
 
something as
 
#define sqrti64(x) (i64)sqrtl((long double)x)

i64 a,b;
...
b=sqrti64(a);
 
[where i64 is a define of one interger type of 64 bit]i think yes...
what would be the link it is better to follow?
 
thank you
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)