--------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: E4H00002 Date: 04/10/97 From: KEVIN SHEETZ Time: 08:40pm \/To: CLIFF RHODES (Read 5 times) Subj: Oop Thanks for the help. I was wondering if you could help me with somthing else. I have been playing with c++ for several months now. I decidied not to write a program in c++ but instead I wrote it in basic. Is there an easy way to import this into a C++ enviroment? I taught myself basic, but the commands to open and save to a disk are to complex for me to understand in basic. I think it might be easier to rewrite it in C++. What do you think. I am not using an graphics mode. Since you are so "all knowing" do you know how to use file accessing in Basic. Maybe the pricipals are the same as C++. Most of the time you go forward on an evolution tree, this time I am willing to go backwards. Since C++ came from C which in turn came from Basic. On last question. Where would a good place to take a class in C++ by mail be from? I don't have a diplomia YET. Thanks Kevin Sheetz --- PCBoard (R) v15.3/M 5 * Origin: The Computer Nut BBS, Elkhart,IN (1:2285/80) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: E4H00003 Date: 04/10/97 From: KEVIN SHEETZ Time: 11:34pm \/To: ALL (Read 5 times) Subj: Oop @1:106/2000 CR>--> Kevin Sheetz wrote to All <-- CR> CR>KS>What the heck is object orientated programing? CR>KS>Can anyone explain in English? CR> CR>The answer to the second question is no. :-) CR> CR>It's not easy to give a totally satisfactory answer without using CR>some new terms that seem confusing. I will try to give you a short CR>and understandable, but by no means complete, answer. CR> CR>Any system can be viewed either by looking at the things involved or CR>the processes involved. Procedural languages and design (for instance CR>using C) concentrate on the processes and algorithms. A collection of CR>functions is created to perform various operations. CR> CR>In object oriented programming, the things themselves are of CR>interest. These are the objects. An object is just some entity that CR>has well defined behavior. Objects do things when one of their member CR>functions is called. CR> CR>Object oriented programming deals with the behavior and interaction CR>of objects. New objects can contain other objects or inherit directly CR>the features of other objects. CR> CR>Here's a simple example of the difference between OOP and procedural CR>languages. I won't discuss the mechanisms involved, but will just CR>tell you what happens. CR> CR>Suppose you are writing a program that needs to display objects of CR>different shapes on the screen. In a procedural language you would CR>write a routine to draw a line, a circle, an oval, a rectangle, etc. CR>Then to display say, a circle, you would call the circle routine with CR>the correct center and radius. To display a rectangle, you call the CR>rectangle routine with the correct parameters. CR> CR>In an OOP drawing program, you would have a base object, call it CR>Figure, from which objects for the various shapes would be derived. CR>To display the proper shape on the display, you might only need to CR>call the Draw() member function of Figure. Figure->Draw(); The object CR>knows what shape it is and how to draw itself! CR> CR>So, instead of calling a particular procedure to display a certain CR>shape, you tell a shape object to draw itself. The result is you can CR>pass around shapes without having to worry about any particular CR>one--the object knows what type it is. CR> CR>KS>What the heck is the differnce between C and C++? CR> CR>C is a procedural language. You write applications by creating a CR>number of functions to do certain operations on data. CR> CR>C++ is an enhanced C with many new capabilities that support object CR>oriented programming. In specific terms, C++ supports classes, CR>encapsulation, polymorphism, inheritance, data abstraction, CR>overloading, and other OOP goodies. CR> CR>X CMPQwk 1.42 1692 X"Every definition is dangerous." - Erasmus CR>--- Maximus/2 3.01 CR> * Origin: COMM Port OS/2 juge.com 204.89.247.1 (281) 980-9671 CR>(1:106/2000) Could you tell me how to read and write data from a disk and what the heck I am doing wrong with this program. It is in basic but most of the commands are backwards compatible. Imagine that! --- CMPQwk #1.42 UNREGISTERED EVALUATION COPY * Origin: The Computer Nut BBS, Elkhart,IN (1:2285/80) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: E4H00004 Date: 04/11/97 From: DARIN MCBRIDE Time: 04:26pm \/To: CHRISTIAN ANDERSEN (Read 5 times) Subj: Direct Acces to API JC> Chase "RAD" that's fashionable this month, and whatever becomes CA> Let's not forget what RAD means: Rapid Application CA> Development. Why is it, that a RAD tool absolutely have CA> to wrap the code into a beefed up drag'n drop CA> userinterface? Everybody knows that, the most time, in Why? Because it's more object-oriented that way. :-) CA> a programming project is spend with some problems CA> concerning, usually, very few lines of code, that just CA> /wont/ behave. It is not the userinterface design, that eats your time. So far for me it has been. :-) CA> For me MFC was the natural RAD tool, not in spite of, CA> but because, it is a relatively thin wrapper around the CA> API code. Almost everything I know from API programming Sure, that has its advantages. But is it really "good"? It's definately not OO (well not OO-enough for me anyway) if it encourages you to avoid its own methods in favour of using the actual Win API. OTOH, the "thinness" of the wrapper easily makes a much easier learning curve... --- Maximus/2 3.01 * Origin: Tanktalus' Tower BBS (PVT) (1:342/708) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: E4H00005 Date: 04/11/97 From: RON BASS Time: 06:24pm \/To: JERRY COFFIN (Read 5 times) Subj: Re: Multithreading member-functions Hello Jerry! JC> Hi Ron, it's been a while... True. But I still lurk... RB> IIRC, the draft standard specifies that RTTI is only available for RB> classes that have at least one virtual function. If so, it's fairly RB> clear that the compiler only has to go to the memory JC> pointed to by the RB> original void pointer, look at the "standard" offset JC> in the (presumed) RB> object for the vtable pointer, and then determine if the data at that RB> offset is a pointer that points to a true vtable. JC> The problem is that if the pointer isn't to the right kind of class at JC> all in the first place. If the compiler attempts to dereference it, JC> that could produce all sorts of problems all by itself. I assume that you are refering to the fact that not all addresses are valid? Seems to me that if dereferencing what "ought" to be the vtable pointer causes a processor exception, dynamic_cast should be able to catch the exception and return a NULL pointer. Implementation details are left to the compiler/library writer. JC> Worse, how can it determine whether or not what's pointed at is a true JC> vtable or not? If it's not, the code has to give a NULL pointer. The model that I have in my mind is that the vtable is really a static data member of the class, initialized either before main()/WinMain() is entered, or possibly the first time a constructor is called for an object of the class, or for an object of a class derived from the class. Consequently, its address (the value of the vtable pointer) can be used by the compiler in just the same way as the address of any static data item. IIRC, the model suggested by Soustrup(sp?) in "Design and Evolution" is that a derived class's vtable would include a pointer to its parent's vtable (let's not get into the MI can of worms here) at a fixed offset, so all that dynamic_cast has to do is to track through the linked list to see if it can get from the object to a vtable pointer that is equal to the value for the class that the cast is for. Again, if it comes to a NULL (indicating the base class for which virtual functions were declared) or dereferencing one of the pointers causes a processor exception, dynamic_cast just returns a NULL. JC> However, anything it has in memory that it uses to identify a vtable, I JC> can (accidentally or otherwise) have in memory otherwise as well, and my JC> pointer will be mis-identified as a pointer to a class, even though it's JC> not. I'm not sure the systen tries that hard to be completely certain. My gut reaction that this is a source of potential run-time bugs waiting to bite... I'll have to take a snoop through the Microsoft RTL, to see if there is any indication of how they implement this sort of thing. JC> The only way I can see to be absolutely certain about this is to always JC> keep a table of all objects that have been created, and search for the JC> passed pointer in that table. Offhand, this sounds slow and memory JC> hungry at best... I agree! ttfn -Ron (rbass@intersecttech.com) --- EZPoint V2.2 * Origin: There's a point here, somewhere... (1:128/13.3) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: E4H00006 Date: 04/12/97 From: ANTHONY SALTER Time: 06:50am \/To: ALL (Read 5 times) Subj: C++ Game Programming Was just wondering if any of you out there knew of any good shareware/freeware game libraries for C++. I'm using Turbo C++ 3.0 right now, and have been programming for a little while, but I'd really like to start making some games. Also, if anyone has a book they'd like to recommend, I'd be very grateful. Badman --- Maximus 2.02 * Origin: Crossroads BBS * Round Rock TX * (1:382/506) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: E4H00007 Date: 04/12/97 From: NICK SHREDERS Time: 01:38am \/To: PIERRE PHANEUF (Read 5 times) Subj: Re: DJGPP OPTIMIZATIONS NS> Whenever I compile my Linux kernel with GCC I notice a slight NS> performance increase when i compile it with the PENTIUM option in the NS> config, rather then the 486 (I have a 486). PP> Really? Would you actually recommend this? What I recomend is doing what Linux was made for - experimenting with it to see whats best fit for your system. --- Telegard v3.02/mL * Origin: Kitchen Sink * Lawrence, KS * 913-749-9480 (1:299/122) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: E4H00008 Date: 04/12/97 From: NICK SHREDERS Time: 01:41am \/To: HERMAN SCHONFELD (Read 5 times) Subj: Re: DJGPP optimizations HS> It doesn't seem to work. When i try running "gprof tex.exe | more" it HS> returns with an error message "unrecognized file format". HS> I have compiled correctly with -pg and no -fomit-frame-pointer. HS> (they're incompatible). Did you compile without the -s ? HS> I tried running "gprof tex.o |more" and it dumped a whole lot of HS> directives on the screen (as if i were to type gprof /? etc). Lets try this again :) After compile, run your newly compiled program. This should dump out a file. then run gprof via > a (redirect to file a) or perhaps | more I havnt tried piping it to more though. --- Telegard v3.02/mL * Origin: Kitchen Sink * Lawrence, KS * 913-749-9480 (1:299/122) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: E4H00009 Date: 04/12/97 From: FRANK MASINGILL Time: 11:07am \/To: SHAUN FARRUGIA (Read 5 times) Subj: C++ and Object Oriented Progging w3rd.. > The difference between C and C++ is that C++ is Object Oriented > whereas C is pretty much procedural. There are other > differences between the languages such as iostreaming which > makes Input/Output alot easier and more Functional. > This is my first post and dont be an ass if youre a guru :)... I'm NOT a guru. Can't even call myself a programmer but I'd like to take this opportunity to pay tribute to the authors who have written good, explanatory books on C++. I have committed myself to learning it this year and fortunately came across a discounted copy of the EXCELLENT book by Borland employee, Michael Hyman, one of those generous REAL programmers with interest and sympathy for learners (some others exist here on this and the C_echo) Mr. Hyman's book gave me my final commitment to learn C++. For the first time in a C style language I saw a profesional naming his variables with such symbols as "FirstName" or "DesiredObject" which has always been a tendency I had in learning in any computer langauge. His book, _Borland C++ for Dummies_ is one of the IDG books but is FAR superior to any of the Dummies books I have on programming and I have a few. Fortunately it only set me back ten bucks but is worth MUCH more than that. I hope to locate an address for him some day to thank him. He WAS an employee of Borland but I don't know if he still is today. I happen to have an old Borland C++ compiler and do not need to be concerned with portability as I only do it as a personal hobby. 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: E4H00010 Date: 04/08/97 From: KEVIN CAMPBELL Time: 08:55pm \/To: ALL (Read 5 times) Subj: Keyboard handling in DOS. Can anyone direct me to a good set of docs on programming the keyboard under DOS? I was hoping to avoid using the Bios functions and write my own handler, but it seems that in intermixing C code with the handler I have it fails to work. Thanks - Kev --- FMail/386 1.02 * Origin: Mail shipped from Deimos Spaceport (2:259/17) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: E4H00011 Date: 04/08/97 From: PAUL MADDOX Time: 04:38pm \/To: FRANK MASINGILL (Read 5 times) Subj: Rating of C++ Frank, FM> This view is shared by the designers of C++. Nevertheless, FM> C++ has enough OOP extensions to meke it quite useful in FM> modeling objects...." Sounds VERY strange to me! :-) In fact, I'd almost say "rubbish". FM> Am I wasting my time - even if it IS only a hobby with FM> no purpose to make a career of it (I'm too old). In the words of MANY people "C++ is a real programmer's language" I say "amen". :-) If you want to program a game, don't even THINK of doing it in Pascal, there are about 2 people worldwide who write games in Pascal, and they're thinking about moving to C/C++.. ;-) Nearly ALL examples out there regarding games programming are in C/C++ with a little ASM.. So, in my opinion, if you want to write games, or get any kind of user support, program in C++! :-) TTFN - Paul. --- cPoint 2.17 * Origin: Nowhere, man. (paul.maddox@zetnet.co.uk) (2:250/102.23)