---------------

FIDO MESSAGE AREA==> TOPIC: 203 C++           Ref: E5X00000 Date: 05/14/97
From: PETER HAYWOOD                                         Time: 03:26am
\/To: QUINTIN OLIVER                                      (Read 3 times)
Subj: Re: Err

Groovy hepcat Quintin Oliver jived with All on 18 Apr 97  12:15:04!
Err's a cool scene. Dig it!
 QO> What the heck is DJGPP i'm kinda getting sick of techno babble...
  It's a compiler, a DOS port of the freeware GNU C/C++ compiler.
                                                  Wolvaen
... "That city will NEVER be rebuilt," the prophets babble on.
--- Blue Wave/RA v2.20
 * Origin: The Gate, Melbourne Australia, +61-3-9809-5097 28.8k  (3:633/159)
---------------

FIDO MESSAGE AREA==> TOPIC: 203 C++           Ref: E5X00001 Date: 05/27/97
From: TIM LOH                                               Time: 01:06am
\/To: ALL THE GALS                                        (Read 3 times)
Subj: chit chat

I m new will some body talk to me my call sign is viper2. call me and i'll 
get back to you asap.
Tim Loh
--- FMail/386 1.20
 * Origin: Comms Barrier BBS +61.3.9585.1112, +61.3.9583.6119 (3:632/533)
---------------

FIDO MESSAGE AREA==> TOPIC: 203 C++           Ref: E5X00002 Date: 05/27/97
From: JERRY COFFIN                                          Time: 09:14am
\/To: CAMERON CLARK                                       (Read 3 times)
Subj: compiler opt.

On (25 May 97) Cameron Clark wrote to Jerry Coffin...
 CC>     How many layers of caching does one need? get?
Hard to say with any certainty...
 CC>     It seems that most likely the drive does some caching/readahead
 CC>     and then OS does the same, and then the compiler does the same.
 CC>     It would seem that there is quite a bit of overkill if a modern
 CC>     compiler assumes that its own caching will improve upon the
 CC> caching up the ladder.
Try a bit of testing:
#include <stdio.h>
#include <time.h>
int main(void) {
    clock_t start = clock();
    FILE *null_dev = fopen("NUL", "wb");
    for ( int i=0; i<100000; i++)
        putc( i % 255, null_dev);
    printf("Time with buffering: %f",
        static_cast<float>(clock()-start)/CLOCKS_PER_SEC);
    setvbuf(null_dev, NULL, _IONBF, 0);
    start = clock();
    for ( i=0; i<100000; i++)
        putc (i % 255, null_dev);
    printf("Time without buffering: %f",
        static_cast<float>(clock()-start)/CLOCKS_PER_SEC);
    return 0;
}
On my system, the version with buffering turned on is roughly 20 times
as fast as the version with it turned off.
Now, note that this is writing to the NUL device, so no output is ever
actually generated at all.  What we're doing here is simply reducing the
overhead in having to call the OS evertime we want to write a character.
After we do that, the OS simply discards the character.
In my experience adding at least a little simple-minded buffering to a
program will typically give a speed increase of 15 or 20 to 1.
 CC>     While I do agree with the use of inline for some functions, I've
 CC>     never been a believer in the use of macros. I find macros in a
 CC> high level language deconstructive to the ideas behind strong
 CC> typecasting
In this case, they're macros simply because they're left-overs from C,
which lacks inline functions.  If they'd been designed specifically for
C++, they'd undoubtedly be inline functions instead.  However, this is
more or less beside the point.  The simple fact is that for simple
character at a time I/O, iostreams are typically quite a bit slower than
their C counterparts.  They may be more typesafe, but in many cases
taking a 2 or 3:1 speed hit simply isn't acceptable.
    Later,
    Jerry.
... The Universe is a figment of its own imagination.
--- PPoint 1.90
 * Origin: Point Pointedly Pointless (1:128/166.5)
---------------

FIDO MESSAGE AREA==> TOPIC: 203 C++           Ref: E5X00003 Date: 05/27/97
From: JERRY COFFIN                                          Time: 10:08am
\/To: FRANK MASINGILL                                     (Read 3 times)
Subj: getline?

On (26 May 97) Frank Masingill wrote to Cliff Rhodes...
 > FM>void main()
 > Frank, please use int main(void) !!!!
 FM>     Thanks, Cliff, I will.  But WHY do the books I'm following not use
 FM> it?  They are some of the most promient names like Lafore, etc.  I'm
 FM> not implying that means they are right - just asking why you make a
 FM> point of it?
