Monday, August 24, 2015

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

Doug Mika <dougmmika@gmail.com>: Aug 24 10:17AM -0700

Could someone explain the following line to me?
 
#include <exception>
struct empty_stack: std::exception
{
const char* what() const throw(); //<--What does this line do?
};
Doug Mika <dougmmika@gmail.com>: Aug 24 10:28AM -0700

On Monday, August 24, 2015 at 12:17:27 PM UTC-5, Doug Mika wrote:
> {
> const char* what() const throw(); //<--What does this line do?
> };
 
What I meant to ask is, shouldn't we instead have something with {} brackets and something inside? Like:
 
class myexception: public std::exception
{
const char* what() const throw()
{
return "My exception happened";
}
}
Bo Persson <bop@gmb.dk>: Aug 24 07:35PM +0200

On 2015-08-24 19:28, Doug Mika wrote:
> return "My exception happened";
> }
> }
 
Yes, you could do that, or you could put the function in you .cpp file
and perhaps produce a more elaborate message there.
 
 
Bo Persson
Doug Mika <dougmmika@gmail.com>: Aug 24 10:50AM -0700

On Monday, August 24, 2015 at 12:36:09 PM UTC-5, Bo Persson wrote:
 
> Yes, you could do that, or you could put the function in you .cpp file
> and perhaps produce a more elaborate message there.
 
> Bo Persson
 
So what does my first post do? That is, what do we have if we only have:
#include <exception>
struct empty_stack: std::exception
{
const char* what() const throw(); //No {}, so what happens without these?
};
Christopher Pisz <nospam@notanaddress.com>: Aug 24 01:07PM -0500

On 8/24/2015 12:50 PM, Doug Mika wrote:
> {
> const char* what() const throw(); //No {}, so what happens without these?
> };
 
You have a broken class that is inherited from std::exception with all
the methods that std::exception has, with what() being overriden and
inaccessable.
 
You'll also have good times when it is running in unicode vs multibyte.
 
 
--
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---
Christopher Pisz <nospam@notanaddress.com>: Aug 24 01:10PM -0500

On 8/24/2015 1:07 PM, Christopher Pisz wrote:
 
> You have a broken class that is inherited from std::exception with all
> the methods that std::exception has, with what() being overriden and
> inaccessable.
 
In your example that uses class. struct is public by default.
In that case, you just don't have any implementation and I imagine it
would produce a link error when you called myexception::what
 
 
 
 
--
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---
Bo Persson <bop@gmb.dk>: Aug 24 08:40PM +0200

On 2015-08-24 19:50, Doug Mika wrote:
> {
> const char* what() const throw(); //No {}, so what happens without these?
> };
 
You have a declaration of a member function. The function is virtual, as
it matches a virtual function from the base class.
 
You have to provide the full definition of the function somewhere else,
perhaps in a .cpp file.
 
 
Bo Persson
Victor Bazarov <v.bazarov@comcast.invalid>: Aug 24 03:29PM -0400

On 8/24/2015 1:50 PM, Doug Mika wrote:
> {
> const char* what() const throw(); //No {}, so what happens without these?
> };
 
