More Effective C++

[barcaroller]

I was thinking of buying Scott Meyer's second book (More Effective C++) and
noticed that it has not been updated since 1995 (unlike his other two famous
books). Does anyone know (rumour or otherwise) if a new edition is coming
out. I would hate to spend $50 today only to see a new edition on the
shelves tomorrow.

[bark]

On Apr 13, 10:09 am, "barcarolle r" <barcarol...@mu sic.netwrote:

I was thinking of buying Scott Meyer's second book (More Effective C++) and
noticed that it has not been updated since 1995 (unlike his other two famous
books). Does anyone know (rumour or otherwise) if a new edition is coming
out. I would hate to spend $50 today only to see a new edition on the
shelves tomorrow.

you could ask him directly

http://www.aristeia.com/books_frames.html

[Clem Clarke]

Some 20 years ago, it became clear that C strings were not as safe, nor
as fast, as strings in PL/I, Assembler or Pascal.

The primary reasons are that one needs to find the current length of a
string before or during a copy process - this is very time consuming.

Secondly, there is no way of determining the maximum length of a string,
and therefore when copying to a string, it is easy to over-write
adjacent storage with often disastrous consequences, including the
deliberate introduction of viruses.
Decades have passed and the C string problem continues. Buffer
over-runs are just part of the story, and the bugs that can be
introduced - the safety problem is still with us all and it has come
back to bite all of us on the lower part of our anatomy, over and over
again.

I have spent some years studying this problem and have developed some
User friendly C macros that solve the problem.

These solutions do enhance the speed and safety aspects of all "C"
programs - these benefits of speed and safety can be passed on to your
users.

The main benefits are:

* Increased speed (up to 20 times for some string handling)
* More reliability (strings cannot overwrite adjacent storage)
* Easier coding and debugging (consistent set of macros)
* Easier external variables

Here is a very short example:

dcl (op,charvar,253 ," ",ext); // Variable 'op' is defined
// as an External variable - Max length of 253 characters.
dcl (symbolic,charf ixed,8," ",ext); // Fixed length of 8

cpylit(op, "This is a 30 character string ");
cat(op,op); /* Concatenate variable op with it self. Now 60
characters */

cpy(symbolic,op ); /* Truncates it to 8 characters */

cpy(op,symbolic ); /* Copy it back. */

I invite you download the macros and code at
http://members.ozemail.com.au/~oscar.../fastsafe.html where a fuller
discussion can be found.

Clement Clarke

,-._|\ Clement V. Clarke - Author Jol, EASYPANEL, OSCAR, 370TO486
/ Oz \ Web: www.ozemail.com.au/~oscarptyltd
\_,--.x/ 38 Kings Park Road, West Perth, AUSTRALIA, 6005.
v Tel [phone], Mob [phone].

[Ian Collins]

Clem Clarke wrote:

Some 20 years ago, it became clear that C strings were not as safe, nor
as fast, as strings in PL/I, Assembler or Pascal.

C++ has a solution, std::string. Did you intend to post to comp.lang.c?

--
Ian Collins.

[Default User]

Clem Clarke wrote:
This clown did exactly the same thing on comp.lang.c, posted his crap
in the middle of an existing thread.

Once, maybe a mistake. Twice, well it's plonking time.


Brian