Wednesday, June 13, 2018

Digest for comp.lang.c++@googlegroups.com - 25 updates in 3 topics

Char Jackson <none@none.invalid>: Jun 13 01:56AM -0500

On Tue, 12 Jun 2018 18:22:05 -0400, "Rick C. Hodgin"
>It is like some peeping Tom pervert watching you as you go. Such a
>thing should only be done under court order, and only when you are
>under suspicion for some crime.
 
I think they believe that doing the right thing would leave money on the
table, and since the current laws seem to permit them to do as they
like, they do as they like. Ethics, fairness, a sense of right, whatever
you want to call it, I think it's out the window until the laws catch
up. Even when the laws catch up, however, they'll catch up to where we
are now. Tech companies will have moved far past this point by then, if
that's even possible. If there are dollars out there, they'll hunt them
down.
boltar@cylonHQ.com: Jun 13 09:02AM


>The only reason people are buying Windows 10 is because they have
>no choice if they want to run Windows software under a currently
>supported OS.
 
I suspect if Apple reduced their absurd prices to a sensible level they'd
probably clean up in the desktop market and with a bit of effort they could
re-enter the server market with OS/X. Unfortunately they seem more interested
in short term profit flogging their iOS devices rather than making any long
term investment in the OS/X platform which using a fraction of their cash pile
could be turned into a decent server OS (along with dumping the hideous
objective-C which should have been strangled at birth).
SilverSlimer <.m@nsn.s>: Jun 13 08:54AM -0400

On Tue, 12 Jun 2018 16:35:20 -0400, "Rick C. Hodgin"
>> usable operating system.
 
>React OS has active development and is fairly stable. I ran it in
>VirtualBox a couple months back and it was impressive.
 
Would you say that it can replace Windows on a day-to-day basis? Why
not?
 
>taken much effort to maintain for backward compatibility. Other OSes
>do it, for example.
 
>It's the danger with monopolies.
 
In the case of Linux, software stops working too though. On the other
hand, the source code is freely available for anyone to take that
project and recompile it to work with the newer editions of Linux.
It's not rare to find open-source projects which depend on package
versions from like 2003, but nobody paid money for those projects and
they therefore have no obligation to keep anything current like
Microsoft might.
SilverSlimer <.m@nsn.s>: Jun 13 09:01AM -0400

On Tue, 12 Jun 2018 17:15:03 -0400, "Rick C. Hodgin"
>run on today's hardware if they rely on BIOS, for example, and you
>buy a BIOS-supporting motherboard.
 
>New functionality can be added without breaking anything old.
 
Software made for Windows in 1992 should still work in some way in
2018 IMO. I doubt that too many people are looking to run software
made for 3.1, but if the Windows product is to have continuity, its
legacy apps should be just as functional twenty-six years later. It's
not best for business, but it's best for their reputation to say the
least. I can't imagine a good reason for dropping compatibility as
adding a layer to aid Windows 3.1 or even 9x compatibility is not
likely to take more than about 500MB which is trivial on an operating
system installation today.
 
>Windows software. You can use WINE and a few others that may or may
>not work. But for the Windows ecosystem, you're stuck with what
>Microsoft gives you.
 
The same way that you're stuck with what Apple gives you to run legacy
Mac OS Classic apps (all of which no longer function) or apps from
around 2002.
SilverSlimer <.m@nsn.s>: Jun 13 09:05AM -0400

On Tue, 12 Jun 2018 16:43:13 -0500, Char Jackson <none@none.invalid>
wrote:
 
>with the more reliable versions of Windows, the look on their faces
>tells all you need to know. As a result, I got permission to upgrade
>back to Windows 7 and all is once again well.
 
Considering the excuse for downtime, you would think that companies
would want to move to Linux which offers a much more acceptable
updating system. It actually gives you a choice and does it in the
background. Not only that but it never requires you to restart
anything. At worst, it might ask you to log in again.
 
Instead, they stick to Windows which essentially takes over the
computer and renders it unusable while it updates...
SilverSlimer <.m@nsn.s>: Jun 13 09:55AM -0400

>term investment in the OS/X platform which using a fraction of their cash pile
>could be turned into a decent server OS (along with dumping the hideous
>objective-C which should have been strangled at birth).
 
Agreed. If they could get their worst machines at a $750 price point,
I'm sure that they would indeed have a higher market share.
Unfortunately, the company was never all too interested in appearing
to be anything but a high-end brand so I doubt they will ever allow
their machines to cost any less than $1,000 for even the worst
specified computer. The iPad seems to be the only affordable machine
and it's arguable as to whether it can really replace a desktop
machine.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jun 13 10:02AM -0400

On 6/13/2018 8:54 AM, SilverSlimer wrote:
>> VirtualBox a couple months back and it was impressive.
 
