Friday, March 20, 2015

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

"محمد رجب" <md.rg8910@gmail.com>: Mar 20 05:48AM -0700

float income;
cout << "Enter your monthly income: ";
cin >> income;
if (income < 0.0)
cout << "You are going farther into debt every month." << endl;
else if (income >= 0.0 && income < 1200.00)
cout << "You are living below the poverty line." << endl;
else if (income >= 1200.00 && income < 2500.00)
cout << "You are living in moderate comfort." << endl;
else if (income >= 2500.00)
cout << "You are well off." << endl;
Victor Bazarov <v.bazarov@comcast.invalid>: Mar 20 10:00AM -0400

On 3/20/2015 8:48 AM, محمد رجب wrote:
> cout << "You are living in moderate comfort." << endl;
> else if (income >= 2500.00)
> cout << "You are well off." << endl;
 
This used to be covered in FAQ 5.2... I can't locate it in its old
place anymore, sorry. After redoing the C++ FAQ, the section on how to
post is empty. Well, too bad. I found the mirror, though. Check it
out (and keep the link for your convenience):
http://www-igm.univ-mlv.fr/~dr/CPP/c++-faq/index.html
 
V
--
I do not respond to top-posted replies, please don't ask
red floyd <no.spam@its.invalid>: Mar 20 10:37AM -0700

On 3/20/2015 7:00 AM, Victor Bazarov wrote:
> post is empty. Well, too bad. I found the mirror, though. Check it
> out (and keep the link for your convenience):
> http://www-igm.univ-mlv.fr/~dr/CPP/c++-faq/index.html
 
Victor, the FAQ is still at Parashift.
 
http://www.parashift.com/c++-faq-lite/
Victor Bazarov <v.bazarov@comcast.invalid>: Mar 20 01:53PM -0400

On 3/20/2015 1:37 PM, red floyd wrote:
>> http://www-igm.univ-mlv.fr/~dr/CPP/c++-faq/index.html
 
> Victor, the FAQ is still at Parashift.
 
> http://www.parashift.com/c++-faq-lite/
 
Yes. Please find 5.2 in it and explain how you did it here. Thanks!
 
V
--
I do not respond to top-posted replies, please don't ask
red floyd <no.spam@its.invalid>: Mar 20 02:58PM -0700

On 3/20/2015 10:53 AM, Victor Bazarov wrote:
 
>> Victor, the FAQ is still at Parashift.
 
>> http://www.parashift.com/c++-faq-lite/
 
> Yes. Please find 5.2 in it and explain how you did it here. Thanks!
 
You're right, it's insanely difficult to find. I have no idea why
Marshall did the rearrangement.
 
However, it is here: http://isocpp.org/wiki/faq/how-to-learn-cpp
 
At the bottom of the page.
 
For some reason, it's under the "Learning OO/C++" link. I really think
Marshall should put the netiquette page back.
Victor Bazarov <v.bazarov@comcast.invalid>: Mar 20 07:30PM -0400

On 3/20/2015 5:58 PM, red floyd wrote:
> Marshall did the rearrangement.
 
> However, it is here: http://isocpp.org/wiki/faq/how-to-learn-cpp
 
> At the bottom of the page.
 
Thanks!
 
> For some reason, it's under the "Learning OO/C++" link. I really think
> Marshall should put the netiquette page back.
 
.. or at least make it possible to search for.
 
V
--
I do not respond to top-posted replies, please don't ask
scott@slp53.sl.home (Scott Lurndal): Mar 20 01:25PM

>> function as well.
 
>It would still be quicksort (the C standard mandates this), not one of
>the newer fangled sort thingies that C++ is allowed to support.
 
generally, if I need significant amounts of data
sorted from C, I'll pipe it to the sort(1) utility.
 
Of course, this only works on an operating system that
includes hundreds of useful utilities out of the box.
"Öö Tiib" <ootiib@hot.ee>: Mar 20 07:03AM -0700

On Thursday, 19 March 2015 17:44:52 UTC+2, BGB wrote:
 
> and, qualify further:
> standard library operation which hardly anyone uses in favor of just
> writing their own.
 
This may be true on case of ´qsort´ but ´std::sort´ does fairly
decent job most of the time and so you are typically content with
it and portably so.
 
