bartc wrote:
You almost persuaded me to have another look at C++ myself. Almost, then
I realised that as soon as I had another look at it's ghastly syntax and
general incomprehensibility, I would go back to C with considerable
relief.

I honestly can't understand what you are talking about. I'm sorry, but
it just sounds like you are being really prejudiced.

Consider this small program:

//----------------------------------------------------------------------
#include <algorithm

int main()
{
int table1[] = { 5, 3, 10, 35, 4, 1, 40, 1, 8, 3 };
double table2[] = { 20.2, 24.6, 12, 1, -4.2, 5.5, -20, 20.2, 1, 0 };

std::sort(table1, table1 + 10);
std::sort(table2, table2 + 10);

// print the tables here, or whatever
}
//----------------------------------------------------------------------

Even though the standard C library also provides a sorting utility
(qsort), consider how much more code you have to write in order to use
it. (Also consider how much more inefficient it will be because of that.)

Exactly what is so "ghastly" and "incomprehensible" here? To me this
looks very simple and straightforward (well, assuming you understand
what "table1 + 10" means, but that should be rather obvious to an
experienced C programmer). Definitely much simpler than the equivalent C
program.

bartc wrote:
You almost persuaded me to have another look at C++ myself. Almost, then
I realised that as soon as I had another look at it's ghastly syntax and
general incomprehensibility, I would go back to C with considerable relief.

