Wednesday, November 19, 2014

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

comp.lang.c++@googlegroups.com Google Groups
Unsure why you received this message? You previously subscribed to digests from this group, but we haven't been sending them for a while. We fixed that, but if you don't want to get these messages, send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Robert Hutchings <rm.hutchings@gmail.com>: Nov 19 02:28PM -0600

Just curious if anyone has used VirtualBox on Ubuntu Linux with a
Windows 8.1 guest? Did that work OK?
red floyd <no.spam@its.invalid>: Nov 19 01:24PM -0800

On 11/19/2014 12:28 PM, Robert Hutchings wrote:
> Just curious if anyone has used VirtualBox on Ubuntu Linux with a
> Windows 8.1 guest? Did that work OK?
 
Your question can be answered by FAQ 5.9
 
http://www.parashift.com/c++-faq-lite/which-newsgroup.html
Melzzzzz <mel@zzzzz.com>: Nov 19 10:26PM +0100

On Wed, 19 Nov 2014 14:28:49 -0600
 
> Just curious if anyone has used VirtualBox on Ubuntu Linux with a
> Windows 8.1 guest? Did that work OK?
 
Works.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Nov 19 08:15PM

On Tue, 2014-11-18, Richard wrote:
 
>> What would be the point of automating it?
 
> Automated refactorings can be applied over a large code base quickly
> and are (usually) less error prone.
 
I suspect we have wildly different philosophies.
 
I'm conservative.
 