Same goes about almost everything in standard library. Lets take
randomly ... ´rand´. If you want the random generator to produce
same sequence portably then you can`t use ´rand´. You achieve it
with by "just writing your own" or using stuff from <random>.
 
Some like writing (or more precisely copy-pasting) same algorithms
again and again. It is hardly everybody. Most developers I know of find
copy-paste annoying. Especially when a sly defect is discovered
long later. Lot better is to have templates.

About subtle defects that "long later" may mean decades:
" ... in the history in Section 6.2.1 of his Sorting and Searching,
Knuth points out that while the first binary search was published in
1946, the first published binary search without bugs did not appear
until 1962." Jon Bentley, Programming Pearls (1st edition), pp.35,,36
History has shown same about merge-sorts.
 
Who likes templates these can anyway roll their own and sometimes do but
often find the implementations in C++ standard library to be decent. Also
if they need few more then other open source libraries (or library
collections like boost) have some things that have been well thought out.
On general case the profiler shows that only maybe 5% of C++ code of
application may need some tinkering later and rest of it is either close
to optimal or ran too rarely to care about. There again C++ shines,
because the "tinkering" often means changing few typedefs and rerunning
the tests.
BGB <cr88192@hotmail.com>: Mar 20 10:54AM -0500

On 3/20/2015 9:03 AM, Öö Tiib wrote:
 
> This may be true on case of ´qsort´ but ´std::sort´ does fairly
> decent job most of the time and so you are typically content with
> it and portably so.
 
was talking about qsort and C.
 
there is no std::sort in C.
 
 
> randomly ... ´rand´. If you want the random generator to produce
> same sequence portably then you can`t use ´rand´. You achieve it
> with by "just writing your own" or using stuff from <random>.
 
rand is more often used, as at least it can conveniently produce
more-or-less random numbers if nothing is needed beyond this. well,
nevermind if specialized RNGs are generally needed if any specific types
of behavior are needed.
 
 
> again and again. It is hardly everybody. Most developers I know of find
> copy-paste annoying. Especially when a sly defect is discovered
> long later. Lot better is to have templates.
 
copy-paste is pretty common practice in C land though, as libraries are
pretty hit or miss sometimes (for example if the code needs to be
portable between targets, and copy-pasting relevant code fragments is
often less problematic than trying to drag around full libraries).
 
this sort of portability tends to be a lot less common in
application-software though, as more commonly people use lots of
libraries and write programs which typically only work on a single OS.
 
 
typically, a focus on "generic" code is pretty much a non-goal, as it
tends to be less productive/efficient/readable/... than doing one-off
use-case-specific versions of the code in question.
 
now, if C had templates, who knows?... but, it doesn't, so the lesser of
the evils tends to be the preferable answer.
 
 
the usual alternate scenario is basically the projects' codebase turning
into a fortress-like mountain of code, which limits the need for
copy-paste internally mostly by creating a mostly homogenous internal
environment, and porting is mostly limited to areas which interface with
the external OS or similar.
"Öö Tiib" <ootiib@hot.ee>: Mar 20 01:29PM -0700

On Friday, 20 March 2015 17:57:19 UTC+2, BGB wrote:
> > it and portably so.
 
> was talking about qsort and C.
 
> there is no std::sort in C.
 
Yes, but the discussion was about C and C++ standard libraries.
I know you write your own compilers and so don´t use C++ (it is
terribly lot of work to write a C++ compiler) but for majority of
people there just are the two compilers available side by side.
 
> more-or-less random numbers if nothing is needed beyond this. well,
> nevermind if specialized RNGs are generally needed if any specific types
> of behavior are needed.
 
I rarely need "more-or-less random numbers". I typically use RNG to
generate some test input data. For example to simulate a module that
people from some other continent will perhaps produce later. The
distribution of such data is next to never linear. It is somehow biased
and <random> is helpful there). If something bad does happen
with generated input then I need the seeds to find if it is reproducible
(<random> is helpful again). Often I want portable algorithms so to at
least try if it happens on other platforms with different debugging
tools (<random> is helpful again). I started to use it 2003 I think
(it was "Boost.Random Number" back then) and never looked back at ´rand´.
 
> pretty hit or miss sometimes (for example if the code needs to be
> portable between targets, and copy-pasting relevant code fragments is
> often less problematic than trying to drag around full libraries).
 
I know it and such manual tinkering with the fragments is annoying.
That is why I tend to use C++ if only possible. You get only what you use,
whatever large the library is.
 
> this sort of portability tends to be a lot less common in
> application-software though, as more commonly people use lots of
> libraries and write programs which typically only work on a single OS.
 
Yes and if the point of application is to clue together calls
to heavyweight libraries, that then do majority of work then we may just
use Python (or the like) instead of C and the result is about as
efficient. C++ adds dimension to it if the libraries are generic
header-only. Compiler optimizes heavily such integrations and does
what only it can compile and link time. It compiles slowly but result
is hard to beat.
 