I honestly can't understand what you are talking about. I'm sorry, but
it just sounds like you are being really prejudiced. It sounds like
immediately when you see some extra angle brackets (<something>) or
double colons (: you immediately give up telling yourself that "this
is incomprehensible", without even seriously wanting to give it a try.

inline void load(

&t,
const unsigned int file_version

,
boost::serialization::stl::archive_input_unique

(ar, t);
}

There are quite many things which are vastly simpler to express in C++
than in C. Just as a fair example of a feature provided by both
languages, let's take sorting. Consider this small program:

"Juha Nieminen" <nospam at (no spam) thanks.invalid> wrote in message
Consider this small program:

//----------------------------------------------------------------------
#include <algorithm

int main()
{
int table1[] = { 5, 3, 10, 35, 4, 1, 40, 1, 8, 3 };
double table2[] = { 20.2, 24.6, 12, 1, -4.2, 5.5, -20, 20.2, 1,
0 }; std::sort(table1, table1 + 10);
std::sort(table2, table2 + 10);

// print the tables here, or whatever
}
//----------------------------------------------------------------------

Even though the standard C library also provides a sorting utility
(qsort), consider how much more code you have to write in order to
use it. (Also consider how much more inefficient it will be
because of that.) Exactly what is so "ghastly" and
"incomprehensible" here? To me
this looks very simple and straightforward (well, assuming you
understand what "table1 + 10" means, but that should be rather
obvious to an experienced C programmer). Definitely much simpler
than the equivalent C program.

Like I said, you make an excellent case for C++. Maybe you should
write a book.

I first came across C++ source when trying to decode MFC header
files, and decided they weren't designed to be understood by a mere
human (possibly they weren't).

More typical C++ does still appear much more intimidating than your
simple example (some of us just can't grok classes and object
hierarchies and what-not).

I understand that much of the power of C++ is the ability to define
all these neat extensions and datatypes, and make them appear as
though they are built-in to the language.

The trouble is the language used for defining them (with the
necessary bells and whistles) is the same language used for
everyday programming, with considerable cross-over. It seems like a
language-implementation language, used as it's own language, if
that makes sense..

He probably thinks of something like this (a random example from the
boost library) :

BGB / cr88192 wrote:
"Jerry Coffin" <jerryvcoffin at (no spam) yahoo.com> wrote:

The same happens with things like closing files and telling a GUI
system you no longer need a handle to a resource. In theory, you
_could_ do all these manually, and you can even do so in fact for
programs that are really trivial. For a program of any size or
complexity, however, remains a mostly theoretical possibility.


as noted, in my case all this has not really been a problem...

granted, I very rarely do my memory-management directly with malloc/free
either (most often, I build my own memory mangagers which either build on
top of them, or do their basic allocation directly with mmap or
VirtualAlloc...).


many of these, in turn, support various, typically specialized,
approaches to memory management.

I also have a "general purpose" garbage collector, which I usually treat
about like a malloc/free implementation, but I leave it up to the GC to
deal with cases where the memory lifetime is not obvious.

Memory is only one resource a programme has to manage.

--
Ian Collins

"Ian Collins" <ian-news at (no spam) hotmail.com> wrote in message
news:7co7v7F28he98U2 at (no spam) mid.individual.net...
BGB / cr88192 wrote:
"Jerry Coffin" <jerryvcoffin at (no spam) yahoo.com> wrote:
The same happens with things like closing files and telling a GUI
system you no longer need a handle to a resource. In theory, you
_could_ do all these manually, and you can even do so in fact for
programs that are really trivial. For a program of any size or
complexity, however, remains a mostly theoretical possibility.

as noted, in my case all this has not really been a problem...

granted, I very rarely do my memory-management directly with malloc/free
either (most often, I build my own memory mangagers which either build on
top of them, or do their basic allocation directly with mmap or
VirtualAlloc...).


many of these, in turn, support various, typically specialized,
approaches to memory management.

I also have a "general purpose" garbage collector, which I usually treat
about like a malloc/free implementation, but I leave it up to the GC to
deal with cases where the memory lifetime is not obvious.
Memory is only one resource a programme has to manage.


it is, however, the main resource, and about the only resource whose
management becomes an application-scale issue...

in my experience, nearly every other resource, such as:
FILE handles;
GUI-related handles (GDI+, ...);
....

can be more or less entirely confined to small sections of code, and "never
seen again".

--
Ian Collins

"Richard Herring" <junk at (no spam) [127.0.0.1]> wrote in message
news:UACdN5CuOuZKFw45 at (no spam) baesystems.com...
In message <h45854$v96$1 at (no spam) news.albasani.net>, BGB / cr88192
cr88192 at (no spam) hotmail.com> writes

stack objects don't need to be freed,

The _memory_ occupied by stack objects doesn't need to be freed.
But any other resources they allocate still need to be deallocated.

stack objects typically don't need to allocate memory or resources either
(instead, any such reasources would be allocated and freed by the parent
function...).

and due to other reasons, one knows
when a stack object goes out of scope, making it trivial in this case to
call the destructor

See other examples in this thread where it's not so trivial, because error
handling means you have to abandon normal processing and still return
cleanly.


most cases it is either trivial, or the function is in need of being split
apart into smaller functions (AKA: the result of bad coding...).


(in the rare case where stack-based objects actually
need them, which personally I have not really seen, since they are
typically
transient pass-by-value types...).

Like FILE* ?


FILE is an allocated type, not a stack-based type.

In message <h485cg$j18$1 at (no spam) news.albasani.net>, BGB / cr88192
cr88192 at (no spam) hotmail.com> writes

"Richard Herring" <junk at (no spam) [127.0.0.1]> wrote in message
news:UACdN5CuOuZKFw45 at (no spam) baesystems.com...
In message <h45854$v96$1 at (no spam) news.albasani.net>, BGB / cr88192
cr88192 at (no spam) hotmail.com> writes

[big snip]

stack objects don't need to be freed,

The _memory_ occupied by stack objects doesn't need to be freed.
But any other resources they allocate still need to be deallocated.

Perhaps I should have written "any other resources they represent" to
make it clearer.


stack objects typically don't need to allocate memory or resources either
(instead, any such reasources would be allocated and freed by the parent
function...).

And how does the "parent function" manage those resources? If the
lifetime of the resource is the duration of the function call, a stack
object is precisely what it uses to track that resource. The stack
object may not itself perform the allocation, but it's
still responsible for tracking and eventually releasing it.

and due to other reasons, one knows
when a stack object goes out of scope, making it trivial in this case to
call the destructor

See other examples in this thread where it's not so trivial, because error
handling means you have to abandon normal processing and still return
cleanly.


most cases it is either trivial, or the function is in need of being split
apart into smaller functions (AKA: the result of bad coding...).


(in the rare case where stack-based objects actually
need them, which personally I have not really seen, since they are
typically
transient pass-by-value types...).

Like FILE* ?


FILE is an allocated type, not a stack-based type.

I said FILE *, not FILE.

FILE * is precisely an example of a resource handle which may be
stack-based:

int update_file(char * filename)
{
FILE * file = fopen(filename", "r+");
/* do stuff to the file */
return fclose(file);
}

In this case the handle happens to be a pointer, but there are plenty
of other instances where resources are represented by opaque handle
types.

In message <h485cg$j18$1 at (no spam) news.albasani.net>, BGB / cr88192
cr88192 at (no spam) hotmail.com> writes

"Richard Herring" <junk at (no spam) [127.0.0.1]> wrote in message
news:UACdN5CuOuZKFw45 at (no spam) baesystems.com...
In message <h45854$v96$1 at (no spam) news.albasani.net>, BGB / cr88192
cr88192 at (no spam) hotmail.com> writes

[big snip]

stack objects don't need to be freed,

The _memory_ occupied by stack objects doesn't need to be freed.
But any other resources they allocate still need to be deallocated.

Perhaps I should have written "any other resources they represent" to make
it clearer.


stack objects typically don't need to allocate memory or resources either
(instead, any such reasources would be allocated and freed by the parent
function...).

And how does the "parent function" manage those resources? If the lifetime
of the resource is the duration of the function call, a stack object is
precisely what it uses to track that resource. The stack object may not
itself perform the allocation, but it's

and due to other reasons, one knows
when a stack object goes out of scope, making it trivial in this case to
call the destructor

See other examples in this thread where it's not so trivial, because
error
handling means you have to abandon normal processing and still return
cleanly.


most cases it is either trivial, or the function is in need of being split
apart into smaller functions (AKA: the result of bad coding...).


(in the rare case where stack-based objects actually
need them, which personally I have not really seen, since they are
typically
transient pass-by-value types...).

Like FILE* ?


FILE is an allocated type, not a stack-based type.

I said FILE *, not FILE.

FILE * is precisely an example of a resource handle which may be
stack-based:

int update_file(char * filename)
{
FILE * file = fopen(filename", "r+");
/* do stuff to the file */
return fclose(file);
}

In this case the handle happens to be a pointer, but there are plenty of
other instances where resources are represented by opaque handle types.

--
Richard Herring

BGB / cr88192 wrote:
"Ian Collins" <ian-news at (no spam) hotmail.com> wrote in message
news:7co7v7F28he98U2 at (no spam) mid.individual.net...
BGB / cr88192 wrote:
"Jerry Coffin" <jerryvcoffin at (no spam) yahoo.com> wrote:
The same happens with things like closing files and telling a GUI
system you no longer need a handle to a resource. In theory, you
_could_ do all these manually, and you can even do so in fact for
programs that are really trivial. For a program of any size or
complexity, however, remains a mostly theoretical possibility.

as noted, in my case all this has not really been a problem...

granted, I very rarely do my memory-management directly with
malloc/free either (most often, I build my own memory mangagers which
either build on top of them, or do their basic allocation directly with
mmap or VirtualAlloc...).


many of these, in turn, support various, typically specialized,
approaches to memory management.

I also have a "general purpose" garbage collector, which I usually
treat about like a malloc/free implementation, but I leave it up to the
GC to deal with cases where the memory lifetime is not obvious.
Memory is only one resource a programme has to manage.


it is, however, the main resource, and about the only resource whose
management becomes an application-scale issue...

in my experience, nearly every other resource, such as:
FILE handles;
GUI-related handles (GDI+, ...);
....

can be more or less entirely confined to small sections of code, and
"never seen again".

That's a pretty small experience!

"Ian Collins" <ian-news at (no spam) hotmail.com> wrote:
BGB / cr88192 wrote:

another, far lesser cost, is when writing libraries which are essentially
a large amount on thin wrapper code which needs to use C-based input and
exporting a C-based API, in which case, one would end up having to use
'extern "C"' in nearly every source file for wrapping nearly all of the
code, in which case the inconvinience of this wraping/... is not likely
to pay for the gain in convinience of having used C++ in this situation.
No, one would use 'extern "C"' where appropriate in the headers. The
source files are unaffected.


AFAIK, both the declarations of the functions in the header, as well as
their implementation as functions, have to be wrapped...

I would think it would be the same as things like "__declspec(dllexport)",
which have to be done in both places, otherwise the compiler gets angry...

BGB / cr88192 wrote:
"Ian Collins" <ian-news at (no spam) hotmail.com> wrote:
BGB / cr88192 wrote:

another, far lesser cost, is when writing libraries which are
essentially a large amount on thin wrapper code which needs to use
C-based input and exporting a C-based API, in which case, one would end
up having to use 'extern "C"' in nearly every source file for wrapping
nearly all of the code, in which case the inconvinience of this
wraping/... is not likely to pay for the gain in convinience of having
used C++ in this situation.
No, one would use 'extern "C"' where appropriate in the headers. The
source files are unaffected.


AFAIK, both the declarations of the functions in the header, as well as
their implementation as functions, have to be wrapped...

No, only the declarations.

I would think it would be the same as things like
"__declspec(dllexport)", which have to be done in both places, otherwise
the compiler gets angry...

What's that?

--
Ian Collins

I did some measurements for COS (C Object System) vs C++ vs Objective-
C. The results are described in the following papers in page 9 for

http://cos.cvs.sourceforge.net/viewvc/cos/doc/cos_draft-dls09.pdf.gz

and in page 14 for

http://cos.cvs.sourceforge.net/viewvc/cos/doc/cos_draft-oopsla09.pdf.gz

I have unzipped the PDF files on the CVS repository and included some
minor remarks I got recently for the DLS09 paper. But it has doubled
the time required to download the content of the directory.

I did some measurements for COS (C Object System) vs C++ vs Objective-
C. The results are described in the following papers in page 9 for

http://cos.cvs.sourceforge.net/viewvc/cos/doc/cos_draft-dls09.pdf.gz

and in page 14 for

http://cos.cvs.sourceforge.net/viewvc/cos/doc/cos_draft-oopsla09.pdf.gz

I have unzipped the PDF files on the CVS repository and included some
minor remarks I got recently for the DLS09 paper. But it has doubled
the time required to download the content of the directory.

BGB / cr88192 wrote:
you seem to be opposing "coding conventions".
coding conventions can be more or less equated with code being well
written...

I'm not opposing coding conventions. I use lots of coding conventions
when I develop programs.

What I oppose are coding conventions which exist solely to get around
limitations of the language. These tend to make programs more complex
than they need to be.

Yes, I readily admit that programming in C++ is in no way free of
necessary coding conventions which exist because of the limitations of
C++ (compared to many higher-level languages). My point is, however,
that in well-written C++ *less* coding conventions of this type are
needed compared to C, making development simpler. Also, many of these
coding conventions are more familiar to most experienced C++ programmers
and can be seen much more easily (eg. because they are used by the C++
standard libraries and such). In C most of these coding conventions are
quite programmer-specific.

why should one worry about more vs less conventions?...

Because more coding conventions makes the program more difficult to
read and understand.

A coding convention is kind of "metalanguage" in the sense that you
are writing in your own "subset" of the programming language. You use a
kind of "meta-C" on top of the bare C programming language, for the
purpose of avoiding pitfalls and errors (such as memory leaks, etc).

The problem is that your "metalanguage" might not be immediately
obvious to someone reading your code and who doesn't know about your
coding conventions.

When these extra coding conventions are *not needed* (rather than
intentionally avoided), the code tends to be more straightforward and
simpler, without any hidden "metalanguage" being used.