> Would you say that it can replace Windows on a day-to-day basis? Why
> not?
 
For some apps probably. For others no. The API is not yet sufficiently
developed or debugged.
 
> versions from like 2003, but nobody paid money for those projects and
> they therefore have no obligation to keep anything current like
> Microsoft might.
 
 
I'm not aware of functionality that has ceased working in Linux. But,
I don't use it too much for development.
 
--
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jun 13 10:05AM -0400

On 6/13/2018 9:01 AM, SilverSlimer wrote:
> adding a layer to aid Windows 3.1 or even 9x compatibility is not
> likely to take more than about 500MB which is trivial on an operating
> system installation today.
 
Windows in 1992 was 16-bit software. You can't run 16-bit software
on 64-bit Windows today. Some 32-bit versions of Windows may run
it. And, there's no reason you can't run 16-bit software on 64-bit
OS versions, by the way. It's not a limitation of the CPU, but only
that Microsoft chose not to support it.
 
There are several software apps written since Windows 95 that will
not work after Vista, or in some cases Windows 7, or in some cases
Windows 8 or 10.
 
Microsoft is removing a lot of legacy functionality that used to
be staples of our development platform, to replace with some newer
thing. They can say they're doing it for security reasons or what-
ever, but it still breaks the functionality.
 
 
> The same way that you're stuck with what Apple gives you to run legacy
> Mac OS Classic apps (all of which no longer function) or apps from
> around 2002.
 
 
I don't know. I do not use any Apple products. From what I've seen
though, since Apple only has to support a finite set of hardware,
their kernel and apps are far more stable and robust than anything
in Windows.
 
I also know many people who run Windows on Apple hardware and love
it.
 
--
Rick C. Hodgin
boltar@cylonHQ.com: Jun 13 02:13PM

On Wed, 13 Jun 2018 09:55:49 -0400
>specified computer. The iPad seems to be the only affordable machine
>and it's arguable as to whether it can really replace a desktop
>machine.
 
Not until they remove the deliberate crippling of the GUI and allow multiple
concurrent windows. That simple model might be fine for a small screen phone
but not for a large screen tablet that might substitute for a desktop. Even
google realised that not all tablets are used simply for media consumption and
allowed split window mode and in android 7 & 8 (if the OEM has enabled it,
samsung has) you can have a proper floating windowing system called freeform
windows.
 
I used to have an iPad - it was an idiots computer. Replaced it with Android
which might not be quite so polished but its far superior in features and
usability.
SilverSlimer <.m@nsn.s>: Jun 13 10:51AM -0400

On Wed, 13 Jun 2018 10:02:05 -0400, "Rick C. Hodgin"
>> not?
 
>For some apps probably. For others no. The API is not yet sufficiently
>developed or debugged.
 
Hopefully, it will get there one day but Microsoft will do everything
they can to put obstacles along the way. I imagine that ReactOS will
never support modern apps but that they will have no trouble running
Win32 ones. If that's the case and Microsoft moves toward a modern
app-only approach, people will likely adopt it in huge numbers.
 
>> Microsoft might.
 
>I'm not aware of functionality that has ceased working in Linux. But,
>I don't use it too much for development.
 
It's not functionality as much as it is apps which served a particular
purpose at some point in time. That purpose might not be served by
newer applications and a user might want to use that archaic piece of
software instead. However, it is unavailable to him in the
repositories and even if a user can get a hold of the source code, it
won't compile in the new versions of Linux because the software
depends on libraries which are no longer compatible. It's a mess for
some people but it's so rare that mentioning it is basically
worthwhile.
SilverSlimer <.m@nsn.s>: Jun 13 10:56AM -0400

On Wed, 13 Jun 2018 10:05:30 -0400, "Rick C. Hodgin"
>it. And, there's no reason you can't run 16-bit software on 64-bit
>OS versions, by the way. It's not a limitation of the CPU, but only
>that Microsoft chose not to support it.
 
I'm sure that Microsoft could have provided some sort of compatibility
layer for that software if they had wanted to regardless of whether
the processor could handle it on its own or not. Apple did such a
thing with Mac OS Classic software when OS X first emerged and there
is definitely a way for them to have done it for old software too. Of
course, there would have been little reason for them to do so
considering how they were, again, trying to sell new versions.
 
>be staples of our development platform, to replace with some newer
>thing. They can say they're doing it for security reasons or what-
>ever, but it still breaks the functionality.
 
I don't entirely dismiss the security argument. Old software was not
written with much security in mind so it is quite possible that
allowing it to run can create some sort of a loophole that would allow
an attacker to take over a system. However, I doubt that was the
official reasoning.
 
>in Windows.
 
>I also know many people who run Windows on Apple hardware and love
>it.
 