> typically, a focus on "generic" code is pretty much a non-goal, as it
> tends to be less productive/efficient/readable/... than doing one-off
> use-case-specific versions of the code in question.
 
My focus is to write generic code when my tools report that I (or others
whom I work with) have already copy-pasted its parts to 4 different applications. Not before but not much later. If it was reused then it
is reusable de facto and so it is worth to smoothen that. Otherwise I
have been criticized for writing too exactly the minimal code what is
sufficient for particular application.
 
> copy-paste internally mostly by creating a mostly homogenous internal
> environment, and porting is mostly limited to areas which interface with
> the external OS or similar.
 
It feels that (at least part) of the goal is to write it in C. No matter
what evils have to be picked. ;) I don't say that C++ is not evil. However
I have tamed the beast before it became C++98 and it wasn´t too hard. Now
with clang and C++14 it is quite easy to domesticate and it takes lot less
time of explaining its benefits to novice coworkers too.
BGB <cr88192@hotmail.com>: Mar 20 06:25PM -0500

On 3/20/2015 3:29 PM, Öö Tiib wrote:
> I know you write your own compilers and so don´t use C++ (it is
> terribly lot of work to write a C++ compiler) but for majority of
> people there just are the two compilers available side by side.
 
ok, figured by context it was apparent that this was about C, rather
than about C++.
 
in my case, it has often been more layered, where some areas were
designated C only, and others were "C or C++", though C++ sections have
tended to be less common than C ones.
 
 
> least try if it happens on other platforms with different debugging
> tools (<random> is helpful again). I started to use it 2003 I think
> (it was "Boost.Random Number" back then) and never looked back at ´rand´.
 
I have usually used specialized RNGs for cases where it has mattered.
 
 
 
> I know it and such manual tinkering with the fragments is annoying.
> That is why I tend to use C++ if only possible. You get only what you use,
> whatever large the library is.
 
a few times, regularly copy-pasted fragments have been coalesced into
libraries.
 
in otherwise, single-source-file implementations have been done of
things many people would use libraries for.
 
 
more often code is copy-pasted, when it is necessary to build something
different but using common (or at least similar) pieces, or when the
code is somewhere completely different (such as in a different codebase).
 
 
> header-only. Compiler optimizes heavily such integrations and does
> what only it can compile and link time. It compiles slowly but result
> is hard to beat.
 
possibly.
 
I have generally not built much end-user application software (besides
my 3D engine, which had a lot of other stuff stuck onto it, and was
basically a big fortress-style codebase).
 
 
a lot more is either low-level / back-end code, or specialized tools.
for example, for some of my robotics stuff, built a few tools to
generate specific pieces of geometry, or to perform basic manipulations
on other geometry, ... (mostly for making parts to be 3D printed).
 
for example, went and made a tool that is able to operate via a simple
batch-like command-language, making primitives, performing manipulations
and various operations, and spitting out the results as STL files or
similar, which can be pretty useful.
 
this tool has been used mostly for making procedural mechanical parts,
such as gears and wheels and similar. mostly it operates on BREP solids
and using CSG operations and similar.
 
then, some other parts, such as gearbox housings, have been made in
Autodesk 123D. made some propellers in 123D, but I feel this is where it
starts showing some limitations (something like NURBS support or similar
would have been really helpful).
 
there is sort of a 3D modeller stuck into my 3D engine (essentially a
quad-view subdivision+vertex modeler), which I could (possibly) go and
make into a standalone thing and update for the use-cases I am currently
dealing with (such as adding STL support), or possibly integrate with my
command-oriented tools, but haven't done so (and 123D "basically works"
for generic graphical 3D modeling ATM...).
 
 
a few other cases, it was stuff that is used as Windows or Linux driver
modules or similar, though I haven't gone too far into this.
 
one example was writing specialized A/V codec drivers on Windows, as
some of my stuff uses custom codecs (and it is easier to write codec
drivers than write custom media-processing applications).
 
 
and, as also noted, some amount of code for embedded hardware, mostly
running on controllers in the robots and similar.
 
 
> is reusable de facto and so it is worth to smoothen that. Otherwise I
> have been criticized for writing too exactly the minimal code what is
> sufficient for particular application.
 
minimal code works...
 
 
minimal standalone code is better than unchecked 3rd party dependencies
I think, which is the main thing I get annoyed with.
 
