--------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECE00003 Date: 08/10/97 From: KURT KUZBA Time: 05:34am \/To: MATTHEW DUHART (Read 3 times) Subj: Problem with initgraph MD> The errors always have to do with stuff like initgraph, MD> setcolor, lineto, moveto, etc. Borland .BGI files are designed to be used as dynamic linking libraries. Your program must name the proper .BGI file and know where to find it. If you wish for your .BGI file to use static linking, then you must use the BGI2OBJ.EXE program to produce a linkable object, which may then be included in a project or a .LIB called by your program when it is compiled. When you register your .BGI library for dynamic linking, you need to use the full path and library names. > ] I'm heavily sedated and seriously thinking about blinking... --- * Origin: *YOPS ]I[* 3.1 GIG * RA/FD/FE RADist * Milwaukee, WI (1:154/750) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECE00004 Date: 08/10/97 From: JOSH JACKSON Time: 12:12am \/To: RAJESH DHAWAN (Read 3 times) Subj: Mpython They are the knights that say neep! not nee. --- SuperBBS 1.17-3 (Reg) * Origin: The Richwood BBS, SuperBBS Support/Reg, (409)265-3828 (1:3812/10) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECE00005 Date: 08/09/97 From: CHRIS DOWNS Time: 06:20pm \/To: NEIL HELLER (Read 3 times) Subj: Re: DATABASE STUFF CD> A lot of the "extra capabilities" from ODBC flow from its design CD> goal of portability across as many DBMSs as possible..... NH> Does that mean that ONE ODBC driver could (theoretically) be used to NH> interrogate databases from several different vendors (Oracle, IBM, M$, NH> etc)? No, as I'm sure you know, the goal is the opposite: to be able to access different DBMSs using different ODBC drivers. The theory is that all you need to do is write one program to do your db stuff. Then if you use a different backend, just use a different data source name that maps to the driver appropriate for the new db. This does work pretty well as long as what you are doing with the db is _extremely_simple_. But even fairly simple stuff (like subqueries) that is standard SQL won't execute across popular micro db platforms. (Or at least won't execute properly with the ODBC drivers available for the db's.) Not only that, but some ways to access the db are excrutiatingly slow with one construct, but quite efficient with another. (Part of this is a flaw in SQL design which allows a multiple of equivalent ways to do something rather than one way which can be consistently optimized.) One other problem is that there's often a lot you have to do with db's that isn't part of SQL. One nice feature of ODBC is that you can access any vendor specific components you need. But naturally vendor spedific stuff is vendor specific. So much like porting C code across platforms, "writing to the standard" is a very small piece (an insignificant piece?!?) of the work needed to port code to new databases. Instead you have a lot of hard work testing all you program paths to make sure that stuf that's "supposed to work" really does work. --- Blue Wave/QWK v2.12 * Origin: St. Louis Users Group (1:100/4) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECE00006 Date: 08/09/97 From: CHRIS DOWNS Time: 06:20pm \/To: JAVIER KOHEN (Read 3 times) Subj: Re: inline const; JK> Why would BC++ 4.51 *sometimes* compile JK> inline int SomeClass:someFunc(void) const; JK> fine, but the linker won't find the "symbol". Either you've got no implementation of the function (where is the code SomeClass::someFunc()?) or BC is can't handle inline functions that are defined in one translation unit and declared in a different one. --- Blue Wave/QWK v2.12 * Origin: St. Louis Users Group (1:100/4) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECE00007 Date: 08/09/97 From: CHRIS DOWNS Time: 06:20pm \/To: NEIL HELLER (Read 3 times) Subj: Re: Printing pointer valu NH> Given the following code: NH> char aStr[10] = "abcdefgh"; NH> char * aPtr = &aStr[5]; NH> cout << aPtr << endl; NH> The output is garbage. How does one correct print the value of a NH> pointer? To print the _value_of_the_pointer_, cast the pointer to a void* cout << (void*)aPtr; //generates something like 0x5423:3212 But I don't understand why your code prints "garbage". It ought to output: fgh --- Blue Wave/QWK v2.12 * Origin: St. Louis Users Group (1:100/4) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECE00008 Date: 08/10/97 From: DARIN MCBRIDE Time: 08:09am \/To: GERRY DANEN (Read 3 times) Subj: C++ or ASM? -=> Quoting Gerry Danen to Darin Mcbride DM> Nope. The const_cast<> is _removing_ const (since there isn't a const DM> in the "brackets" (<>)). The static_cast<> is doing nothing about DM> static - it's saying that we're not going to do a runtime check, but a DM> compile time check to change the volatile void* to volatile char*. GD> I've never used volatile on any direct screen I/O. Perhaps that's GD> because under single-tasking DOS that's not a problem. In what way GD> would I see problems under multi-tasking OS like WinNT or OS/2? Something tells me you just wanted the answer to the other question, but had to keep it on topic. That's ok - I'm not the moderator, and thus the moderator isn't so anal that he'd care. :-) [There's an implication in there somewhere... ] Anyway, you would use volatile under DOS for global variables that are modified by interrupts, or anything else modified by interrupts for that matter. For example, if you had an interrupt that changed a global stack to add each new character that came in from a modem, anything dealing with the stack would have to be considered volatile (in OS/2 or NT, you would use semaphores to guarantee the variable didn't change between accesses). Another one would be, say a pointer to the incoming byte of a serial port - this would be volatile as well. OS/2 and WinNT have semaphores that render volatile mostly useless. Only your own process threads can modify your variables, and all these variables can be protected by semaphores. If they aren't so protected, you run into race conditions that can make the system blow up. ;-) Same for DOS, but you don't have as much power over it, so you use the volatile. (The screen isn't going to change, so having a volatile pointer to it is useless... unless you have an interrupt handler also modifying it.) GD> BTW, you got internet e-mail and/or fido node yet? Internet: dmcbride@ibm.net Fido: Keep an eye on the nodelist. I'll have my BBS line this Friday and apply for Fido shortly thereafter. So I should have a Fido node number within two weeks. And then I'll be posting from my own system shortly after that. :-) ... Programmers don't get sniffles, they get a CODE. --- FastEcho 1.46 * Origin: House of Fire BBS - Toronto - (416)601-0085 - v.34 (1:250/536) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECE00009 Date: 08/09/97 From: LEIGH MORRESI Time: 09:54pm \/To: ALL (Read 3 times) Subj: WATCOM and C++ g'day all! hey!, ive got WATCOM V11.0, and wondering how do you do simple inline assembly, without the use of confusing pragma's a stuff?? i mean, is it possible todo it like borlands C?, ie asm; { lalalalal }; ???? thanxs! --- 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: ECE00010 Date: 08/09/97 From: FRANK ADAM Time: 11:36am \/To: MATTHEW DUHART (Read 3 times) Subj: Problem with initgraph On Aug 05 09:50, 1997, MATTHEW DUHART of 1:307/8 wrote: G'day MATTHEW, MD> Hi, I seem to be having !ymany many many errors with Turbo C++. I MD> entered a program out of a book, checked it over many times, had other MD> people check it over, and compiled it. I always get 1 warning and 5 Switch on "include graphics library" or something like that in compiler options. Alternatively, create a new project, add the source, add graphics.lib from your bc\lib directory. Build all. Regards, Frank --- Msged 4.00 * Origin: The ticking point, Melbourne, Australia. (3:635/728.21) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECE00011 Date: 08/07/97 From: JAVIER KOHEN Time: 08:21pm \/To: RAJESH DHAWAN (Read 3 times) Subj: Please help me On 31-Jul-97, Rajesh Dhawan wrote to Javier Kohen about Please help me. JK>> RD> Break your source code into graph.c & graph.h. JK>> RD> Put all your function prototypes (declarations) in graph.h RD> ^^^^^^^^^^^^ JK>> RD> along with all global variables that you want to use in later ^^^^^^^^^^^^^^^^ JK>> RD> programs. JK>> JK>> You shouldn't define anything in the header files, just declarations are JK>> allowed. RD> Who said anything about defining ?? You shouldn't define global variables definitions in the header file. RD> I think your message was meant for Dave Boyd and not for me. Nope. Javier Kohen [The_Crusher] http://jkohen.base.org ... En la esquina voy a vomitar y al que pase voy a salpicar! Flema -!- CrusherTag 0.3.2. --- Terminate 4.00/Pro * Origin: The King of The Ring (4:900/748.3) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECE00012 Date: 08/07/97 From: JAVIER KOHEN Time: 08:36pm \/To: CAMERON CLARK (Read 3 times) Subj: Re: Classes On 31-Jul-97, Cameron Clark wrote to Javier Kohen about Re: Classes. JK>> #define FALSE (0 == 1) JK>> #define TRUE (!FALSE) CC> Why couldn't that be done as part of the language? It is, but my compiler didn't yet support it to the version I have (BC++ 4.51). Javier Kohen [The_Crusher] http://jkohen.base.org ... Four more. None survived. Worf -!- CrusherTag 0.3.2. --- Terminate 4.00/Pro * Origin: The King of The Ring (4:900/748.3)