In case nobody else answers (and in case that you didn't know), the
"throw()" is the exception-specification for that member and it says
that the member function does *not* throw any exceptions. Same effect
can be achieved with keyword 'nothrow' or 'nothrow(/const-expr/)' if the
/const-expr/ evaluates to 'true' (only C++11 and later).
 
V
--
I do not respond to top-posted replies, please don't ask
Thomas Richter <thor@math.tu-berlin.de>: Aug 24 10:51PM +0200

Am 24.08.2015 um 21:29 schrieb Victor Bazarov:
 
> In case nobody else answers (and in case that you didn't know), the
> "throw()" is the exception-specification for that member and it says
> that the member function does *not* throw any exceptions.
 
Actually, I would rather say that the C++ compiler ensures that the
function never throws. Actually, throw() is equivalent to
 
try {
.. function body ..
} catch () {
std::unexpected();
}
 
So there is an additional overhead included in using throw() because the
compiler has to catch exceptions within functions marked as throw().
 
> Same effect
> can be achieved with keyword 'nothrow' or 'nothrow(/const-expr/)' if the
> /const-expr/ evaluates to 'true' (only C++11 and later).
 
You probably mean "noexcept"? Actually, that is not quite equivalent to
throw(), because the former calls std::terminate() if an exception tries
to leave the function (i.e. the compiler is not required to unroll the
stack).
 
Greetings,
Thomas
Juha Nieminen <nospam@thanks.invalid>: Aug 24 12:06PM

> And even today, C++ is slower than C in the »programming
> language shootout« (the last time I looked it up).
 
It's impossible for C++ to be slower than C, given that (almost) any
valid C program is also a valid C++ program. (Those "almost" exceptions
are not things that affect speed, mainly only syntax.)
 
The only reason compiling a C program as C++ would make it slower is
if the compiler does something stupid with it, but that's hardly the
language's problem. It's the compiler's problem.
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Juha Nieminen <nospam@thanks.invalid>: Aug 24 12:13PM

> That is a big step in the wrong direction. That means that a new
> "concepts" hierarchy is created that complexifies the compiler yet a bit
> more.
 
Well, you have two choices:
 
1) Clear template syntax errors at the cost of slightly longer
compile times.
 
2) Slightly faster compile times at the cost of unclear template
syntax errors.
 
Which one do you prefer?
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Juha Nieminen <nospam@thanks.invalid>: Aug 24 12:27PM

> can take you quite far. I added vectors, lists, hash tables (C++ added
> that shortly afterwards), implemented the visitor pattern, you have
> iterators, etc. All in C.
 
The biggest problem is that without RAII, using such data containers
becomes unyieldingly complex.
 
Because there is no RAII, you have to free the data containers explicitly.
This requirement is "inherited" by anything that uses such data containers.
For example, if you put such a data container in a struct, the struct
automatically "inherits" the need for manual construction and destruction.
 
With complex data structures, it can become really complicated to track
which structs require manual construction and destruction, and which don't.
 
And we all know how error-prone (and tedious) non-RAII manual destruction
can be. It's one of the biggest sources of bugs in C programs out there.
 
And of course you also have the problem of having data structures as
members of data structures (for example you have a struct containing
some dynamic data structure, and you need to create another dynamic
data structure containing elements of that struct type.) The data
structure needs to know how to destroy those elements appropriately.
 
The classical way of doing that is to add "member functions" to structs
for construction and destruction... as function pointers. Which increase
the size of the struct, thus adding overhead. (In C++ member functions
incur no penalty on the size of the class or struct, especially if
they are not virtual. Even if they are virtual, the penalty is that
of one single pointer regardless of the number of virtual member
functions.)
 
And debugging macro-based dynamic data containers must be a joy.
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
David Brown <david.brown@hesbynett.no>: Aug 24 02:27PM +0200

On 24/08/15 14:06, Juha Nieminen wrote:
 
> The only reason compiling a C program as C++ would make it slower is
> if the compiler does something stupid with it, but that's hardly the
> language's problem. It's the compiler's problem.
 
That is not quite entirely true. There are a few nuances that make a
small difference. For example, if a function bar() contains a call to
an external function foo(), the code generated for bar() must take into
account the possibility that foo() throws an exception. This can mean
different requirements for stack layout or restrictions to optimisations
and re-organisations that would not apply in the case of plain C.
Compilers have got very good at optimising in the face of exceptions,
and minimising their impact - but there can still be a non-zero overhead.
 
This is, I think, at least one reason why benchmark comparisons
regularly show C++ to be a percent or two slower than C for the same
code, typically compiled with the same compiler. Usually those couple
of percent are not important, of course, and the use of C++ gives many
other benefits - and such benchmarks say nothing about how the code
could have been written better or faster using C++ rather than C.
 
(I haven't tried look at this in detail myself - maybe I will do so if I
get the time.)
BGB <cr88192@hotmail.com>: Aug 24 09:54AM -0500

On 8/24/2015 7:27 AM, Juha Nieminen wrote:
> of one single pointer regardless of the number of virtual member
> functions.)
 