I liked Mac OS at first. After two years of using it exclusively, I
grew to truly dislike it. Considering how many of their recent
decisions are very much against everything that I believe in, such as
giving $1 million to the horrible Southern Poverty Law Center, they
will never again get my money for hardware.
cross@spitfire.i.gajendra.net (Dan Cross): Jun 13 12:21AM

>for design or algorithm analysis?
 
>I've been around many TDD proponents and none of them have ever said
>this.
 
See some of the links I posted earlier; I feel that they make
that argument.
 
- Dan C.
Daniel <danielaparker@gmail.com>: Jun 12 07:11PM -0700

On Tuesday, June 5, 2018 at 3:47:23 PM UTC-4, Richard wrote:
> >opinion) poorly suited for.
 
> Can you show me a TDD proponent that *is* saying it is a substitute
> for design or algorithm analysis?
 
There are no doubt many things that TDD proponents haven't said, but what
they have said, in particular, what Robert Martin has said, is that
specifications can be fully expressed by tests, and that the tests can fully
validate the specifications thus expressed. This would fall under the
heading of being a bold claim, and, in my opinion, one that cannot be
substantiated.
 
Daniel
Juha Nieminen <nospam@thanks.invalid>: Jun 13 04:27AM

> TDD people would need some insight into floating point numbers to be
> confident that they had sufficient test coverage, as they could easily pick
> tests that would fortuitously pass.
 
Or, maybe, if they had sufficient understanding and experience about TDD,
having to write proper tests would have guided them to think about the
problems and edge cases that converting a string to a floating point has.
 
As said, the basic idea of TDD is that the behavior of every function should
be accurately specified before it's implemented. Thus it would lead the
programmer to think "hmm, what *should* this function return with this
kind of input?" rather than just go and make some kind of untested
wishy-washy maybe-it-will-work-maybe-it-won't-I-don't-know haphazard
ad-hoc implementation.
 
As a side note, given that there's a perfectly good implementation of
an ascii string representation to a floating point value both in the C
and C++ standards (which is most probably better and more efficient than
anything they could write), why do those people feel the need to
implement their own?
Ian Collins <ian-news@hotmail.com>: Jun 13 09:17PM +1200

On 13/06/18 05:33, Daniel wrote:
> point numbers would ever use the code shown above in the first place. I find
> it interesting that the three github projects (sajson, pjson, gason)
> actually did.
 
Are you saying that those who do not practice TDD don't need some
insight into floating point numbers?
 
> a formal notation, and then implement a simple parser to process the terms
> of that grammar. And you'd get a clear error message for incorrect input
> practically for free.
 
In this case, I would map the grammar to tests.
 
> Generally speaking, TDD over emphasizes the role of tests as a specification
> of a problem, and their simultaneous validation of that specification. >> Whatever heuristic value TDD offers, it's biggest claims can't be
justified.
 
I think you are over simplify the claims. No one claims tests are the
only specification, they are simply one layer of it. I have implemented
both back of an envelope and detailed specification with TDD. An
example of the latter was an implementation of the strtol family of
functions, which ended up with 48 tests starting out with the error
conditions and building up to base conversions.
 
--
Ian.
Daniel <danielaparker@gmail.com>: Jun 13 06:23AM -0700

On Wednesday, June 13, 2018 at 5:17:54 AM UTC-4, Ian Collins wrote:
> > actually did.
 
> Are you saying that those who do not practice TDD don't need some
> insight into floating point numbers?
 
I'm pretty sure that I've never said that, ever :-)
 
 
> I think you are over simplify the claims. No one claims tests are the
> only specification
 
Robert Martin has, or as near as, check out the old discussions in
comp.software.extreme-programming.
 
Best regards,
Daniel
Daniel <danielaparker@gmail.com>: Jun 13 07:24AM -0700

On Wednesday, June 13, 2018 at 12:27:57 AM UTC-4, Juha Nieminen wrote:
 
> As a side note, given that there's a perfectly good implementation of
> an ascii string representation to a floating point value both in the C
> and C++ standards
 
Actually, there currently aren't any good conversion functions between
double and char suitable for XML or JSON processing, although the C++ 17
from_chars and to_chars may fit the bill in the future. I think it's safe to
say that no open source project (or at least any that has users) uses the
C++ streams classes, which faithfully follow the "infinite cost abstraction"
and "you get what you don't need" principles. Most projects use strtod for
string to double and snprintf for double to string, and jump through hoops
to reverse the affect of localization, for example, by substituting the
decimal point in the locale for a '.' when parsing a json fractional value.
And when using the "g" format to output, fixing up the end of string output
so that they don't illegally end with a '.', or unnecessary trailing zeros
(one zero after a '.' is necessary.)
 
> why do those people feel the need to implement their own?
 
Because of benchmarks. Open source tools compete for users, and one factor
is how they compare on benchmarks. Also, open source projects are partly for
the benefit of mankind, and partly as a hobby for their creators, and some
hobbyist/creators like to say they have the fastest parser. It would be nice
if the "zero cost abstraction" wasn't just a funny joke, but there it is.
 
