--------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: EG^00006 Date: 12/29/97 From: BOB STOUT Time: 07:12am \/To: SIMON AVERY (Read 2 times) Subj: Pritty Lites... On , Simon Avery (2:255/90@fidonet) wrote: SA>> // put these here to save prototyping. JG> Seeing as this is the C echo may I suggest you use C comments only? > Too inelegant, and nit-picking since most compilers can handle them. Simon... "Most" isn't all. Sorry, but I have to agree with Jerry on this. It's not a really big issue nowadays, but it still compromises portability. Which is why you won't find any "//" comments in any of the SNIPPETS C files (only in the C++ files). > If it really bothers you I can knock you up a wee converter... There are already two in SNIPPETS - see COMMCONV.C or CMTCONVR.CPP. Only it isn't a "wee" project. First of all, you have to have a parser that fully understands the syntax and grammer of a standard C program, as well as the syntax of "//" comments. Think about it, what if "//" happens to occur within a string literal? What about continued multi-line comments, e.g. // This is a continued \ multi-line comment. \ Is it legal? New versions of the \ C and C++ standards will clear it up. \ Right now, some compilers allow it, others don't. puts("Oh, and you don't want to convert // in here"); > Yes, sorry. Neglected to check Ansi compliancy. peekb() etc are > Borland specific. As already noted, there are portable equivalents in SNIPPETS - see PCHWIO.*. --- QM v1.00 * Origin: MicroFirm : Down to the C in chips (1:106/2000.6) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: EG^00007 Date: 12/29/97 From: BOB STOUT Time: 07:37am \/To: KURT KUZBA (Read 2 times) Subj: WHAT DOES THIS WARNING ME On , Kurt Kuzba (1:154/750@fidonet) wrote: > Try writing > temp_uword = 60000; > as > temp_uword = 60000L; temp_uword = 60000U; /* More correct for an unsigned int */ --- QM v1.00 * Origin: MicroFirm : Down to the C in chips (1:106/2000.6) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: EG^00008 Date: 12/30/97 From: FRANK MASINGILL Time: 08:13am \/To: KURT KUZBA (Read 2 times) Subj: Which way is more C++? FM> Which of the two versions below is better in using classes? They both FM> yield exactly the same results: (Please include why) KK> Your subject is off-topic, but not your question. :) I assume you meant KK> to post this in C++? OOPS (no pun intended) sorry Kurt and moderator. I DID, indeed, intend to post this is C++. Being 77 has its disadvantages in more ways than one. Thanks for the answer anyhow, Kurt. Sincerely, Frank --- PPoint 2.05 * Origin: Maybe in 5,000 years - frankmas@juno.com (1:396/45.12) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: EG^00009 Date: 12/29/97 From: TIKA CARR Time: 08:47pm \/To: NEIL HELLER (Read 2 times) Subj: WHAT DOES THIS WARNING ME -=> Quoting Neil Heller to All <=- Let's see if I still remember how to "C" ;) NH> int temp_sword; NH> unsigned int temp_uword; I think I'd rather make both of these unsigned ints. NH> temp_uword = 60000; /* warning on this line */ ... NH> memcpy(&temp_sword,&temp_uword,2); NH> On the marked line above (/* warning on this line */) I get the NH> warning that "constant is long in function main()". This was written NH> and compiled with Turbo C++ 4.5. I looked at the explanation of this NH> this warning but it really didn't seem to apply. Can someone give me NH> an understandable explaination of this warning message? Additionally, NH> can someone give me an explaination that makes sense? First off, I tested this in a 16-bit OS, using Quick C 2.5, Power C 2.2, and Borland C++ 3.1 for Windows. None of the compilers gave an error. I would suggest writing memcpy() like this: memcpy(&temp_sword, &temp_uword, sizeof(temp_uword)); I've heard that some 32-bit compilers uses 32-bits (4 bytes) for integers where 16-bit compilers use 16-bits (2 bytes) for integers. If this is true, your problem may have been that the program was written with the assumption t was to be compiled with a 16-bit compiler, and you may be compiling it in a 32-bit compiler that uses 4 bytes for an integer instead of 2. This may be why your compiler is complaining. It is saying that temp_uword is a 32-bit number, and you were telling memcpy to only work with 16-bit numbers (2 bytes). Try using the sizeof() as I showed above and see if that helps. Using sizeof() will always insure that the compiler gets the correct size of an integer (or any other type). In detail, memcpy is: void *memcpy (void *dest, const void *src, size_t n); This means that memcpy thinks temp_uword is a constant (as the warning said t was). It also said that constant is a long, or at least, it must be omething larger than the 2 bytes you said was to go into the *dest (temp_sword). ince temp_uword was the const void *src, your compiler found the declaration for temp_uword and told you that's where the problem was (where the problem is really in your memcpy()). Sometimes compilers don't always highlight the eal problem, making bug-hunting a bit tricky. Whenever I get an error, I try to look at the other parts of the code to see what else could have triggered an error. Sometimes even ONE syntax error can clear up 7 or 8 other errors in the code. Hope this helps (and hope I got this right for once :) Tika ... You have reached tech support. Read the manual. Goodbye. ___ Blue Wave/DOS v2.30 --- QScan/PCB v1.17b / 01-0406 * Origin: Knight Moves - Rochester,NY 716-865-2106 (1:2613/313) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: EG^00010 Date: 12/30/97 From: MICHAEL MCGAVIN Time: 12:59pm \/To: FRANK MASINGILL (Read 2 times) Subj: Which way is more C++? Hi Frank, Frank Masingill was saying something to All about "Which way is more C++?": FM> Which of the two versions below is better in using classes? They FM> both yield exactly the same results: (Please include why) I haven't been using C/C++ for too long, so someone can correct me if I'm wrong. :-) If you put the entire function/message/method/whatever (I'll refer to it as a function) as part of the declaration within the class as you did in the first example, it's assumed to be inline. ie. Every time that function is called in the code, it doesn't actually call the function, it copies all the code into every part of the program where it's called. If you have a lot of code in it, and you call it lots, it's going to make the executable bigger although it could make it marginally faster. Usually I only use it for speedy one-off statements such as assignments and so on. As far as I'm aware, compilers are allowed to compile it as a normal function without telling you if it gets too complex. In your second example where you only had the header information in the class definition, it treats each function call as a standard function call. Hope this was some help. Catch ya later, Mike. email: zog@sans.vuw.ac.nz --- GoldEd 2.50 UNREG * Origin: DARK SKIES Astronomy -- Wgtn, NZ. +64-4-235-6887 (3:771/300.1701) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: EG^00011 Date: 12/27/97 From: ROGER SCUDDER Time: 11:49pm \/To: TORBJORN KRISTOFFERSEN (Read 2 times) Subj: problem Hello Torbjorn. 26 Dec 97 19:14, Torbjorn Kristoffersen wrote to All: TK> When I run this code and type in a string like : "hello" then the hexvalue TK> of "hello" is printed on my screen as "olleh". TK> int i; TK> char a[220]; TK> printf("Text: "); TK> gets(a); TK> for(i=0;i { TK> printf("%x",a[i]); TK> } That is strange... When I run the code and enter "hello" I get output 68656c6c6f, which is correct. Are you sure you did not write your for loop to count down from strlen(a) to 0 when you ran the code. You have it right above. :-) One thing, though. I want to steer you away from the gets function. You have wisely used a very large array size for a, but it is best to avoid the bounds problems of the gets function buy using fgets instead. For example, in the above code you would use... #define MAX_ARRAY_LEN 220 char a[MAX_ARRAY_LEN]; fgets( a, MAX_ARRAY_LEN, stdin ); This will allow no more than 219 characters plus the nul terminator to be copied to a. Roger ... 'If it ain't broke, you can probably still fix it.' - Tim Allen --- Msged 4.20 beta 2 * Origin: Hodge-Podge Support BBS, Upper Darby, Pennsylvania, USA (1:273/404@fidonet) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: EG^00012 Date: 12/29/97 From: NEIL HELLER Time: 07:29pm \/To: BILL BIRRELL (Read 2 times) Subj: HELP ;) BB> Finally, I hope this thread has not put anybody off using macros. Why not? On my last job I worked at debugging code written by someone who was in love with macros. Some of them were two to three pages of hard copy long. If I never see another macro again I won't shed a tear. * KWQ/2 1.2i * --- FLAME v1.1 * Origin: Port Chicago's Loading Dock - 510-676-5359 (1:161/204) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: EG^00013 Date: 12/27/97 From: ANDREY KUPRISHOV Time: 04:04pm \/To: SIMON ODELL (Read 2 times) Subj: 3D rotation + perspective Welcome, Simon! (Friday 19-12-1997 06:43), Brian McCloud wrote to Simon Odell: SO>> someone help me !!! i have been working on some primitive 3d routines, SO>> and rotating them is doing my head in !!! can anyone give me any hints SO>> on how the **** rotation works. i know it has some thing to do with sin SO>> and cos but how the formulas work is the tough bit since i am ***** at SO>> maths. BM> The trick is matrix math! Well, in other words: we have A(x,y,z) point, want to rotate it around x(e.g.) axis at alpha angle. A(x,y,z) becomes A1(x1,y1,z1). See the text below: x1 = x; y1 = y*cos(alpha) + z*sin(alpha) ; z1 = -y*sin(alpha) + z*cos(aplha) ; That's all. And for y and z axises you should correctly change operators above. P.S. I see the subject consists of two major words:rotation & perspective. My way of perspective realization is (not only my :) ): A \ virtual 3D-space \ \ ---------------- - monitor screen \ \ B B point is the our eye's place. You see, we must find the intersetion point between AB ray and the surface of screen. Then simp[ly plot A' there. My best respects to you. Andrey. --- GoldED 3.00a4+ * Origin: Sun is shining (FidoNet 2:5023/16.30) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: EG^00014 Date: 12/28/97 From: PAUL POLOSKOV Time: 12:34am \/To: ALL (Read 2 times) Subj: Fidonet Massage Bases Nice to see you, All. Is anybody here developing any programs, which working with a standart massage bases ? For ex: JAM, Squish, etc, exepts Hudson and OPUS ? What API are you using ? I'm trying a S.J. Dudley SQISH API - but it sooo slowww... Happy New YEAR from a cold Russia !!! /Paul --- Let It Be UNREG * Origin: Sing With A Wind... (2:50/420.24)