I've spent a lot of time in maintenance, so I value the history: going
back through the version control tool and seing all changes, one by
one, and the rationales for them. And I really like it when code only
changes when it /has/ to change. (That doesn't mean I don't do
refactoring, or don't want to use C++11.)
 
I also see source code as a message from one human to another, and
distrust anything written by a machine, intended for reading by a
human. You need a tone, and good taste, to write code.
 
Lastly, I see refactoring as a way to become more familiar with the
code. I can find things out, or make improvements that a program
cannot make, while doing the refacotoring.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
legalize+jeeves@mail.xmission.com (Richard): Nov 19 09:14PM

[Please do not mail me a copy of your followup]
 
Jorgen Grahn <grahn+nntp@snipabacken.se> spake the secret code
 
>> Automated refactorings can be applied over a large code base quickly
>> and are (usually) less error prone.
 
>I suspect we have wildly different philosophies.
 
Not really.
 
>I've spent a lot of time in maintenance, so I value the history: going
>back through the version control tool and seing all changes, one by
>one, and the rationales for them.
 
Automated refactoring tools are othogonal to having good history. I
don't see this as being any sort of problem for refactoring, whether
it is applied by a tool or by hand.
 
>And I really like it when code only
>changes when it /has/ to change.
 
That raises an interesting point of when to apply this sort of stuff.
If you have a library or code base to which you aren't doing any
active development (i.e. few, if any new features added) and you are
still supporting it, then I wouldn't say to apply clang-modernize to
it, but I would suggest evaluating the switch to a new compiler. The
longer you stay on older compilers, the more difficult it is to switch
when you are forced to switch.
 
If you have a project that is still under active development, then I
see no reason to lag behind on C++11 features that make your code
easier to understand and therefore easier to modify and maintain.
 
>I also see source code as a message from one human to another, and
>distrust anything written by a machine, intended for reading by a
>human. You need a tone, and good taste, to write code.
 
In the context of clang-modernize I don't see the problem here either.
The whole point of many of the C++11 features was to make code easier
to read and easier to understand.
 
>Lastly, I see refactoring as a way to become more familiar with the
>code. I can find things out, or make improvements that a program
>cannot make, while doing the refacotoring.
 
Nothing in clang-modernize is prohibiting this either.
 
Your objections have been stated very abstractly, while the benefits of
a tool like clang-modernize -- and so far this is the ONLY tool that has
come up in this thread -- are very specific and focused. If you want
to continue saying that you think clang-modernize would be a bad idea
to apply to your code, then I suggest that you clarify your specific
objections to the specific transformations that clang-modernize can
apply to a source file.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
legalize+jeeves@mail.xmission.com (Richard): Nov 18 11:29PM

[Please do not mail me a copy of your followup]
 
Alain Ketterlin <alain@dpt-info.u-strasbg.fr> spake the secret code
>(the grammatical conjunction), from "or" (the logical connective), from
>"|" (the bitwise-or operator), and from what you call the "or-operation"
>(I don't know what this is)--all of these being named or.
 
The standard uses "bitwise OR" for | and "logical OR" for ||.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Louis Krupp <lkrupp@nospam.pssw.com.invalid>: Nov 18 10:50PM -0700

>against using it? Why C++ people normally still prefer ||, I don't see
>people using "or" ? Is there a reason for it? I like to use all the
>improvements as they come with C++ ...
 
I personally would rather not use it. Perl has both "||" and "or"
operators. They do similar things, but they have different
precedence, and I usually have a reason to use one or the other.
 
Louis
Juha Nieminen <nospam@thanks.invalid>: Nov 19 08:35AM

> use many different versions of compilers (for various reasons) and
> for that reason alone cannot (and will not) use 'or' in place of the
> conditional-OR operator.
 
You do realize that 'or' isn't a "new" feature? It's C++98.
 
If you can't use C++98 because you don't have a "newer compiler",
then perhaps you shouldn't be coding in C++ in the first place.
We don't live in the 90's anymore.
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
David Brown <david.brown@hesbynett.no>: Nov 19 09:38AM +0100

On 18/11/14 21:08, Martin Shobe wrote:
> who speaks French might find using the word for gold rather odd. Symbols
> don't usually carry such baggage.
 
> Martin Shobe
 
"or" in English also normally "exclusive or" (as in, "would you like an
apple /or/ a banana?"), while "or" in programming usually means
"inclusive or", allowing for both to be "true". So from this viewpoint,
using "or" rather than || here does not actually make the code more
readable.
JiiPee <no@notvalid.com>: Nov 19 09:14AM

On 19/11/2014 08:38, David Brown wrote:
> "inclusive or", allowing for both to be "true". So from this viewpoint,
> using "or" rather than || here does not actually make the code more
> readable.
 
But I never thought about programming language being like normal
language but rather like a mathermatical language and in mathematics
'or' means exatcly the same as in programming (inclusive). So for me
this is not a problem.
 
Also, even in normal english "or" is also inclusive sometimes. For example:
"Paul, if the delivery arrives before 2pm or John calls before 2pm
please send me an email at 4pm". Now if both happens surely Paul should
send that email, isn't it?
Reinhardt Behm <rbehm@hushmail.com>: Nov 19 06:32PM +0800

JiiPee wrote:
 
> example: "Paul, if the delivery arrives before 2pm or John calls before
> 2pm please send me an email at 4pm". Now if both happens surely Paul
> should send that email, isn't it?
 
Not if he is a programmer. ;-)
 
--
Reinhardt
Jorgen Grahn <grahn+nntp@snipabacken.se>: Nov 19 09:01PM

On Wed, 2014-11-19, Martin Shobe wrote:
> On 11/18/2014 3:38 PM, Jorgen Grahn wrote:
>> On Tue, 2014-11-18, Martin Shobe wrote:
...
>> uses them ...
 
> I've been using C and C++ during that time period. I just wasn't aware
> of the or token until recently.
 
Ah, then I understand. Yes, it /is/ surprisingly unknown.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Brian Waldrop <bwald32@hotmail.com>: Nov 18 11:32PM

Öö Tiib wrote:
 
 
> This must be is some counter-joke. 1000 happens to not be power of 2 so
> I don't know how to get the remainder of divison by 1000 using some
> outmasking the bits trick.
 
Very easy, just pick out only the significant bits, once you know their
location. Make it 2¹⁰, ten bits, the LSB of that would count msecs 100%
for sure.
Christopher Pisz <nospam@notanaddress.com>: Nov 18 06:21PM -0600

On 11/18/2014 5:00 PM, Öö Tiib wrote:
> 2) How many milliseconds was in it?
> 3) Does not remainder (operator %) let you to separate those seconds from
> milliseconds?
 