Curiously, one of the most comprehensive and widely referred to JSON
benchmarks is sponsored by RapidJson, which implements double to string
conversion with Grisu2 from Florian Loitsch ACM Sigplan paper, and string to
double conversion following an ACM paper. And the benchmark file is a file
of floating point numbers. sajson, pjson, and gason will beat RapidJson on
speed, but they don't follow any ACM papers :-)
 
Daniel
woodbrian77@gmail.com: Jun 12 06:11PM -0700

On Tuesday, June 12, 2018 at 5:31:59 PM UTC-5, Öö Tiib wrote:
 
> > For once I agree with you :)
 
> Note that the exception propagation scheme like described in that
> document was how these were usually implemented in nineties.
 
Was that in ++C implementations? Was it 1998 ++C standard
that required dynamic exceptions? I guess we will be going
back to the future.
.
Melzzzzz <Melzzzzz@zzzzz.com>: Jun 13 02:18AM

> for wiring up the events (signals) emitted by UI elements with the
> handlers (slots) that process the events. Unless you want to be
> disgusted, don't dig into the Qt implementation too deeply :-).
 
Well, you don't have to use moc and qt's signal/slot
, you can override application event function and take over ;)
I did that back in 2000 with one project.
 
--
press any key to continue or any other to quit...
Ian Collins <ian-news@hotmail.com>: Jun 13 06:09PM +1200


> Was that in ++C implementations? Was it 1998 ++C standard
> that required dynamic exceptions? I guess we will be going
> back to the future.
 
I've never seen a ++C implementation...
 
--
Ian.
guinness.tony@gmail.com: Jun 13 02:11AM -0700

On Tuesday, 12 June 2018 16:09:35 UTC+1, James Kuyper wrote:
> • Minimum of two years' experience as a C++ coder
 
> Desired:
> • Prior experience with M&S software coding.
 
Unless you've previously worked for Marks and Spencer (https://www.marksandspencer.com/), I don't see how you can obtain this.
 
;-)
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Jun 13 02:13AM -0700

On 6/11/2018 1:20 PM, Melzzzzz wrote:
> Rant: my new job at embedded programming ;)
> So I am now C/C++ programmer...
 
I have been there... No STL and no exceptions... However, POD's all day
long! ;^)
Juha Nieminen <nospam@thanks.invalid>: Jun 13 09:47AM

>> So I am now C/C++ programmer...
 
> I have been there... No STL and no exceptions... However, POD's all day
> long! ;^)
 
I have to wonder if a hard rule like "no STL" is throwing the baby away with
the bathwater. After all, what's commonly referred to as "standard template
library" consists of much more than dynamic data containers like std::vector
and std::map.
 
For example, arguably std::sort() is part of the "STL", and if you need to
sort a large amount of elements as fast as possible, it's probably going to
be more efficient than most custom implementations.
 
Of course, I suppose, it depends on how much RAM you have to work with in
your embedded system. If you have 2 kB of RAM available, then that does
severely limit what you can do (and, perhaps, using C++ might not be the
best possible option, unless you have a C++ compiler for it that can
strip away most of the extra stuff and really optimize for size).
 
Most embedded systems that are used nowadays have RAM sizes in the megabytes.
I'd say that in these cases "no STL" is an actual example of premature
optimization. Know your tools, use the most efficient tool of the task
at hand, and only if it turns out that you are really running out of RAM,
then consider replacing that standard tool with something custom.
(For example, std::vector with a one-time reserve() call, which doesn't
get reallocated after that, ought to be just fine in most situations,
even with relatively tight RAM constraints.)
Ian Collins <ian-news@hotmail.com>: Jun 13 10:18PM +1200

On 13/06/18 21:47, Juha Nieminen wrote:
 
> For example, arguably std::sort() is part of the "STL", and if you need to
> sort a large amount of elements as fast as possible, it's probably going to
> be more efficient than most custom implementations.
 
The phase "No STL" is nonsense, especially to those of us who used the
origin STL back in the 90s. If someone were to tell me I couldn't use
"the STL" I would just go ahead and use std::array, std::unordered_map
and all the containers and algorithms that weren't in the original STL.
 
:)
 
--
Ian.
boltar@cylonHQ.com: Jun 13 11:05AM

On Wed, 13 Jun 2018 22:18:47 +1200
>origin STL back in the 90s. If someone were to tell me I couldn't use
>"the STL" I would just go ahead and use std::array, std::unordered_map
>and all the containers and algorithms that weren't in the original STL.
 
A lot of times the STL and std::string is the only reasom people use C++ over
C. I've seen plenty of C++ code with not a user defined class in sight. Take
out the STL and string and it would be plain C.
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)