Mostly because it tends to generate MUCH longer discussions than it
really merits.  Most compilers will accept main returing void without
complaint.  However, it's not really portable, and (more importantly)
generally ends up returning random values to the OS when it finishes.
Depending on the OS and shell in use, this tends to make the program
less useful, and with some can be extremely frustrating.  Returning some
value to indicate (at minimum) sucess or failure in operation is so
trivial to add that it's hardly worth discussing doing otherwise.
As far as books go: well, you'll quickly find that many (if not most)
books set rather poor examples in some area or another.  Some relatively
well known authors are notorious among better programmers for the
exceptionally poor examples they set.  Herbert Schildt is probably the
best known in this regard, but is FAR from the only author guilty of
publishing example code that can't be considered exemplary.
The basic fact is that being an excellent (or even superb) technical
writer doesn't necessarily mean one is an excellent (or even fair)
coder, and vice versa.  Herbert Schildt is a very good author who writes
rather poor code.
One other point worth noting is that many people who write about
programming primarily for PCs started writing about Turbo Pascal years
ago, and have simply switched to C and C++ when it became more popular.
Turbo Pascal has never made any attempt at conforming with any stardard
but itself.  People who grew up with it often tend to view whatever
compiler they happen to use as the ONLY standard.  The situation with C
is entirely different than with Turbo Pascal, but many authors have
never bothered quite caught onto that.
    Later,
    Jerry.
... The Universe is a figment of its own imagination.
--- PPoint 1.90
 * Origin: Point Pointedly Pointless (1:128/166.5)
---------------

FIDO MESSAGE AREA==> TOPIC: 203 C++           Ref: E5X00004 Date: 05/27/97
From: FRANK MASINGILL                                       Time: 04:18pm
\/To: CLIFF RHODES                                        (Read 3 times)
Subj: Textfile to another

Hi Cliff:
    Would you, (or anybody else) critique this and tell me if I should be 
proud of my progress?
//copyfil2.cpp
#include <fstream.h>
#include <process.h>
void main(int argc, char *argv[])
{
    if(argc != 3)
    {
        cerr << "\nUse Arguments";
        exit(1);
    }
    char ch;
    ifstream infile; ofstream outfile;
    infile.open(argv[1]);             // I know I should stick in cerr
    outfile.open(argv[2]);            // on both of these calls.
    while(infile.get(ch) != 0)
    {
            outfile.put(ch);
    }
}
    //-------------------------------------------------------------
It compiles and copies one text file to another.
If this is correct, my next project is to try to process each line
in such a way that I can delete it ' i.e. NOT write the line to the
destination text file.  Or else designate a block of lines to skip
over.
    Any comments will be appreciated.  The enormous array of choices in 
dealing with streams in C++ is a little confusing as I am doing it without 
having learned C very much.
                            Sincerely,
                                            Frank
--- FMail/386 1.02
 * Origin: Maybe in 5,000 years   frankmas@juno.com (1:396/45.12)
---------------

FIDO MESSAGE AREA==> TOPIC: 203 C++           Ref: E5X00005 Date: 05/27/97
From: PAUL WANKADIA                                         Time: 09:25pm
\/To: ALL                                                 (Read 3 times)
Subj: DJGPP, gcc et al

Having discovered the joys of '--oformat binary', I can now get myself a
binary image when I compile.  Unfortunately, I now get a strange byte thrown
into my code, namely 0x66.  According to one of the files with Ralfie's list,
it's some kind of prefix for 386+ to specify memory-size or something.  Does
anyone know how to get rid of it?  It doesn't seem to appear in code that gcc
generates...  TIA.
--- PPoint 2.00
 * Origin: Junyer's Workshop (3:640/772.3)
---------------

FIDO MESSAGE AREA==> TOPIC: 203 C++           Ref: E5X00006 Date: 05/28/97
From: SADOVNIKOV SERGEY                                     Time: 01:44am
\/To: PAUL DRUGGIT                                        (Read 3 times)
Subj: passing structures to functions

 p  28 1997, 01:28. , p,   㬠 ⯨ Vadim. ⯨ᠫ.
c  25 1997 05:50, Vadim Davydoff ⯨ᠫ  Paul Druggitt:
 PD>> Now, is it possible to write a single function that will
 PD>> accept ANY structure as a parameter, stating which member to
 PD>> compare?
 VD> According to the EchoTag, we are talking about C++, right?
 VD> Simply use a base class with the only data member as a type
 VD> identifier.
