Friday, March 25, 2016

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

"Merve Tektaş" <mervetektas1995@gmail.com>: Mar 25 11:33AM -0700

1. Design an algorithm to print integers divisible by 3, from 1 to N. N should be input by the user.
a. Write pseudo code of your solution first.
b. Write the c code for your solution.
Victor Bazarov <v.bazarov@comcast.invalid>: Mar 25 02:35PM -0400

On 3/25/2016 2:33 PM, Merve Tektaş wrote:
> 1. Design an algorithm to print integers divisible by 3, from 1 to N. N should be input by the user.
> a. Write pseudo code of your solution first.
> b. Write the c code for your solution.
 
Oh, "c code"? Wrong newsgroup. Down the corridor, to your left, try
'comp.lang.c'. They don't do homework either, though...
 
V
--
I do not respond to top-posted replies, please don't ask
Ben Bacarisse <ben.usenet@bsb.me.uk>: Mar 25 07:18PM

>> b. Write the c code for your solution.
 
> Oh, "c code"? Wrong newsgroup. Down the corridor, to your left, try
> 'comp.lang.c'. They don't do homework either, though...
 
... in fact it turns out they do! The OP got a solution with only a few
rough edges in about 21 minutes. (They posted to comp.lang.c first, I
think.)
 
--
Ben.
red floyd <no.spam@its.invalid>: Mar 25 04:25PM -0700

On 3/25/2016 11:33 AM, Merve Tektaş wrote:
> 1. Design an algorithm to print integers divisible by 3, from 1 to N. N should be input by the user.
> a. Write pseudo code of your solution first.
> b. Write the c code for your solution.
 
Do your own homework.
"Merve Tektaş" <mervetektas1995@gmail.com>: Mar 25 11:30AM -0700

1. Design an algorithm to print integers divisible by 3, from 1 to N. N should be input by the user.
a. Write pseudo code of your solution first.
b. Write the c code for your solution.
Robbie Hatley <see.my.sig@for.my.address>: Mar 24 07:05PM -0700

On 3/24/2016 4:08 PM, Ian Collins wrote:
 
> This is one case where fixed-size arrays *are* the best fit!
 
Perhaps. But, it's not very C++ish. "That's nice C code you
have there." Ultimately I suppose it's a style thing, since both
approaches (std::string + std::ostringstream, versus
char array[SIZE] + strftime) appear to work quite fine.
For the purpose of these two functions, I'm more comfortable
programming with the std:: strings & streams. But I'll admit
as how the "char array + strftime" approach is likely more
efficient because it's closer to the machine.
 
 
--
Cheers,
Robbie Hatley
Midway City, CA, USA
perl -le 'print "\154o\156e\167o\154f\100w\145ll\56c\157m"'
http://www.well.com/user/lonewolf/
https://www.facebook.com/robbie.hatley
Ian Collins <ian-news@hotmail.com>: Mar 25 03:09PM +1300

On 03/25/16 15:05, Robbie Hatley wrote:
> programming with the std:: strings & streams. But I'll admit
> as how the "char array + strftime" approach is likely more
> efficient because it's closer to the machine.
 
It also save 90% of the typing!
 
--
Ian Collins
Robbie Hatley <see.my.sig@for.my.address>: Mar 24 09:49PM -0700

On 3/24/2016 11:02 AM, Stefan Ram wrote:
 
> This is independent of what »g++« allows, since this is
> »comp.lang.c++«, not »comp.lang.g++«.
 
You know, that does bring up a good point, in a way: different C++
compilers may handle this bug in different ways.
 
However, just about any C or C++ compiler I'm likely to be able to
get my hands on is going to be *some* variant or port of gcc / g++.
 
But let's try a minimal test program on 2 different compilers:
 
#include <iostream>
#include <string>
using std::cout;
using std::endl;
int main (void)
{
cout << "anaphylaxis" << endl;
std::string s = 0; // This pointer points NOWHERE.
cout << "brachiocephalic" << endl;
return 0;
}
 
 
Results on g++ v 5.0, Cygwin64 port, Windows10, Intel 64bit CPU:
[Compiles without error or warning.]
%string-init-to-0-test
anaphylaxis
[program crashes at that point and silently returns to Bash.]
 
 
Results on Dev-C++ 5.11 IDE with TDM-GCC compiler:
[Compiles without error or warning, but fails violently at runtime.]
anaphylaxis
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_S_construct null not valid
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Process exited after 210.3 seconds with return value 255
Press any key to continue . . .
 
 
Wow, it looks like multiple compilers (albeit all versions of gcc)
have this bug: they all silently accept initializing a std::string
to 0 at compile time, but the program always malfunctions at
runtime. I find that bizarre, and I really can't see a good reason
why compilers don't flag that construct as an "error" at compile-time.
 
 
--
Cheers,
Robbie Hatley
Midway City, CA, USA
perl -le 'print "\154o\156e\167o\154f\100w\145ll\56c\157m"'
http://www.well.com/user/lonewolf/
https://www.facebook.com/robbie.hatley
Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid>: Mar 25 08:54AM +0100

