By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,320 Members | 2,212 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,320 IT Pros & Developers. It's quick & easy.

More Effective C++

P: n/a
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.

Apr 13 '07 #1
Share this Question
Share on Google+
4 Replies


P: n/a
On Apr 13, 10:09 am, "barcaroller" <barcarol...@music.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

Apr 13 '07 #2

P: n/a
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,charfixed,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 (61)-8-9324-1119, Mob 0401-054-155.
Apr 13 '07 #3

P: n/a
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.
Apr 13 '07 #4

P: n/a
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
Apr 13 '07 #5

This discussion thread is closed

Replies have been disabled for this discussion.