like, see some half-way interesting program, consider trying to get it
built on Windows, realize it is pretty much entirely thin wrapper code
over GNOME libraries and would need to be almost entirely rewritten to
make it standalone or get it built on Windows (short of going and trying
to get all of the GNOME libs built and working on Windows), don't bother...
 
 
 
> I have tamed the beast before it became C++98 and it wasn´t too hard. Now
> with clang and C++14 it is quite easy to domesticate and it takes lot less
> time of explaining its benefits to novice coworkers too.
 
dunno...
 
 
I ended up with a fortress like codebase while trying to have a system
of modular libraries.
 
it turned, ultimately, far more into complicated a monolith than I would
have hoped for (but had been essentially a single codebase which I had
been worked on continuously for around 15 years, taking on many
different superficial forms in this time).
 
but, more recently I have been working on stuff outside the original
confines of this codebase, in a way making its ultimate future a bit
uncertain.
 
 
though, yes, in many cases, it is possible to grab individual libraries
and use them without needing to bring the whole rest with it, and a few
libraries which ended up originally built on other things, had gradually
been moving in the direction of being self-contained and independent.
 
ironically, one way in which making parts independent had been done, was
by partially cloning the COM+ system, where interfaces may be imported
and exported, and libraries would be plugged together by implementing
interfaces representing pieces of functionality which they needed to
import from other subsystems. this had allowed partially inverting the
dependence hierarchy.
 
 
most often this was used for things like memory-management and VFS /
File-IO, where my codebases have tended to use things like custom
memory-managers and VFS systems and similar, and you could either plug
in an interface during initialization (and have the library use this),
or leave it undefined (where typically the library would fall back to
malloc and stdio and similar).
 
 
though, yes, this could basically also be done with abstract base
classes in C++, but an emulation of the COM+ system keeps things more open.
 
I had at one point also considered going and cloning MIDL, so that I
could also use IDL files without being nominally stuck with MS tools
while doing so, but hadn't gotten around to it.
 
I had also considered possibly moving to using such a reverse-engineered
COM+ as a major interface between my VMs and C land, but hadn't gotten
to it (in the scripting language, these would have been expressed using
syntax like "public native interface IFoo { ... }").
 
however, the scripting language had primarily done its existing C FFI
via mechanisms with syntax like "native import C.libname;" (for
importing libraries from C) and "public native package C.foo { ... }"
(for exporting interfaces to C, mostly via generated headers and
function stubs), but this had a lot more interdependence than a COM+
style interface would have had (where each side could remain
more-or-less agnostic that the interface was crossing language borders).
 
ironically, my C VM has a less transparent interface as-is, as there is
no real transparent way to call from native code into the VM, but in the
current use-case (real-time), you don't really want to do something like
this (generally, C->VM calls are asynchronous, but C has no concept of
asynchronous function calls).
 
a few cases, I have also done something a bit questionable, and made use
of GUIDs and SIXTEENCC values having mutually-exclusive bit-patterns
(there are no cases where one could be valid as the other, *), to have
cases where either a GUID or a SIXTEENCC is used as an identifier (with
the conventions for using SIXTEENCC values basically being similar to
those for using FOURCC values).
 
*: actually, there are a lot of smaller, but still gigantic, spaces left
over within the 128-bit space.
 
 
but, for smaller codebases, it is often easier to grab parts of code
which are relevant to the specific tool or application in question, and
simpler/easier to not bother with trying to generalize anything.
 
after the new thing is made, usually the old and new versions have
little more to do with each other, and will typically develop in their
own directions independently.
Christopher Pisz <nospam@notanaddress.com>: Mar 13 06:30PM -0500

On 3/13/2015 6:15 PM, Melzzzzz wrote:
> http://tech.co/highest-paying-programming-languages-2015-03
 
Well, I need a raise I think :P
 
 
 
--
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---
Melzzzzz <mel@zzzzz.com>: Mar 14 12:15AM +0100

http://tech.co/highest-paying-programming-languages-2015-03
drew@furrfu.invalid (Drew Lawson): Mar 20 06:36PM

In article <mecre2$dqr$1@dont-email.me>
 
>> Chris
 
>Are there no newsgroups catering to left wing nut jobs, centrist nut
>jobs, or sane radicals?
 
No, all nut jobs are right wing.
The left wing has cranks.
 
The centrists are too busy debating which is rarer,
them or unicorns.
 
--
Drew Lawson | We were taking a vote when
| the ground came up and hit us.
| -- Cylon warrior
"Lőrinczy Zsigmond" <zsiga@nospam.for.me>: Mar 13 12:59PM +0100


> Hi, I am having a difficult time figuring out how I'm going to design my
> base and derived classes for a specific project.
 