> cout << "brachiocephalic" << endl;
> return 0;
> }
 
Trying with both g++-4.8.4 and g++-5.3.1 (on
http://www.tutorialspoint.com/compile_cpp11_online.php) I get this
message:
 
> terminate called after throwing an instance of 'std::logic_error'
> what(): basic_string::_S_construct null not valid
 
I don't know what smart terminal configuration you use that somehow
hides this message (or maybe it is make's), but it is a fact that the
program does exactly what it is supposed to do.
 
> Wow, it looks like multiple compilers (albeit all versions of gcc)
> have this bug:
 
The bug is in your own code, not in g++ nor in any compiler. The
standard (N4296) describes the constructor (21.4.2§8):
 
| basic_string(const charT* s, const Allocator& a = Allocator());
|
| Requires: s points to an array of at least traits::length(s) + 1
| elements of charT.
 
Your code violates the requirement. It "crashes" by throwing
logic_error, as expected.
 
> time, but the program always malfunctions at runtime. I find that
> bizarre, and I really can't see a good reason why compilers don't flag
> that construct as an "error" at compile-time.
 
Because <string> is a library, and you should not expect the compiler to
care about library-specific requirements, which are outside its scope.
You will get the same result by, e.g., calling at() on a map with an
invalid key, or by any other misuse of the library.
 
-- Alain.
Qu0ll <qu0ll64@gmail.com>: Mar 25 02:28PM +1100

On 23/03/2016 10:54, Mr Flibble wrote:
> Trump was voted President and Jeremy Corbyn Prime Minister.
 
> I think they should call the comic "Radioactive Sausages".
 
> /Flibble
 
Lord Kanye for President in 2020! Just imagine, Trump versus
Yeezus/Jesus - the ultimate comedy spectacular in history!
 
--
 
And loving it,
 
-Qu0ll (Rare, not extinct)
_________________________________________________
Qu0llSixFour@gmail.com
[Replace the "SixFour" with numbers to email me]
ram@zedat.fu-berlin.de (Stefan Ram): Mar 25 02:24AM

>myClass() : i(42), j(13) {}
>myClass(int a, int b) : i(a), j(b) {}
 
One might also consider:
 
my_class( int const i = 42, int const j = 13 ): i( i ), j( j ) {}
 
>myClass& operator= (myClass o) {this->j = o.j; return *this;}
 
The parameter should be a reference.
 
When one defines a custom assignment operator,
one often also should specify a custom move assignment,
a custom copy constructor and a custom move constructor.
 
The effects of all these special member functions and
operator member functions should not be surprising to
users of the class.
 
But it is better to design the class in such a way that
one has to define none of the above!
Robbie Hatley <see.my.sig@for.my.address>: Mar 24 05:25PM -0700

On 3/23/2016 11:36 AM, Bob Langelaan wrote:
 
> ... students would be more likely to able to figure the issue
> on their own if the MS VS 2015 error messages were more
> illuminating.
 
This is yet another case where I find MS software bloody annoying.
Try Gnu's g++. While it is annoyingly silent about *some* errors
(see my post below about "initializing std::string to 0"),
it prints *lots* of warnings and errors for your code, including
a warning to the effect that "warning: non-static const member
'const int myClass::i' in class without a constructor":
 
%make const-member-test.exe DEBUG=1 PEDANTIC=1
Using pattern rule %.exe:%.cpp to compile const-member-test.cpp to const-member-test.exe:
g++ -I /rhe/include -pedantic -Wall -Wextra -Wfloat-equal -Wshadow -Wcast-qual
-Wcast-align -Wconversion -Winline -Wcomments -Wundef -Wunused-macros
-Wold-style-cast -Woverloaded-virtual -std=gnu++14 const-member-test.cpp
-L/rhe/lib -L/lib -lrh -lfl -ly -lm -lname -o /rhe/bin/test/const-member-test.exe
 
const-member-test.cpp:3:12: warning: non-static const member 'const int myClass::i'
in class without a constructor [-Wuninitialized]
const int i;
^
const-member-test.cpp: In function 'int main()':
const-member-test.cpp:8:10: error: use of deleted function 'myClass::myClass()'
myClass a, b;
^
const-member-test.cpp:1:7: note: 'myClass::myClass()' is implicitly deleted because
the default definition would be ill-formed:
class myClass
^
const-member-test.cpp:1:7: error: uninitialized const member in 'class myClass'
const-member-test.cpp:3:12: note: 'const int myClass::i' should be initialized
const int i;
^
const-member-test.cpp:8:13: error: use of deleted function 'myClass::myClass()'
myClass a, b;
^
const-member-test.cpp:9:4: error: use of deleted function
'myClass& myClass::operator=(const myClass&)'
a = b;
^
const-member-test.cpp:1:7: note: 'myClass& myClass::operator=(const myClass&)'
is implicitly deleted because the default definition would be ill-formed:
class myClass
^
const-member-test.cpp:1:7: error: non-static const member 'const int myClass::i',
can't use default assignment operator
 
/rhe/maketail:198: recipe for target 'const-member-test.exe' failed
make: [const-member-test.exe] Error 1
 
 
 
 
--
Cheers,
Robbie Hatley
Midway City, CA, USA
perl -le 'print "\154o\156e\167o\154f\100w\145ll\56c\157m"'
http://www.well.com/user/lonewolf/
https://www.facebook.com/robbie.hatley
Robbie Hatley <see.my.sig@for.my.address>: Mar 24 05:42PM -0700

Btw, there is nothing inherently wrong with having a non-static
(per-object) const member in a class. But if you *do*, you must
provide an assignment operator, even if it does nothing.
 
The following correction of your code compiles and runs fine:
 
#include <iostream>
using std::cout; using std::endl;
class myClass
{
public:
operator= (myClass) {return 0;}
const int i = 17;
};
 
int main()
{
myClass a;
myClass b;
a = b;
cout << "a.i = " << a.i << endl;
cout << "b.i = " << b.i << endl;
}
 
OUTPUT:
 
%const-member-test.exe
a.i = 17
b.i = 17
 
 
 
 
--
Cheers,
Robbie Hatley
Midway City, CA, USA
perl -le 'print "\154o\156e\167o\154f\100w\145ll\56c\157m"'
http://www.well.com/user/lonewolf/
https://www.facebook.com/robbie.hatley
Ian Collins <ian-news@hotmail.com>: Mar 25 02:00PM +1300

On 03/25/16 13:42, Robbie Hatley wrote:
 
> Btw, there is nothing inherently wrong with having a non-static
> (per-object) const member in a class. But if you *do*, you must
> provide an assignment operator, even if it does nothing.
 
If the const has an initialiser, why wouldn't you make it static?
 
> {
> public:
> operator= (myClass) {return 0;}
 
That's a syntax error...
 
--
Ian Collins
Robbie Hatley <see.my.sig@for.my.address>: Mar 24 06:49PM -0700

Oh, and I should also add that your assignment operator *need not*
do nothing. It's free to copy-over the non-const parts of objects
of your class.
 
For example:
 
#include <iostream>
using std::cout; using std::endl;
class myClass
{
public:
myClass() : i(42), j(13) {}
myClass(int a, int b) : i(a), j(b) {}
myClass& operator= (myClass o) {this->j = o.j; return *this;}
geti() {return i;}
getj() {return j;}
private:
int const i;
int j;
};
 
int main()
{
myClass a;
myClass b (86, 74);
cout << "Before assigning b = a :" << endl;
cout << "a.i = " << a.geti() << endl;
cout << "a.j = " << a.getj() << endl;
cout << "b.i = " << b.geti() << endl;
cout << "b.j = " << b.getj() << endl;
b = a;
cout << "After assigning b = a :" << endl;
cout << "a.i = " << a.geti() << endl;
cout << "a.j = " << a.getj() << endl;
cout << "b.i = " << b.geti() << endl;
cout << "b.j = " << b.getj() << endl;
}
 
 
OUTPUT:
 
%const-member-test.exe
Before assigning b = a :
a.i = 42
a.j = 13
b.i = 86
b.j = 74
After assigning b = a :
a.i = 42
a.j = 13
b.i = 86
b.j = 13
 
 
Note that b.j has now changed from 74 to 13, because j is a
non-const member, so the = operator can copy it over.
 
 
--
Cheers,
Robbie Hatley
Midway City, CA, USA
perl -le 'print "\154o\156e\167o\154f\100w\145ll\56c\157m"'
http://www.well.com/user/lonewolf/
https://www.facebook.com/robbie.hatley
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)