> And debugging macro-based dynamic data containers must be a joy.
 
FWIW, in C, if you have a single method which may be shared among a
number of structs, it is typical to have another struct as a "vtable".
 
then you would access it as:
obj->vt->Whatever(obj, ...);
 
another variant is to have the object as a double-pointer to the vtable,
in chich case it is:
(*obj)->Whatever(obj, ...);
 
 
the main reason to put the function-pointers directly in the struct
would be if you want to be able to configure which functions are called
on a per-instance basis. all this depends mostly on what one is doing
with it.
 
 
Bo Persson <bop@gmb.dk>: Aug 24 05:00PM +0200

On 2015-08-24 14:27, Stefan Ram wrote:
 
> And this seemed to be what happened in the case of
> the programming language shootout the last time I
> looked at it IIRC.
 
From what I could see, the benchmarks were made up by taking a set of C
programs and converting them to C++ in such a way that they ran slower.
Not by malice it seems, just by incompetence.
 
For example, take a fixed size static array and replace it with a
std::vector. Then fill it with push_back. Now C++ is slower than C. :-)
 
 
Bo Persson
Wouter van Ooijen <wouter@voti.nl>: Aug 24 05:25PM +0200

Op 24-Aug-15 om 5:10 PM schreef Stefan Ram:
 
> Agreed, but this is possibly hinting at the possibility that
> it might be more difficult to become so competent in C++ that one
> can write code as fast as C code than to become competent in C.
 
But every C programmer starts out that competent just by *not* knowing
any C++!
 
So if you are performance-wise in a tight spot, and you are
- sure that the C solution will be good enough
- unsure about whether your C++ attempt might be better or not
 
the solution is simple and clear.
 
This of course sweeps aside that a reasonable C++ solution might be
- easier to write
- faster
 
Wouter van Ooijen
Bo Persson <bop@gmb.dk>: Aug 24 07:31PM +0200

On 2015-08-24 17:10, Stefan Ram wrote:
 
> Agreed, but this is possibly hinting at the possibility that
> it might be more difficult to become so competent in C++ that one
> can write code as fast as C code than to become competent in C.
 
It doesn't have to be. It could also mean that the benchmarks are
selected to contain things that are easy to do in C. What if they are hard?
 
This is an example from one of Bjarne's papers:
 
#include <vector>
#include <fstream>
#include <algorithm>
#include <string>
 
using namespace std;
 
int main(int argc,char* argv[])
{
char* file = argv[2]; // input file name
char* ofile = argv[3]; // output file name
 
vector<string> buf;
 
fstream fin(file, ios::in);
string d;
while(getline(fin, d)) buf.push_back(d); //add line to buf
 
sort(buf.begin(), buf.end());
 
fstream fout(ofile, ios::out);
copy(buf.begin(), buf.end(), ostream_iterator<string>(fout,"\n"));
 
}
 
 
Now the challenge is:
 
"You have a file with an unknown number of text lines of variable
lengths. Read the lines and write them out sorted in another file.
 
Please do this in less than 10x the number of lines of C code, and make
it run faster."
 
 
Why do we never see anything like this?
 
 
 
You can't trust a benchmark you haven't rigged yourself. :-)
 
 
Bo Persson
Christopher Pisz <nospam@notanaddress.com>: Aug 24 02:23PM -0500

On 8/24/2015 1:28 PM, Stefan Ram wrote:
 
> BTW: The original implementation of the famous UNIX
> »sort« utility should have been written in C, so one can
> have a look at this for a realistic implementation.
 
Can we use C++ in the C++ newsgroup?
malloc? really?
void * array?
void * return type?
void * component?
Macros?
abort?
 
How many bad habits can you teach someone with something as easy as
reading a file?
 
 
--
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---
scott@slp53.sl.home (Scott Lurndal): Aug 24 07:49PM

>lengths. Read the lines and write them out sorted in another file.
 
>Please do this in less than 10x the number of lines of C code, and make
>it run faster."
 