True, but would this not be what they were going for, given their
methods? (I sub param for class member m_dateTime for example's sake)
 
 
const unsigned long long getMilliseconds(boost::posix_time::ptime
m_dateTime) const
{
const unsigned long long fractionOfSecond =
m_dateTime.time_of_day().fractional_seconds();
 
switch(m_dateTime.time_of_day().resolution())
{
case boost::date_time::time_resolutions::sec:
return 0;
 
case boost::date_time::time_resolutions::tenth:
return fractionOfSecond * 100;
 
case boost::date_time::time_resolutions::hundredth:
return fractionOfSecond * 10;
 
case boost::date_time::time_resolutions::milli:
return fractionOfSecond;
 
case boost::date_time::time_resolutions::ten_thousandth:
return fractionOfSecond / 10;
 
case boost::date_time::time_resolutions::micro:
return fractionOfSecond / 1000;
 
case boost::date_time::time_resolutions::nano:
return fractionOfSecond / 1000000;
 
default:
throw std::exception("Unknown fractional second resolution");
}
}
"Öö Tiib" <ootiib@hot.ee>: Nov 18 10:36PM -0800

On Wednesday, 19 November 2014 01:32:33 UTC+2, Brian Waldrop wrote:
 
> Very easy, just pick out only the significant bits, once you know their
> location. Make it 2¹⁰, ten bits, the LSB of that would count msecs 100%
> for sure.
 
What "significant bits"? Can you show us algorithm?
 
For example value of 'total' is 6789 (1101010000101 in binary), ten last
bits are 1010000101 (645 in decimal) but 6789%1000 is 789 (1100010101
in binary).
 
I can't see what algorithm is faster than 'total%1000'.
"Öö Tiib" <ootiib@hot.ee>: Nov 18 10:50PM -0800

On Wednesday, 19 November 2014 02:22:09 UTC+2, Christopher Pisz wrote:
> throw std::exception("Unknown fractional second resolution");
> }
> }
 
OK, but I don't see what is the point? How it is better than ... for
example ...
 
return m_dateTime.time_of_day().fractional_seconds()*
(1000/m_dateTime.time_of_day().ticks_per_second());
Martijn Lievaart <m@rtij.nl.invlalid>: Nov 19 09:22AM +0100

On Tue, 18 Nov 2014 16:47:50 -0600, Christopher Pisz wrote:
 
> and from popular string formats I like its style and error handling
> (exceptions)
> I don't like C style :)
 
And:
 
Boost is way more portable.
 
M4
Christopher Pisz <nospam@notanaddress.com>: Nov 19 02:56PM -0600

On 11/19/2014 12:50 AM, Öö Tiib wrote:
> example ...
 
> return m_dateTime.time_of_day().fractional_seconds()*
> (1000/m_dateTime.time_of_day().ticks_per_second());
 
The latter returns 0 in my unit tests while the former gives the correct
answer. I don't follow why you are using ticks_per_second. Also keep in
mind the types and truncation.
jghickman@gmail.com: Nov 19 08:40AM -0800

Consider:
 
namespace Outer {
typedef int Int32;
typedef char Char8;
}
using namespace Outer;
 
namespace Library {
namespace Inner {
typedef int Int32;
typedef char Char8;
}
using namespace Inner;

Int32 f() { // Outer::Int32 or Library::Inner::Int32?
Int32 x = 0;
return x;
}
}
 
An ambiguity would result if Inner::Int32 were defined at global scope, but
all the compilers I've used resolve the reference to Int32 in Library::f()
to Library::Inner::Int32. Intuition suggests that Library::Inner::Int32 is
favored over Outer::Int32 because it's declared in the Library's own namespace
(albeit a nested one). Is that reasoning in fact confirmed/required by
the standard? If so, is it also true (in this particular case) that the using
directive issued inside the Library is equivalent to a series of using
declarations, one for each name contained inside the Inner namespace (e.g.,
using Inner::Int32; using Inner::Char8; etc.)?
seeplus <gizmomaker@bigpond.com>: Nov 18 07:16PM -0800

