Tuesday, November 15, 2016

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

Tim Rentsch <txr@alumni.caltech.edu>: Nov 15 08:56AM -0800


>> [1] https://en.wikipedia.org/wiki/ISO_31-11#Sets
 
> You have a full five gallon pail of water. You empty it. How
> many more gallons do you have in the pail now?
 
If I had a nicely full five gallon pail I would hope that what
it's full of would be something more interesting than just water.
Tim Rentsch <txr@alumni.caltech.edu>: Nov 15 09:23AM -0800


> Therefore 'unsigned' of C++ is not natural number but unnatural
> number and one has to write a wrapper around it to reach something
> resembling a natural number.
 
First off my comment was mostly just a play on words, as the
smiley face indicates.
 
Second, when working with whole numbers (natural numbers plus
zero), it is customary to employ 'proper subtraction', which is
defined only when the number being subtracted is no larger than
the number from which it is being subtracted (or alternatively
is defined to be zero in such cases).
 
Third, the comment about having to write a wrapper applies just
as much to signed integer types, if not moreso. The set of
natural numbers is infinitely large, which is not even close to
being true for either signed integer types or unsigned integer
types.
 
But probably most important is that operations on unsigned types
always at least produce some number, which IMO makes them more
natural than the undefined behavior that happens with signed
types.
Tim Rentsch <txr@alumni.caltech.edu>: Nov 15 09:52AM -0800


>> [1] https://en.wikipedia.org/wiki/ISO_31-11#Sets
 
> I see your smiley, but comparison with natural numbers is not
> actually appropriate.
 
Sure it is, that's what makes it funny.
 
> else than natural. Ditto the other way: how is it natural in any
> way that incrementing an unsigned integer will yield zero at some
> point?
 
Modular arithmetic is a well-established field of mathematics.
 
> nonsense has brought in to alleviate the inherent defect in the
> design of unsigned integers - discontinuity at zero. If there
> were no unsigned numbers, such a hack would not be needed.
 
My experience is the opposite of that. Those who routinely use
unsigned types for certain kinds of quantities and use cases are
IME more likely to think carefully about the programming they do
and not engage in sloppy programming. Conversely, those who
espouse a "signed types almost everywhere" approach tend not to
worry about whether overflow might occur, at least not on a
comparative basis. That seems rather an odd attitude to take,
considering the potential downsides in the two cases, but it
apparently occurs fairly often nonetheless.
 
Just to be clear, I don't mean to advocate that anyone change
their preferences regarding signed versus unsigned types. But I
think a blanket statement that signed types are nearly always a
better choice than unsigned types is a significant overstatement.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Nov 15 08:45PM +0100

On 15.11.2016 18:52, Tim Rentsch wrote:
> I
> think a blanket statement that signed types are nearly always a
> better choice than unsigned types is a significant overstatement.
 
Unsigned types are good for bit-level stuff. In particular you don't
want to do left-shifts with signed integers.
 
Signed integers are good for numbers, numerical values, when they're not
mixed with signed integers. In particular you don't want implicit
promotion of signed quantities to unsigned ones. You don't want
expressions like `string("blah").length() < -1` in your code.
 
Unfortunately, while the standard library at one point seemed to be
heading in the right direction, with signed distances, the C++17 general
size function has unsigned result. It also conflates several notions of
size. This lack of standard library support -- not even in any in Boost,
as far as I know -- makes it difficult for individual programmers to
transition to non-risky types for each usage area.
 
 
Cheers!,
 
- Alf
"Öö Tiib" <ootiib@hot.ee>: Nov 15 02:52PM -0800

On Tuesday, 15 November 2016 19:23:28 UTC+2, Tim Rentsch wrote:
> > resembling a natural number.
 
> First off my comment was mostly just a play on words, as the
> smiley face indicates.
 
Ok.
 
> defined only when the number being subtracted is no larger than
> the number from which it is being subtracted (or alternatively
> is defined to be zero in such cases).
 
I don't think we have such universal truths. Zero is natural number
by ISO 31-11. Also there are choices to say that 42 can not be
subtracted from 24 or to say that result of subtracting 42 from 24
is -18. Those choices feel more common than to say that subtracting
42 from 24 is 0.
 
> natural numbers is infinitely large, which is not even close to
> being true for either signed integer types or unsigned integer
> types.
 
I suspect that we do not need larger integer numbers than for
example billion more often than we need to find out distance
between two numbers ... but don't have such statistics.
 
> always at least produce some number, which IMO makes them more
> natural than the undefined behavior that happens with signed
> types.
 
