Sunday, January 3, 2016

Digest for comp.lang.c++@googlegroups.com - 15 updates in 5 topics

JiiPee <no@notvalid.com>: Jan 03 02:13AM

On 02/01/2016 21:56, Bo Persson wrote:
>> and so on ...
 
> I have heard that some of those guys now also regret making size_type
> an unsigned type.
 
yes thats what they say also in that video
JiiPee <no@notvalid.com>: Jan 03 02:16AM

On 02/01/2016 22:34, Jorgen Grahn wrote:
> and C) cannot be changed, and Stroustrup strikes me as the kind of
> guy who gives advice for the /real/ world ...
 
> /Jorgen
 
I actually agree with Bjarne here..... what if you put -2 to unsigned
int? you might not get what you expect. They both can contain very big
numbers, so even that is not a reason.
 
unsigned int would work only if there would be a compile time error
ALWAYS when you try to put a negative number to it. but i guess its not
possible. also we have this constant problem converting uint to int
later in the code.
Paavo Helde <myfirstname@osa.pri.ee>: Jan 03 01:39AM -0600


> unsigned int would work only if there would be a compile time error
> ALWAYS when you try to put a negative number to it. but i guess its
> not possible.
 
There is a widely used idiom for initializing an unsigned integer with all
bits set. This is also extremely simple and extremely portable as the
conversion rules are explicitly stated in the C and C++ standards:
 
unsigned int x = -1;
 
std::uint64_t y = -1;
 
Cheers
Paavo
JiiPee <no@notvalid.com>: Jan 03 04:33PM

On 03/01/2016 07:39, Paavo Helde wrote:
> bits set. This is also extremely simple and extremely portable as the
> conversion rules are explicitly stated in the C and C++ standards:
 
> unsigned int x = -1;
 
you mean
 
unsigned int x = -1;
 
int y = x;
 
would guaranteed to set y to -1?
Paavo Helde <myfirstname@osa.pri.ee>: Jan 03 01:22PM -0600


> unsigned int x = -1;
 
> int y = x;
 
> would guaranteed to set y to -1?
 
No, I mean it is guaranteed that all bits of an unsigned integer are set
to 1 when -1 is assigned to it. Assigning this value back to an int is
implementation-defined (because the value cannot be represented in int).
You might get -1 back in some implementations, but this is not
guaranteed.
 
Cheers
Paavo
Vir Campestris <vir.campestris@invalid.invalid>: Jan 03 07:53PM

On 03/01/2016 07:39, Paavo Helde wrote:
> conversion rules are explicitly stated in the C and C++ standards:
 
> unsigned int x = -1;
 
> std::uint64_t y = -1;
 
