Tuesday, December 16, 2014

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

itoneymathew@gmail.com: Dec 16 01:34PM -0800

I can't get rice to display larger than 65,536. See:
 
vector <int> squares;
 
int main()
{
signed long long int rice = 1;
for (int i = 0; i < 15; ++i)
{
squares.push_back(rice);
cout << squares[i] << endl;
if (rice == 1)
rice = 2;
else
rice = rice * rice;
}
}
Mark Blair <mblair@quantumdata.com>: Dec 16 03:39PM -0600

> I can't get rice to display larger than 65,536. See:
 
> vector <int> squares;
 
Should be:
vector <long long int> squares;
 
mathewji <itoneymathew@gmail.com>: Dec 16 01:57PM -0800

Made the change. I can't get rice to display larger than 4,294,967,296. See:
 
vector <signed long long int> squares;
 
int main()
{
signed long long int rice = 1;
for (int i = 0; i < 15; ++i)
{
squares.push_back(rice);
cout << squares[i] << endl;
if (rice == 1)
rice = 2;
else
rice = rice * rice;
}
}
Victor Bazarov <v.bazarov@comcast.invalid>: Dec 16 05:06PM -0500

On 12/16/2014 4:57 PM, mathewji wrote:
> rice = rice * rice;
> }
> }
 
Which means that your implementation cannot store the square of that
number in a 'long long'. Are you surprised? Why? It requires more
than 64 bits, which is what your 'long long' has, probably.
 
Use Google to search for "arbitrary precision integer" and use some
library, there are probably open source ones out there.
 
V
--
I do not respond to top-posted replies, please don't ask
Barry Schwarz <schwarzb@dqel.com>: Dec 16 02:39PM -0800

On Tue, 16 Dec 2014 13:34:13 -0800 (PST), itoneymathew@gmail.com
wrote:
 
> rice = rice * rice;
> }
>}
 
Changing squares to vector<long long> will postpone the error but not
solve the problem. To see why, take a piece of paper and write down
the value of rice for the first few values of i. (Hint: make life
easy on yourself and write the values as powers of 2.) How soon will
rice exceed the value of LLONG_MAX?
 
--
Remove del for email
Ian Collins <ian-news@hotmail.com>: Dec 17 10:41AM +1300

Scott Lurndal wrote:
 
> The type-safety argument is overblown. Particularly since the compilers have
> had the capability to warn about mismatched format arguments for almost
> two decades.
 
For built in types, yes but once you start to use user defined types all
of that is lost. Even printing something as mundane as std::complex
becomes a mess.
 
My one opinion isn't as polarised as many, if I want to generate a fixed
format string from numeric data, I'll probably use snprintf. If I'm
writing templated code, iostreams are the only choice. If I'm writing
code than outputs user defined types, I'll use iostreams.
 
> instead of snprintf; and I find snprintf much easier to read and
> especially to write than the redefinition of the bit shift operator
> into some sort of magic I/O operator.
 
That's hard to believe.
 
--
Ian Collins
Christopher Pisz <nospam@notanaddress.com>: Dec 16 04:20PM -0600

On 12/16/2014 12:31 PM, Scott Lurndal wrote:
>> C++ programmers and don't outright lie.
 
> I'm sorry, I don't understand your comment. I've been programming,
> for pay in C++ since 1989.
 
Having a title and a paycheck doesn't make one a C++ programmer, it only
makes them employed as one.
 
Kind of like my going and getting my ass kicked in the UFC. I could get
in the ring, but I am not martial arts champion.
 
No offense to you personally, but I haven't seen your code, only your
posts, and my opinion is that you use C style programming thusfar.
 
 
>> Far more readable? Far more usable? Are you kidding me?
 
> Yes, far more readable. Consider:
 
> lp->log("%-132.132s\n", start);
 
Ugly and cryptic.
 
 
> bytecount = snprintf(tbp, tbsize, " [%6.6llx:%6.6llu]",
> gethex(p_operands[1]->getaddress(), 6),
> getdigits(p_operands[1]->getaddress()+6, 6));
 
Ugly, complex, and cryptic. How many operations are occurring there? How
many times do I need to hit F10 in my debugger for this one silly line?
You think that's readable?!!! Fantasy world and beyond help.
 
You C programmers love your Lucky Charms encoder rings. I blame printf
and sprintf.
 
 
 
> picture clauses are much more similar to *printf than cout).
 
> I find your insistence on the "purity" of C++ to be completely
> silly.
 
I'd rather be silly than unmaintainable and error prone.
 
> less readable and more verbose output streams particularly
> given the performance constraints on most of the C++ software
> that I'm responsible for.
 
Any bug tracking software will provide you with all the reasons you will
ever need.
 
In my case, it has shown 80% of all bugs over my career have been traced
back to C style programming from programmers with the same mentality you
so blindly cling on to.
Christopher Pisz <nospam@notanaddress.com>: Dec 16 04:25PM -0600

On 12/16/2014 3:25 PM, Scott Lurndal wrote:
> instead of snprintf; and I find snprintf much easier to read and
> especially to write than the redefinition of the bit shift operator
> into some sort of magic I/O operator.
 
Maybe you are actually working in a C shop and no one told you. You only
noticed something peculiar when you hired someone whom was born after
1960, but most likely canned them for not following your ancient traditions.
Luca Risolia <luca.risolia@linux-projects.org>: Dec 16 11:29PM +0100

Il 16/12/2014 22:28, Scott Lurndal ha scritto:
 
>> Furthermore there is no way for a classic C printf implementation to be
>> faster than the C++ counterpart using variadic templates. Guess why.
 
> Please enlighten us. How is:
 
I was commenting about the supposed efficiency of the standard printf. I
don't see it. It's inherently inefficient because C-style variadic
argument types have to be resolved at runtime with explicit casts in
va_arg. An efficient version of printf for C++ would be based on
variadic templates where types are known at compile time.
agent@drrob1.com: Dec 15 09:17PM -0500

On Mon, 15 Dec 2014 19:51:49 -0600, Robert Wessel
>in either case, in C++, a type named struct_name will be created (and
>in the second example typedef_name will be created as well).
 
>In C++ you would usually avoid the explicit typedef.
 
 
That helps.
 
I am interested in learning c++ first, and then maybe or maybe not, c.
 
Thanks guys.
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)