On Wednesday, November 19, 2014 2:37:38 AM UTC+11, Louis Krupp wrote:
> by the way), and I clicked on "Print & Ebook" under "Buying Options"
> on the top right.
 
> Louis
 
Be careful if you are not in the US.
OReilly usually only provide just one option of 2 day international delivery @ $49.50, not exactly what you want if you already have the PDF.
 
This makes it cheaper to buy somewhere with a discount and buy the Ebook separately :(
Robert Hutchings <rm.hutchings@gmail.com>: Nov 19 07:59AM -0600

On 11/18/2014 9:16 PM, seeplus wrote:
 
> Be careful if you are not in the US.
> OReilly usually only provide just one option of 2 day international delivery @ $49.50, not exactly what you want if you already have the PDF.
 
> This makes it cheaper to buy somewhere with a discount and buy the Ebook separately :(
 
Well, I contacted O'Reilly to see if I could get the book in addition to
my PDF download. Waiting for an answer now...
Nobody <nobody@nowhere.invalid>: Nov 19 09:52AM

On Sun, 16 Nov 2014 14:34:18 -0800, Öö Tiib wrote:
 
 
> You can't. There can be 'istream' whose size is not constant. For example
> it can be some fifo or pipe that other application is writing into from
> other side.
 
It could even be a regular file which some other application is writing
into.
 
In that case, it will have a defined size at any moment in time, but that
doesn't mean that you'll be able to read it all before the size changes.
Nobody <nobody@nowhere.invalid>: Nov 19 09:48AM

On Fri, 14 Nov 2014 19:33:29 +0000, Scott Lurndal wrote:
 
> Most modern systems are 64-bit, and unsigned long is 64-bit.
 
On "64-bit" versions of Windows, long is still only 32 bits.
DSF <notavalid@address.here>: Nov 18 08:22PM -0500

On Fri, 07 Nov 2014 16:09:28 -0600, Paavo Helde
>instantiation, these are actually totally different classes which have no
>relation to each other, so why should some static data member of them to
>be located at the same address?
 
I have some other points, but what you just typed brought up an
interesting question. Is a static (non-const) member of a template
class:
A. Common to all implementations?
 
B. Common to implementations where "T" is the same type?
 
C. Exclusive to each implementation?
 
As far as const static members, from a language standpoint, it should
follow whichever of the above is correct. From a purely technical
standpoint since it has the lifespan of the process and cannot be
changed, it can exist in only one place. (This could be important if
the const static data are large and limited memory is available, as in
some imbedded systems.)
 
>variable or not.
 
>Cheers
>Paavo
 
DSF
"'Later' is the beginning of what's not to be."
D.S. Fiscus
DSF <notavalid@address.here>: Nov 18 08:45PM -0500

On Sun, 09 Nov 2014 01:10:12 -0600, Paavo Helde
>should some other code pieces happen to take it.
 
>Cheers
>Paavo
 
If I were replacing #defines, I'd only use const, as static (in this
case) implies memory allotted somewhere. (At least to me. I
understand that static const could be converted to an immediate value
as well as plain const.)
 
In the interest of efficiency, I would not want to use a compiler
that did both. With immediate values, you've incurred no overhead and
 
const int maxplayers = 12;
 
is on a par with
 
#define maxplayers = 12;
 
as far as memory usage goes. If the first statement also reserves
memory, then, on a modern system, you are using at least four bytes
for each equivalent of #define. That's why I would prefer that
 
const int maxplayers = 12;
 
would allot no memory, and
 
static const int maxplayers = 12;
 
would allot memory and place 12 there.
 
(Not that I have any say-so whatsoever. It just seems the logical
way to distinguish the two; for the programmer to make clear what
he/she wants.)
 
Wishing you relatively unfrustrating coding,
DSF
"'Later' is the beginning of what's not to be."
D.S. Fiscus
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)