int main(int argc, const char **argv)
{
system ("sort -d inputfile > outputfile");
}
 
:=)
Christopher Pisz <nospam@notanaddress.com>: Aug 24 02:57PM -0500

On 8/24/2015 2:23 PM, Christopher Pisz wrote:
> abort?
 
> How many bad habits can you teach someone with something as easy as
> reading a file?
 
I realize you're intentionally writing craptastic C code for the sake of
yet another silly C++ vs C argument, but you cut the context out and now
noobs everywhere will be getting this post in their search for "C++ read
file"
 
--
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---
ram@zedat.fu-berlin.de (Stefan Ram): Aug 24 12:27PM

>It's impossible for C++ to be slower than C, given that (almost) any
>valid C program is also a valid C++ program. (Those "almost" exceptions
>are not things that affect speed, mainly only syntax.)
 
You are thinking of technical aspects in isolation.
 
But programming also has psychological and social
aspects.
 
Assume that a group of C programmers and a group of
C++ programmers is created. Assume that the judges
try to be fair and to give both groups the same number
of programmers with the same amount of experience as
far as this is possible.
 
Now, it /is/ possible that the solutions turned in
by the C++ group run slower than the solutions turned
in by the C group (for whatever reason).
 
And this seemed to be what happened in the case of
the programming language shootout the last time I
looked at it IIRC.
ram@zedat.fu-berlin.de (Stefan Ram): Aug 24 12:43PM

>It's impossible for C++ to be slower than C, given that (almost) any
>valid C program is also a valid C++ program. (Those "almost" exceptions
>are not things that affect speed, mainly only syntax.)
 
It's possible that you have forgotten »restrict«.
 
(However, both »restrict« and C++ rvalue references might
not [yet] have had a great impact on the results of the
programming language shootout benchmark.)
ram@zedat.fu-berlin.de (Stefan Ram): Aug 24 03:10PM

>Not by malice it seems, just by incompetence.
>For example, take a fixed size static array and replace it with a
>std::vector. Then fill it with push_back. Now C++ is slower than C. :-)
 
Agreed, but this is possibly hinting at the possibility that
it might be more difficult to become so competent in C++ that one
can write code as fast as C code than to become competent in C.
ram@zedat.fu-berlin.de (Stefan Ram): Aug 24 06:28PM

>You have a file with an unknown number of text lines of variable
>lengths. Read the lines and write them out sorted in another file.
 
One needs a single helper function in C to do the hard work
that is so general that I believe some library should
already contain it:
 
void * append
( void * array,
size_t * pos,
size_t * capacity,
size_t compsize,
void * component )
 
for example:
 
{ int capacity = 10;
int * a = malloc( capacity * sizeof *a );
if( !a )abort();
int position = 0;
int value = 65;
 
/* append value to a */
a = append( a, &position, &capacity, sizeof *a, &value );
if( !a )abort();
 
... }
 
This is intended to append a value to the buffer a,
reallocating if necessary.
 
Using the preprocessor, we could get some more efficient
»generic« implementations of »append« for specific component
types.
 
DEFINE_APPEND(append_int,int);
DEFINE_APPEND(append_double,double);
 
. The above call would then become
 
a = append_int( a, &position, &capacity, value );
 
I do not claim that this will be faster than the C++
implementation. I am just thinking about how it will
become possible at all in C.
 
Another approach (that will not be efficient, however,
however), would be to read the line sizes and number of
lines on a first pass and write them into temporary (tmpnam)
helper files. Then allocate the buffers from the sizes given
in those helper files and do the rest of the work in a
second pass. (You wrote »file« - not »stream«.)
 
BTW: The original implementation of the famous UNIX
»sort« utility should have been written in C, so one can
have a look at this for a realistic implementation.
Juha Nieminen <nospam@thanks.invalid>: Aug 24 12:42PM

> You put a try-catch in a place where you know how to handle the error. For
> many programs this means a single try-catch in main() where you report the
> error and exit the program with an error exit code.
 
There are environments where you can't exit cleanly from main().
(For example iOS. If main() is exited, the system considers the
program having crashed.)
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
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)