That "undefined behavior" is likely a result of sabotage. Actual
hardware platforms that support signed arithmetic behave on case
of signed integer overflow in definable manner and even the
differences between behavior of different platforms could be
indicated with a value of pre-defined macro or the like.
"Christopher J. Pisz" <cpisz@austin.rr.com>: Nov 15 02:05PM -0600

I've been taking some screening tests for interviews lately. I haven't
gotten any bites. I am starting to wonder if my code is yucky. Haven't
had problems getting jobs for the last 10 years.
 
Would anyone mind taking a look at one of these tests and the answers I
gave? I've already been passed on, and I took the name of the company
off. I asked for feedback, but they didn't bother giving me any :(
 
I uploaded Visual Studio projects and a text file with the questions here.
 
https://github.com/ChristopherPisz/Test-1
 
They seemed to be pretty damn standard questions. I can't imagine I got
them wrong.
 
Any feedback?
"Christopher J. Pisz" <cpisz@austin.rr.com>: Nov 15 02:11PM -0600

On 11/15/2016 2:05 PM, Christopher J. Pisz wrote:
 
> They seemed to be pretty damn standard questions. I can't imagine I got
> them wrong.
 
> Any feedback?
 
P.S
They supplied all function stubs. I wouldn't never make functions with
names and arguments like that. :P
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Nov 15 09:57PM +0100

On 15.11.2016 21:11, Christopher J. Pisz wrote:
 
> P.S
> They supplied all function stubs. I wouldn't never make functions with
> names and arguments like that. :P
 
:)
 
I'm looking at the first exercise, the linked list thingy.
 
I think one is supposed to use only linked list operations, not
`std::set`, otherwise the linked list itself doesn't make sense.
 
The straightforward implementation of the `optimal` function (which is
sort of like `std::unique`), simply searching the whole list for each
node encountered, is then O(n²), but I think that's what one is supposed
to submit. Since the initialization of the list in your code is O(n²),
it doesn't totally make sense to have better behavior in the `optimal`
function.
 
Better behavior can be achieved with only linked list operations, at the
cost of great complexity, by sorting a list whose nodes refer to the
original (merge sort is O(n log n)) and removing duplicates in that
sorted list, but. I think anyone submitting that would fail. Because a
company doesn't want employee to use looooong time on premature
optimization, unless it's contract work for Donald Trump.
 
Finally, I think maybe you're supposed to delete the nodes at the end.
 
 
Cheers & hth.,
 
- Alf (experienced in failing evaluations by not-very-competent people).
"Christopher J. Pisz" <cpisz@austin.rr.com>: Nov 15 04:26PM -0600

On 11/15/2016 2:57 PM, Alf P. Steinbach wrote:
 
> Cheers & hth.,
 
> - Alf (experienced in failing evaluations by not-very-competent people).
 
Fair enough. Should one suppose, when asked questions about data
structures, that they should not use the STL data structures or
algorithms therein?
 
I did it brute force for my first try, just iterating through the list
every insertion looking for the value to be inserted. Then I thought to
myself, we could has everything that has been inserted thus far and it
would be quicker then going through the entire list.
 
I don't know how to implement my own hash, so I just used std::set, not
really thinking about "I am implementing a data structure with another
data structure"...
 
I've always hated these kind of fake exercises where one should ignore
the STL and Boost. I always think to myself, "Why am I implementing a
linked list when one already exists that has been used by millions of
people for decades?" I understand they want to inquire as to whether the
interviewee understands complexity and how the data structures work though.
pack112@gmail.com: Nov 15 02:44PM -0800

On Tuesday, November 15, 2016 at 2:05:20 PM UTC-6, Christopher J. Pisz wrote:
 
> They seemed to be pretty damn standard questions. I can't imagine I got
> them wrong.
 
> Any feedback?
 
I only took an extremely quick look. You use assignment instead of initializers in the LinkedListNode constructor. I'd take a pass on any applicant who did that - but maybe that's just me.
 
--
Mark
ruben safir <ruben@mrbrklyn.com>: Nov 15 02:46PM -0500

Does anyone know of any sample code for reading PNG files that doesn't
include using libpng.... just straight direct access.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Nov 15 08:46PM +0100

On 15.11.2016 20:46, ruben safir wrote:
> Does anyone know of any sample code for reading PNG files that doesn't
> include using libpng.... just straight direct access.
 
Find the specification, code it up?
 
 
Cheers!,
 
- Alf
scott@slp53.sl.home (Scott Lurndal): Nov 15 07:58PM

>Does anyone know of any sample code for reading PNG files that doesn't
>include using libpng.... just straight direct access.
 
libpng, being open source, would seem to be the best starting point
for someone who wishes to code the same functionality.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Nov 15 12:06PM -0800

