Subj : Re: A really stupid Question - how to build a library
To   : borland.public.cpp.borlandcpp
From : D Kat
Date : Thu Oct 07 2004 03:01 pm


"Ed Mulroy [TeamB]" <dont_email_me@invalid.com> wrote in message 
news:4165342f@newsgroups.borland.com...
> Note that I assumed from your message that you were creating code for use 
> by students.  Upon re-reading the message I am not sure how I formed that 
> opinion.  I have made more than a few bucks teaching professors C++ and C 
> who were assigned to teach language classes but were only a few pages 
> ahead (sometimes behind!) the students and wanted to express caution about 
> some things.
> Post and pre increment/decrement:
>
> ++var
> Increment var.  The value used in the expression is the new value.
>
> var++
> Increment var and save the value, but use the original value of var in the 
> expression.
>
> Same comments and syntax with -- except that it decrements instead of 
> incrementing.
>
> Consider the differences between what the loops do in this code:
>
>  int var;
>
>  for (var = 6; var < 22; var++)
>      function_A();
>
>  for (var = 6; var < 22; ++var)
>      function_A();
>
> The logical operations caused by these loops differ in that the first loop 
> requires that a copy of the original value of 'var' must be formed, saved 
> somewhere and loaded again after the increment and store of the new value.
>
> Restating:
> There is some additional overhead associated with the post increment (the 
> var++).  Compiler writers have long since caught on to this common bad 
> habit of programmers and optimize this specific usage for integers, but 
> the syntax is the same if 'var' is an object other than an integral type.
>
> When 'var' is a class or structure, not a uncommon situation in C++, 
> post-increment forces construction of a temporary instance of the class to 
> capture the original state, save of the temporary somewhere (possibly 
> causing an allocation call), call the post increment function, restore the 
> temporary test and test, save the test results, possibly a de-allocation 
> call for the temporary - BIG overhead.  Using var++ instead of ++var is 
> not a good habit.
>
> .  Ed
>
Things are going well... I'm in the process of changing all the incrementing 
code to pre rather than post....
Problem...  I have a pointer to a character array that I'm incrementing ... 
*message++

what is the proper way to deal with this?  ++(*message) or what? It compiles 
just fine as ++*message .... but that just seems... not right.

I'm also going back and forth on where to put the actual ISR since that 
varies and I can see no way to make it do optional operations without 
putting too much code in it.

For example... Some times we play one buffer out one channel and another out 
the other (in effect stereo).  Sometimes we play the same data point out of 
both channels (mono).....  I am already getting clicks once in every great 
while so I do not want to push it......  Unfortunately you can't create 
different ISRs that are called depending on the argument list (overloading 
?)...  Sorry, thinking outloud to the room.  It has been very helpful coming 
here.

.