Actually, it's not about classes and inheritance,
it's about data-organizations.
Maybe you could start here:
 
https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model
"Öö Tiib" <ootiib@hot.ee>: Mar 20 08:25AM -0700

On Thursday, 19 March 2015 22:34:13 UTC+2, Christopher Pisz wrote:
 
> I've never had the pleasure of seeing anyone roll their own custom
> classes that A) worked bug free and B) were more efficient than the STL,
> while fulfilling the exact same requirements.
 
C++ efficiency skill does not come from capability of copy-pasting thousands
of lines of bloat. Skill is to know what is out there, already written
and ready to use, and how good it is and for what. Just download boost.
It contains classes that are relatively bug free and are more efficient
than STL *in* *situations*. Fulfilling exact same requirements is pointless
because you need the operations that you use most often to be fast, and
do not care if the operations that you use rarely or never meet the
performance requirements.
 
I have seen orders of magnitude gains of efficiency of function from
simply replacing usage of containers. For example ´std::set´ with
´boost::flat_set´ or (not so simply) with ´boost::intrusive::set´.
In situations the difference can be like between 5 seconds and 8 minutes.
However you need someone who has experience with efficiency because
these things aren`t just more efficient as "silver bullets" but only
more efficient *in* *situations*.
 
> do better individually, then a committee of top C++ programmers and have
> the confident that comes with the number of people using the STL for the
> length of time it has been around.
 
Very true. I have even seen memory leak in STL that Microsoft SOLD to me.
It fixed it with service pack few months later. With gcc it is fairly
*common* to have some subtle defects. Verdict: Even the "top programmers"
just can´t write things without defects.
 
Therefore what average Joe writes is typically naive to no repair.
Someone familiar with efficiency isn´t exactly average Joe. Only about
10% of C++ developers can use profiler and do understand what they see
with it. Less than 5% can read source code of STL or boost fluently.
So the problem of Joe is that his best option is to use the header-only
code that he can´t neither read nor measure. He is afraid and so he
writes his silly classes. FUD, but he can´t say it is his FUD and so he
will say "efficiency", because only 10% are capable of measuring it.
So solution to your problems is like Jorgen said, to have someone around
who has experience with efficiency ... and that in style of C++.
jacob navia <jacob@jacob.remcomp.fr>: Mar 20 08:27AM +0100

> talks about.
 
> "But a natural man does not accept the things of the Spirit of G-d,
> for they are foolishness to him;
 
 
Exactly. Religion is for fools.
 
> and he cannot understand them,
 
No. I refuse god, the angels, the demons and all that nonsense!
 
 
> And yes, it was a band(company) of believers who paved the way
> for modern civilization.
 
No. Mankind STARTED to make progress when we threw AWAY religion at the
renaissance. Science and mathematics paved the way of the scientific
revolution that has brought us (among thousands of other things)
computers, and C++, C, and software in general.
 
:-)
 
It wasn't Jesus, computers weren't in the Bible.
ram@zedat.fu-berlin.de (Stefan Ram): Mar 12 09:40AM

>absolutely *have* to know the implications of what you're doing in
>detail or you can introduce a vast array of problems by a single line or
>reference (like std::string).
 
When a programmer is writing code for microcontrollers in C++,
he - of course - first has to learn C++ and then microcontroller
programming in C++. He should have come across texts such as (quote):
 
»Most of the standard and third-party C++ libraries don't
adhere to these limitatins, so they are not useable.«
 
I am by no means an expert in this topic, but my own
(German-language) C++ tutorial has a small lesson on
embedded programming containing this advice:
 
· avoid exceptions (code size)
· possibly avoid dynamic memory
· possibly avoid virtual classes and templates
· possibly avoid iostreams
· possibly avoid RTTI, dynamic_cast and the container library
· possibly avoid temporary objects
(additions or modifications to this list are welcome)
 
I also have a remark that templates might increase or
sometimes decrease code size. An example for the last would
be a template instantiation where the compiler only puts
those parts of a class into the object file that are really
used while without template instantiation the whole class
might get included IIRC.
ram@zedat.fu-berlin.de (Stefan Ram): Mar 12 09:18AM

>And for resource constrained systems, templates are the aboulte worst
 
Templates fit small-memory systems well when the
programmer is knowing what he is doing.
Christopher Pisz <nospam@notanaddress.com>: Mar 13 05:37PM -0500

On 3/13/2015 5:05 PM, astro.del.cielo wrote:
 
> I don't know this
 
> --
> a.d.c.
 
Tis true.
 
 
--
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---
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)