On Tuesday, November 15, 2016 at 2:46:31 PM UTC-5, ruben safir wrote:
> Does anyone know of any sample code for reading PNG files that doesn't
> include using libpng.... just straight direct access.
 
On Windows and with a C++ compiler, you can use the built-in
Gdiplus::Bitmap object and load the png and then write it out
as a standard .bmp format, which is much easier to access
line-by-line.
 
See:
 
Bitmap class:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms534420(v=vs.85).aspx
 
Basically, load the image, convert it to a HBITMAP which you then
BitBlt onto another HBITMAP you've created using CreateDIBSection().
In that one you obtain a pointer to the bits and can write them out
in any format you desire:
 
https://msdn.microsoft.com/en-us/library/windows/desktop/ms536295(v=vs.85).aspx
 
Some steps in this operation:
 
Make sure structures are packed to 1-byte (and not the default 8-
or 16-bytes).
Use GdiplusStartup() to engage the Gdiplus engine.
Use the image->GetWidth() and image->GetHeight() to determine size.
Use image->LockBits() to obtain a BitmapData object.
Use image->GetHorizontalResolution() * 39.700787f to get pixels
per meter for the output bmp setting. And GetVerticalResolution().
Use image->unlockBits() when finished.
Use GdiplusShutdown() to disengage the Gdiplus engine.
 
Best regards,
Rick C. Hodgin
Christian Gollwitzer <auriocus@gmx.de>: Nov 15 09:31PM +0100

Am 15.11.16 um 20:46 schrieb ruben safir:
> Does anyone know of any sample code for reading PNG files that doesn't
> include using libpng.... just straight direct access.
 
Sean Barret has very impressive (compact) C code to write PNG files in
stb_image_write.h:
 
https://github.com/nothings/stb
 
I have not checked if this does reading of PNGs, too; however he has a
ite here on github which lists similar libraries, and this refers to
 
http://lodev.org/lodepng/
 
Christian
Popping mad <rainbow@colition.gov>: Nov 15 08:50PM

On Tue, 15 Nov 2016 21:31:16 +0100, Christian Gollwitzer wrote:
 
> https://github.com/nothings/stb
 
too complex. I'm just looking for PNG access
Popping mad <rainbow@colition.gov>: Nov 15 08:50PM

On Tue, 15 Nov 2016 12:06:12 -0800, Rick C. Hodgin wrote:
 
> On Windows
 
/dev/null
Popping mad <rainbow@colition.gov>: Nov 15 08:53PM

On Tue, 15 Nov 2016 19:58:33 +0000, Scott Lurndal wrote:
 
> libpng, being open source, would seem to be the best starting point for
> someone who wishes to code the same functionality.
 
maybe, but its complex and I think it is broken. At some point they
decided to fix a long standing bug that has rended most of my early png
files useless. And the programs design to fix them don't work, so I want
to excavate the problem myself. I'm not looking to create a huge
library, just to look at the files at this point under the hood,
perferably in a single file program
Tim Rentsch <txr@alumni.caltech.edu>: Nov 15 08:51AM -0800

>> geometry, there is no royal road to making good design choices.
 
> There's "A Royal Road to Algebraic Geometry" by Holme, Audun.
> http://www.springer.com/us/book/9783642192241
 
An amusing title, presumably deliberately so. But thank you for
the reference.
 
> Perhaps the royal road is doing the right thing given the context.
 
I think the whole point of the "no royal road" comment is that
there is no surefire way to know what the right thing is in
any given context.
woodbrian77@gmail.com: Nov 15 10:55AM -0800

On Tuesday, November 15, 2016 at 10:51:51 AM UTC-6, Tim Rentsch wrote:
 
> I think the whole point of the "no royal road" comment is that
> there is no surefire way to know what the right thing is in
> any given context.
 
If you give up, you are not on the royal road.
 
Brian
Ebenezer Enterprises - If you can't join 'em, beat 'em.
http://webEbenezer.net
ram@zedat.fu-berlin.de (Stefan Ram): Nov 15 11:53AM

>takes a std::string (obtained from getline) and returns a
>std::vector<std::string> that contains the white-space-separated
>tokens.
 
And I would recommend not to hardcode ::std::cin and
::std::cout, but use an istream/ostream as a parameter.
This helps writing tests that take the input from a
string.
admin@isocpp.org: Nov 14 04:20PM -0800

On Monday, November 14, 2016 at 6:53:15 AM UTC-8, Philipp Klaus Krause wrote:
> C++, such as what was introduced by C++11, C++14 and C++17 and changes
> in what is considered good C++?
 
> Philipp
 