Another example (if I understood correct):
 VD> class CBase
 VD>   {
 VD>   public:
        virtual int CompareFunction(CBase&)
        {
           ...
        }
        int ObjectId;
 VD>   };
 VD> Then, derive all your other classes from it just like:
  class CBig1 : public CBase
  {
   public:
          CBig1 () {ObjectId = 1;}
          ....
          int CompareFunction(CBase&);
   };
  class CBig2 : public CBase
  {
   public:
     CBig2 () {ObjectId = 2;}
     int CompareFunction(CBase&);
   };
  Use a reference to the CBase as your function paramter. Function
  will check the parameters for the same type and to comaring it (for 
example).
   void Function(CBase& Obj1,CBase& Obj2)
   {
      int CompareResult;
      .....
      if(Obj1 . ObjectId == Obj2 . ObjectId)
         CompareResult = Obj1 . CompareFunction(Obj2);
      .....
   }
    Read the Biarn Straustrupp C++ Programming (second edition) chapter
"Templates and Containers". He show about ways how to do it. Here one of 
m.
                                                           Commander Wolf
᫨ pp  襫  p p 訡  pp, 
     ⥬y ppy,   訡  pp.
--- 2.50+
 * Origin: *) Commander Wolf (*  Moscow, Russia (2:5020/760.14)
---------------

FIDO MESSAGE AREA==> TOPIC: 203 C++           Ref: E5X00007 Date: 05/27/97
From: CLIFF RHODES                                          Time: 01:19pm
\/To: FRANK MASINGILL                                     (Read 3 times)
Subj: int main()

--> Frank Masingill wrote to Cliff Rhodes <--
 
FM> > Frank, please use int main(void) !!!!
 
FM>But WHY do the books I'm
FM>following not use it?  They are some of the most promient
FM>names like Lafore, etc.  I'm not implying that means they
FM>are right - just asking why you make a point of it?
 
I wish I knew why capable authors used void main(). The only reason I
can think of is that it will compile and they do not think it
necessary to return a completion code to the system.
 
ANSI/ISO C specifies that when running under an Operation System (they
call it a hosted environment), not returning a value results in
undefined behavior. In fact only two forms of main() are specified:
 
int main();
int main(int argc, char *argv[]);
 
C++ is similar in that the above two forms of main() must be 
supported. void main() is not specified, but may be allowed in an 
implementation.
It is a simple thing to return a value from main(), so I cannot
understand why it is not always done. It's not the end of the world if
you don't, but it is a good habit to get into.
 
Cliff Rhodes
cliff.rhodes@juge.com
 
X CMPQwk 1.42 1692 X"None love, but they who wish to love." - Jean Rac
--- Maximus/2 3.01
 * Origin: COMM Port OS/2 juge.com 204.89.247.1 (281) 980-9671 (1:106/2000)
---------------

FIDO MESSAGE AREA==> TOPIC: 203 C++           Ref: E5X00008 Date: 05/27/97
From: CLIFF RHODES                                          Time: 11:07pm
\/To: FRANK MASINGILL                                     (Read 3 times)
Subj: IO streams

--> Frank Masingill wrote to Cliff Rhodes <--
FM>void main(int argc, char *argv[])
// Ahem, int main(...)
FM>{
FM>    if(argc != 3)
FM>    {
FM>        cerr << "\nUse Arguments";
FM>        exit(1);
FM>    }
FM>    char ch;
FM>    ifstream infile; ofstream outfile;
FM>    infile.open(argv[1]);             // I know I should stick in
FM>    cerr outfile.open(argv[2]);            // on both of these
FM>    calls. while(infile.get(ch) != 0)
FM>    {
FM>            outfile.put(ch);
FM>    }
  return 0;
FM>}
Looks good to me! It could use some error checking to make sure files 
are opened as expected. Also, you could use fstream constructors to 
open your files instead of the open() member.
ifstream infile(argv[1]);  // Constructor opens file argv[1]
 
FM>If this is correct, my next project is to try to process each line
FM>in such a way that I can delete it ' i.e. NOT write the line to the
FM>destination text file.  Or else designate a block of lines to skip
FM>over.
You probably won't want to use the get() and put() members to do that.
FM>    Any comments will be appreciated.  The enormous array
FM>of choices in dealing with streams in C++ is a little
FM>confusing as I am doing it without having learned C very
FM>much.
Since C++ streams are different from C I/O, you aren't at too much of 
a handicap. Don't feel bad about it, streams are confusing to 
everybody since they are so flexible.
Cliff Rhodes
cliff.rhodes@juge.com
X CMPQwk 1.42 1692 X"Divide and rule." - Latin Proverb
--- Maximus/2 3.01
 * Origin: COMM Port OS/2 juge.com 204.89.247.1 (281) 980-9671 (1:106/2000)