I've heard rumours of machines that don't use 2s complement arithmetic
(although I've never met one). Shouldn't we use ~0?
 
Andy
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 03 09:08PM +0100

On 1/3/2016 8:53 PM, Vir Campestris wrote:
 
>> std::uint64_t y = -1;
 
> I've heard rumours of machines that don't use 2s complement arithmetic
> (although I've never met one). Shouldn't we use ~0?
 
Only when the 0 is of the right size.
 
E.g.,
 
unsigned x = ~0u; // OK
 
but
 
uint64_t x2 = ~0u; // Probably not OK (e.g., not OK in Windows).
 
 
Cheers & hth.,
 
- Alf
Paavo Helde <myfirstname@osa.pri.ee>: Jan 03 03:27PM -0600

Vir Campestris <vir.campestris@invalid.invalid> wrote in
 
>> std::uint64_t y = -1;
 
> I've heard rumours of machines that don't use 2s complement arithmetic
> (although I've never met one). Shouldn't we use ~0?
 
Conversion from -1 is well-defined on all machines:
 
4.7 Integral conversions [conv.integral]
[...]
2 If the destination type is unsigned, the resulting value is the least
unsigned integer congruent to the source integer (modulo 2n where n is
the number of bits used to represent the unsigned type). [ Note: In a
two's complement representation, this conversion is conceptual and there
is no change in the bit pattern (if there is no truncation). —end note ]
 
The tilde operator however is more tricky:
 
5.3.1./10: The operand of ˜ shall have integral or unscoped enumeration
type; the result is the one's complement of its operand. Integral
promotions are performed. The type of the result is the type of the
promoted operand.
 
In ~0, 0 is of type int, so the promoted type is int as well, and we get
one's complement of a signed int, that would be some implementation-
defined value as the representation of signed integers is implementation-
specific IIRC.
 
~0u would work better, but would still fail with larger unsigned types. I
still think using -1 is the simplest and most robust way.
 
Cheers
Paavo
Ramine <ramine@1.1>: Jan 03 03:58PM -0800

Hello...........
 
I have come to very important subject...
 
And rationality and logic have to dictate to me
my way of thinking and answering this important question
about Free Software Fondation, this is my wisdom and
this is wisdom, so what is the very important principal
of Free Software Fondation, it's that it is a social act
that has as a principal objective to reduce social darwinism,
and as i said this is a honnorable principal and act of
Free Software Fondation, but this honnorable principal and act
must be constrained to not be transformed in an act of social darwinism,
because how can we make a living easily if it's Free
like in Free Sofware Fondation, so we have to build with wisdom
and be careful to not constain with this act of Free Sofware Fondation
to avoid the disavantages that we can get from it, and
those disavantages are to be able to balance between Free
and not Free to make it more easy for devellopers of Freewares
and Free Softwares to survive easily... this is a principal
fondation of wisdom that is in accordance with rationality and
logic, because this is an act of beauty that higher the chance
of surviving and higher the chance of success, this beauty is
also the base fondation for the principal of Liberalism that
allow us to penetrate the economic markets of others so that to
become more rich, so that to become more capable, and as i said
that wisdom dictate that we have to allow the rich to be rich
because when you are more rich you are more capable
and this is good for science and technology and this
is a light for humanity, but we have to constrain
the rich by impose it and taxing it with a certain
percentage to redistribute more this wealth as
social acts so that to make the life more beautiful because
this is a requirement to make the economic system more optimal,
because when the life is more beautiful that means that
the people are more confident and happy so they will consume
and buy more goods...
 
 
 
Thank you,
Amine Moulay Ramdane.
 
.
bleachbot <bleachbot@httrack.com>: Jan 03 09:57PM +0100

Paavo Helde <myfirstname@osa.pri.ee>: Jan 03 03:58AM -0600

Jorgen Grahn <grahn+nntp@snipabacken.se> wrote in
>> often mean creating a too low-level abstraction.
 
> To me there's no such thing. If I identify "the length of a molecule"
> as a type, I can make a C++ type out of it, and benefit from it.
 
I think the key words here are "If I identify...". Indeed, if creating a
separate type has benefits, then of course that's way to go. And OTOH, if
it wouldn't bring any benefits then it would be over-engineering. I have
seen plenty of the latter as well.
 
Of course, the border between good design and over-engineering is not so
clear in real life and depends on all kind of things, including the
actual usage of the software piece. A well-designed piece of software may
appear over-engineered when used in another context. One of the worst
examples of this I have seen is a library which wraps a SQL database in
an heavy OOP design so that each table and table row basically becomes an
OOP object. All good and fine, but in our product the business logic was
not formulated in this object-oriented interface, but in the next layer
of software sitting on top of that library. The next layer does not have
such expressiveness and basically operates in terms of simple tables
(similar to SQL). To make this work, the absolute minimal set of needed
operations was identified and wrapped up so they could be used by the
next layer. Each wrapped operation involves figuring out the needed OOP
types, instantiating them correctly, translating the content of tables to
calls to objects - and I am pretty sure somewhere deep inside the library
all this information finally gets translated into some simple SQL
statements again. So basically the main effort when using this library
(inside this product) goes to translating the table-based interface into
OOP interface with lots of types and classes nobody cares about, just so
the library can translate it back into table-based SQL again. The
compiled size of this library is 455 MB, by the way.
 
Cheers
Paavo
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 03 05:11PM

On Sun, 2016-01-03, Paavo Helde wrote:
> clear in real life and depends on all kind of things, including the
> actual usage of the software piece. A well-designed piece of software may
> appear over-engineered when used in another context.
 
I agree.
 
> OOP interface with lots of types and classes nobody cares about, just so
> the library can translate it back into table-based SQL again. The
> compiled size of this library is 455 MB, by the way.
 
(Good grief; the most absurd library size I've seen is 80 MB,
stripped.)
 
That fits nicely with my other personal rule of C++ programming: "I'm
too stupid to write libraries, and so is pretty much everyone else"
:-)
 
I'd be very careful if I had to write a library, not trying to force
my prejudices onto others when I cannot know anything about their
needs. It seems these guys were not that careful ...
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Paavo Helde <myfirstname@osa.pri.ee>: Jan 03 01:15PM -0600

Jorgen Grahn <grahn+nntp@snipabacken.se> wrote in
>> compiled size of this library is 455 MB, by the way.
 
> (Good grief; the most absurd library size I've seen is 80 MB,
> stripped.)
 
This 455 MB is a Windows x64 static library, release build. Fortunately the
product only uses a small subset of the full library, so the final size of
the plugin DLL linked to this static library and implementing the needed
minimal interface is "only" 33 MB.
 
Cheers
Paavo
woodbrian77@gmail.com: Jan 02 05:59PM -0800

http://stackoverflow.com/questions/34521354/tcp-ip-server-in-c-is-not-waiting-for-client/34539331#34539331
 
That thread says socket descriptors returned by accept()
can be negative. The documentation on FreeBSD and Linux
says accept() returns a non-negative number if successful.
Are there some systems where accept() can return negative
socket descriptors? Tia
 
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 03 08:47AM


> http://stackoverflow.com/questions/34521354/tcp-ip-server-in-c-is-not-waiting-for-client/34539331#34539331
 
> That thread says socket descriptors returned by accept()
> can be negative.
 
Yes it does say that:
 
"Your error tests are invalid. It isn't correct to test for <
-1. A socket FD for example can have any value except -1. You
should test the result of every system call for == -1. 2. As
you're using Winsock, errno and friends don't work. Use
WSAGetLastError()"
 
> The documentation on FreeBSD and Linux says accept() returns a
> non-negative number if successful.
 
In Unix sockets are file descriptors, and those start at 0.
 
> Are there some systems where accept() can return negative socket
> descriptors?
 
Apparently Windows, according to that guy on stackoverflow. But why
they would create such a gratituous incompatibility with Unix, I don't
know -- not much point in implementing what looks a lot like the BSD
Sockets interface, and fail there. (Disclaimer: I have never done any
Windows programming.)
 
To get back to C++, Boost.Asio seems like a good way to write portable
code using TCP if you cannot assume POSIX.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
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)