Philipp,
 
Unfortunately, technical book publishing isn't what it used to be. As Brian has suggested, there is a wealth of videos now, but although they there is a lot of valuable information in them, video isn't really a reference friendly medium and the free videos are not necessarily well integrated.
 
I would recommend Scott's book Effective Modern C++ ( https://www.amazon.com/Effective-Modern-Specific-Ways-Improve/dp/1491903996/ ) as valuable after you have had some experience with Modern (11 & later) C++. I don't know of any book that is focused specifically on teaching Modern C++ to someone that is comfortable with Classic C++.
 
I would recommend C++ Primer (5th Edition) ( https://www.amazon.com/Primer-5th-Stanley-B-Lippman/dp/0321714113/ ) for your consideration. It doesn't assume that you already know Classic C++, so you might find some of it redundant to you, but it will has been updated for C++11 and will acquaint you with new features.
 
Some notes:
 
* You want the C++ Primer (5th Edition) not an earlier edition and not C++ Primer Plus. Look for Barbara Moo's name.
 
* The differenced between C++17 and C++14 and between C++14 and C++11 are minor compared to the differences between C++11 and Classic C++ (C++03). There are important differences, but those differences deserve an article, not a book.
 
Good luck.
Philipp Klaus Krause <pkk@spth.de>: Nov 15 10:38AM +0100

Thanks already for the information so far. English language technical
books tend to be a bit expensive in the West, so recommendations for
good French or German books are welcome, too.
 
Philipp
seeplus <gizmomaker@bigpond.com>: Nov 15 03:23AM -0800

On Tuesday, November 15, 2016 at 8:38:26 PM UTC+11, Philipp Klaus Krause wrote:
> English language technical
> books tend to be a bit expensive in the West
 
There are many publishers such as Pakt, Informit, O'Reilly Media,
Manning, where you can download the most uptodate Ebooks
(some of them you read while they are being written) as PDFs or other E formats,
available for every possible technology, and they usually include reviews,
forums for the book, source code and instant errata.
When the book is updated, you get that for free.
 
You just pay the local price, often with 50% discounts offered (Black Friday etc).
You get it instantly, and being foreign, with no sales tax (that could change).
You are getting them cheaper than the locals!
 
Setup a nice tablet ( >= 10 inch ) and load them on, and persevere with the
non paper format which can take some getting used to.
This is not quite so convenient for references as reaching for a paper book,
however on a PDF you can just click on a topic or in the index, and be taken
straight to the text.
 
You can stick 100's of books on one uSD card and read them on the bus,
or back them all up to a bigger computer/screen where your IDE lives,
and also have a copy offsite for safety.
You cannot do these things with a paper book library ....
"K. Frank" <kfrank29.c@gmail.com>: Nov 14 07:48PM -0800

Hi Bob!
 
On Sunday, November 13, 2016 at 2:04:27 PM UTC-5, Bob Langelaan wrote:
> ...
> This is the first assignment for this class and their first use of the string class and therefore I would be surprised if they are required to use istringstream as part of their solution. And another possibility is to use a function like getchar() to read in each character, one by one, and manufacture the int and string values character by character.
 
> My question is there a better/easier way? This "better/easier way" would, I assume, need to be aware when a '\n' is encountered in the input stream.
 
Well, if this is the first assignment, it's a bit hard to
know what tools the students are expected / allowed to use.
But part of the point of c++ is to use the standard tools,
rather than write all of the low-level stuff from scratch.
 
So one suggestion that doesn't use too much machinery, is
pretty straightforward, and doesn't involve unnecessary
low-level coding runs as follows:
 
Use getline. This is perfectly appropriate because the input
format is explicitly line oriented.
 
Split the line into white-space-separated tokens. Count
the tokens. In your case, n != 4 is an error.
 
Parse / validate the tokens. In your case, tokens 3 and
4 are arbitrary (non-white-space-containing) strings, so
they are automatically valid. Tokens 1 and 2 are (decimal?)
integers, so parse them as such, and flag an error if they
are not.
 
I find it convenient to write a little helper function that
takes a std::string (obtained from getline) and returns a
std::vector<std::string> that contains the white-space-separated
tokens.
 
If tokens 1 and 2 are supposed to parse into a value that
fits into an unsigned int or unsigned long, you could use,
e.g., std::stoul. If they are supposed to parse into an
arbitrary length integer, then it's probably simplest to
write your own validation function that checks that each
character in the token is a (decimal) digit.
 
(I have used schemes like this frequently when writing
smallish programs that need to parse line-oriented input.)
 
> Thanks in advance :)
 
 
Happy Hacking!
 
 
K. Frank
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)