--------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: EBV00017 Date: 07/25/97 From: HERBERT BUSHONG Time: 04:39am \/To: CHRISTIAN S. PEDERSEN (Read 3 times) Subj: Conversion of pointer. ::> Behold, a function which returns a pointer: The function has a problem though; the variable scope is local to the function, and whose contents are only "valid" until the function returns. After that, the memory location may be used for something else... One solution would be o make the variable static. ::> int* test() ::> { ::> int i=5; ::> return &i; ::> } ::> Why do I get a "Suspicious pointer conversion"-warning ? The functions si ::> this concept seems to work OK. Should I make them differently. Try parenthesis. int *test(void) { static int = 5; return (&i); } # Herbert Bushong harchon@centuryinter.net [TEAM OS/2] - Blackbeard's BBS Intelec: 239:600/0 + Fido: 1:19/19 http://www.intelec.com/software/ --- RM 1.31 2508 Friday the 13th Part LCMXXIV : Jason Meets Spock * Origin: Blackbeard's BBS - Ville Platte, LA - 318-468-3385 (1:19/19) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: EBV00018 Date: 07/25/97 From: HERBERT BUSHONG Time: 04:39am \/To: CHRISTIAN S. PEDERSEN (Read 3 times) Subj: Mutually class definition ::> I want to define two classes like the following: /* you need a forward declaration of class B */ class B; ::> class A ::> { ::> A(int a) { }; ::> B func1() { return B(1); }; ::> } ::> class B ::> { ::> B(int a) { }; ::> A func2() { return A(1); }; ::> } ::> two classes which each contains a function which return a instance of the ::> class. I get a "typename expected"-error in class A. I believe I have to ::> the "typename" keyword, but I can't get it to work. Add the forward declaration before class A, so that it knows there *is* a class B... # Herbert Bushong harchon@centuryinter.net [TEAM OS/2] - Blackbeard's BBS Intelec: 239:600/0 + Fido: 1:19/19 http://www.intelec.com/software/ --- RM 1.31 2508 Taglines are like cats. You just THINK they're yours. * Origin: Blackbeard's BBS - Ville Platte, LA - 318-468-3385 (1:19/19) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: EBW00000 Date: 07/26/97 From: ASHER DENSMORE-LYNN Time: 10:06am \/To: DARIN MCBRIDE (Read 3 times) Subj: Sunir ventures into C++ 25 Jul 97 18:36, Darin Mcbride wrote to Asher Densmore-Lynn: DM> Yech. No, this feature was added exactly FOR readability. By placing DM> variables close to code, it makes both easier to understand. The DM> human mind can only keep track of 7 +/- 2 things at a time. By DM> putting all 537 variables at the top of your function, you make it DM> hard to follow. However, by putting the variables close to where DM> they're used, the reader is more likely to be able to understand what DM> a variable's job is because there is less to remember at a time. Excuse me, but the human mind can only keep track of 7 +/- 2 things at a time. What the heck are -you- doing with a function with 537 variables?! (537 -constants- are another story -- those are -supposed- to be forgettable, like math constants. But if you're using 537 variables, it's time to quit using BASIC. d: (: Ideally, no function should -need- more than ten to fifteen variables or so -- if it requires greater complexity, break -that- down into functions, and then inline them if you must.) (Remember I said 'ideally' -- and that there are exceptions, and good ones. No need to post 2E8 optimized functions with 11 vars...) AD>> Think your functions through before you set hand to keyboard -- AD>> you really should know the vars you'll need before you do AD>> anything more than prototype it. DM> Except when debugging... I generally debug -after- I prototype, myself. If you're that good, I know a couple of local companies that'd -love- to have you. d: (: Asher Densmore-Lynn ... Doing it the hard way is always easier. --- Squish v1.11 * Origin: Phaenix Rampant, 'Uhm... I hit it again!' (1:130/115) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: EBW00001 Date: 07/26/97 From: DARIN MCBRIDE Time: 07:56pm \/To: THOMAS MAEDER (Read 3 times) Subj: template hell? -=> Quoting Thomas Maeder to Darin McBride DM> TM> Download a public STL. You can learn a lot about using template DM> TM> looking at the code. DM> However, what you're more likely to get by looking at the code is a TM> Ok. The STL is well enough documented to use it without understanding TM> every line of code. But I'm not only a software developer, but also a TM> C++ teacher, so I think that I have to understand the STL code. I disagree. You merely need to know how to use it, not how it works. The same goes whether you're using strcpy, scanf, list<>, or say some third-party library. I have never seen a professor explain the intricate insides of iostreams (i.e., cout) but, rather, only explain how to use it. The reason? I'd like to think it's because the insides don't actually matter. However, it's more likely to do with the fact that you _aren't supposed to know_. This is due to the fact that no two implementations are necessarily implemented the same way. For example, the current implementation of the STL is incomplete - because no compiler could handle default template arguments. (I'm not sure if this is still true.) Nevermind that GNU's version has been hacked from the original HP release. Or that MS has probably made a few modifications to get it to work (properly) on MSVC. Or that Borland made a few modifications. Or that... you get the idea. Do you understand all the C runtime library functions' code? Some of it is surely quite straight-forward. But it's useless to know it since you change compilers and your knowledge is obsolescant! ... On the other hand, I have five fingers. --- FastEcho 1.46 * Origin: House of Fire BBS - Toronto - (416)601-0085 - v.34 (1:250/536) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: EBW00002 Date: 07/25/97 From: CAREY BLOODWORTH Time: 09:19pm \/To: CHRISTIAN S. PEDERSEN (Read 3 times) Subj: Conversion of pointer. CSP>Why do I get a "Suspicious pointer conversion"-warning ? The functions usin CSP>this concept seems to work OK. Should I make them differently. Most likely because you are returning a pointer to local, auto storage. As soon as you leave that function, what the pointer points to is going to disappear. --- QScan/PCB v1.19b / 01-0162 * Origin: Jackalope Junction 501-785-5381 Ft Smith AR (1:3822/1) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: EBW00003 Date: 07/25/97 From: CHRIS DOWNS Time: 06:11pm \/To: ASHER DENSMORE-LYNN (Read 3 times) Subj: Re: Sunir ventures into C SS>> I hate five major things about C++ so far: SS>> /* 2. Declaring data in random places */ SS>> int HiIAmRandomlyDeclaredHere; BP> Another thing I did never forgive in C. I write my code. I need an BP> additional local. Why on earth I have to go up, search start of the BP> block and insert it there instead of putting it right there? AD> Code readability, and it makes it easier on the compiler, but the AD> first one is the real one. Nothing but code readability. I programmed AD> in BASIC for much too long; it was very painful to convert to C, but AD> once I managed, I was okay. AD> Notice that a lot of Sunir's complaints are just what the compiler AD> ALLOWS -- things that are bad coding practice. I agree; if I'm looking AD> at your code, I don't want to have to wade around, looking for random AD> declarations. To each his own. I find that declaring variables as closely as possible to where they are used _enhances_ "readability". (Besides the potenial increase in program reliability via restriciting visibility.) If the definition and the code are right there on the screen, then which style of code forces the programmer to "wade around"??? In either case, the "problem" is easily solved with a better set of tools. With an adequate set of tools, any variable is just one keystroke away. But I suppose that restrictive (though functionally useless) software standards could at least somewhat compensate for primitive tools. --- Blue Wave/QWK v2.12 * Origin: St. Louis Users Group (1:100/4) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: EBW00004 Date: 07/25/97 From: CHRIS DOWNS Time: 06:11pm \/To: CHRISTIAN S. PEDERSEN (Read 3 times) Subj: Re: Conversion of pointer CSP> Behold, a function which returns a pointer: CSP> int* test() CSP> { CSP> int i=5; CSP> return &i; CSP> } CSP> Why do I get a "Suspicious pointer conversion"-warning ? Whatever tool is issuing the warning is doing an excellent job of helping you. But the message kind of stinks. I would prefer something more along the lines of "soon to be out of scope address being returned". But a misleading warning is still better than no warning at all! What is the "lifspan" of 'i'. It's contents are only valid while 'i' exists. It no longer exists then the function returns. So if anyone tries to dereference the returned pointer, he may get back the right answer, the wrong answer, or the system may even crash and burn. CSP> The functions using this concept seems to work OK. That's the beauty of "undefined behavior". You can very well get "correct" results on some platforms. But even on your platform, I *know* I can make it fail. What's happening is that the address returned is (or rather was) on the stack. You had no intervening uses of the stack between the function call and the dereferening of the returned pointer. If you add some code which "clobbers the stack", you won't be getting the right answer. CSP> Should I make them differently. YES! The lifetime of the variable needs to match the lifetime of the pointer to the variable. Perhaps making i 'static' would be appropriate. --- Blue Wave/QWK v2.12 * Origin: St. Louis Users Group (1:100/4) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: EBW00005 Date: 07/25/97 From: CHRIS DOWNS Time: 06:11pm \/To: NEIL HELLER (Read 3 times) Subj: Re: DATABASE STUFF EW> I meant a preprocessor can be told to behave civilized, if it can, EW> I don't see a reason to leave SQL. NH> ODBC is a delivery system for sending SQL to databases. And a _whole_lot_ more! --- Blue Wave/QWK v2.12 * Origin: St. Louis Users Group (1:100/4) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: EBW00006 Date: 07/25/97 From: DAVID TORREZ Time: 07:02am \/To: ALL (Read 3 times) Subj: Been Away! Just caught up! 07:02:0007/25/97 I have been away from this echo for some time now, so I read through most of this echo tonight. I felt overwhelmed answering any questions with so many left to read. I am answering to those that stuck into my head and not Code specific. First on that comes to mind is the C++ is evil issues, *.* languages are better than C++. Bjarne Stroustup speaks out himself addressing many of these same responses, questions, etc. If you have Internet and WWW access check out this site, here is Bjarne's retaliations in person. They are on his HomePage... http://www.research.att.com/~bs/blast.html Second is Borland C++, speaking Win32 of course. At the recent BorCon (Borland Convention) someone aske about the future of OWL. Borland Rep said something to the tune of this: DIANE'S RESPONSE ---------------- 1) Be sure Borland hears about any shortcomings in C++Builder that prevent you from using that product for your OWL work. Borland already knows that the project manager needs to be stronger, and they plan to improve it in the next release. They want to make it easy for Borland C++ projects, including OWL projects, to move easily into C++Builder. 2) Borland is looking for a partner to take on OWL. MY ANALYSIS OF DIANE'S RESPONSE