--------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: EGU00027 Date: 12/25/97 From: KURT KUZBA Time: 03:02am \/To: JOHN RICHARDSON (Read 2 times) Subj: Greens JR> I see no advantages in the class construct except that it JR> does help to prevent sloppy programming, and it does add JR> overhead in terms of program execution speed. JR> I don't see how it can hasten application development. You should ask about that in the C++ echo, really. Inheritance and Polymorphism are the answer, of course. The use of structured code really can make a difference. > ] It's around somewhere. I put it where I wouldn't lose it.... --- * Origin: *YOPS ]I[* 3.1 GIG * RA/FD/FE RADist * Milwaukee, WI (1:154/750) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: EGU00028 Date: 12/24/97 From: BOB STOUT Time: 07:09pm \/To: PETER LOUWEN (Read 2 times) Subj: Posix stuff On , Peter Louwen (2:280/901@fidonet) wrote: RS> The close() function is defined in Posix.1 and is available on most C RS> compilers in most environments. Some pedantic compilers for various PC RS> environments depart from standard Posix/Unix practice and call it open() RS> instead. > Shurely shome mishtake ? Peter... OK, obviously, I meant to say _close() instead of _open(). Still, it's a sill practice - no surprise, Microsoft started it, now everyone does it for compatibility. :-( Posix and ISO need to get their coordinated acts together. --- QM v1.00 * Origin: MicroFirm : Down to the C in chips (1:106/2000.6) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: EGU00029 Date: 12/24/97 From: BOB STOUT Time: 07:17pm \/To: NIGEL TRAVES (Read 2 times) Subj: STREDIT 0/13 On , Nigel Traves (2:2503/509@fidonet) wrote: > Sorry about that Bob, it just didn't occur to me that someone would see it > to make that a (sort-of) reserved word in their compiler. Nigel... Making reserved words of standard library functions (and especially so of *potential* function names TBD in the future!) was one of the more hotly debated new features of ANSI C. At the time I opposed it, but I'm pretty much neutral these days. > Let me know what you want done. Nothing. It's one of the general portability things I check for and correct before committing code to SNIPPETS. OTOH, if you have any functional changes you'd like to make in light of the subsequent discussions, let me know and I'll make sure they're included. --- QM v1.00 * Origin: MicroFirm : Down to the C in chips (1:106/2000.6) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: EGU00030 Date: 12/25/97 From: BOB STOUT Time: 02:02am \/To: KEN WAUGH (Read 2 times) Subj: HOW2: Manipulate GIF/JPG ? On , Ken Waugh (1:374/128@fidonet) wrote: >> Congratulations, you pretty much described the system I've been working n >> for the past 6 months! The only differences are that mine is an embedded >> system so the text I'm overlaying is real-time telemetry, and I'm >> displaying it continuously rather than saving it to a file. > GEEZ just a FWIW:, That option exists both on my C=64, 128, and this Amiga. > It's hardly something new. Ken... I'm not surprised. If anyone had ever made embedded Ami controllers, I'd be using one. Of course, if if there had ever been embedded controllers based on the Ami, I would've realized my long-standing goal of actually having a valid business reason to acquire one. As it is, I'm having to do what in auto body work is called, "hammer to fit, paint to match". ;-) --- QM v1.00 * Origin: MicroFirm : Down to the C in chips (1:106/2000.6) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: EGU00031 Date: 12/25/97 From: BOB STOUT Time: 03:05am \/To: BRUCE LEGRANDE (Read 2 times) Subj: HOW2: Manipulate GIF/JPG ? On , Bruce LeGrande (1:2003/0@fidonet) wrote: RS> Congratulations, you pretty much described the system I've been RS> working on for the past 6 months! The only differences are that > Great minds think alike ??? :) Bruce... Well, speaking only for myself, "great" is arguable.. RS> mine is an embedded system so the text I'm overlaying is real-time RS> telemetry, and I'm displaying it continuously rather than saving it to a RS> file. > Hmmm.. Interesting goal. This would be kind of like the subway TV's that > display a graphical background (usually something soothing, to calm atrons > down from their busy daze) with the train schedules or weather data > superimposed over it. ? Similar. In my case it's a commercial system that provides information and advertisements while tracking the current sale. RS> 1. What is what is your environment? DOS/Win16/Win32/Unix/OS/2, > DOS would be my first choice of OS, and once the application is out of eta > perhaps a Win16/32 and OS/2 version. DOS is a good choice for pragmatic, rather than technical reasons. Embedding DOS is a mature technology, i.e. it's far from perfect, but all the gotchas are known. Since yours isn't an embedded system, your choices are wide open. I'd been considering moving to embedded Linux for the MPEG version, but now I'm testing a new PC/104 card that does MPEG-1 in hardware, so I may stay in DOS. The best thing about staying in DOS is that the MPEG hardware has a VGA input so I can keep my same software to generate the screen that will overlay the MPEG presentation. > The end product (enduser) should be compatable with a wide variety > of hardware from XT to 686/Pentium, and should be backward compatable > to at least DOS v5 (v3.2 would be nice) to add versatility to userbase. This does suggest DOS, in which case, please consider my recommendation of Genus for programming tools. Also, ignore my previous post where I said Genus doesn't do GIF - it does, but I'd forgotten it since I have no personal interest in doing GIF for this product. RS> 2. Are you tied to GIF format? Is the choice of graphics formats under RS> your control or determined by your users? > The format would be at the control of the author (me), for the time > being. Maybe adding support for a few of the other formats later on > that could be selected by the graphic image designer. I have to work quite closely with the ad agency that produces most of the multimedia content. I've found a couple of shareware tools that handle all necessary conversion. Currently they're delivering WAV audio, which I'm post- processing into VOC format. They've also delivered video in several formats, which I can postprocess into PCX. The only problem with video has been palette matching. > It's entirely possible that the exe MIGHT be released with the image being > integral to the exe and all the settings as far as x/y coded in - just the > data that fills the various fields (at x/y) to be added by the user a the > time of running the program. One of the nice things provided by Genus is the ability to create libraries of content files. Currently, I'm using one each for the audio and video files, respectively. However, another option is to package libraries within the body of the .EXE. The nice thing about Genus libraries is that you don't have to open each separate file, plus they're indexed for fast access. > This later would require SOME sort of utility to patch the graphic > (different for each user) and the field locations into the exe 'on the ly' > to remove the need to "recompile" before the exe is sent to the end user. > Come to think of it... That would be the prefered method, and some type f > encoding of the patched graphic in order to keep the user from simply > 'cutting' it out to a seperate file using a bin-editor. As noted, I'm packaging the content-specific stuff separate from the .EXE. I'm also making extensive use of configuration files so that the .EXE may never have to change between specific sites/customers. In my case, to set up a new customer, all I have to do is package the content into the library files, then create the configuration files so that each state in the FSM knows which files, in which order, and in concert with which other files, it's supposed to play. RS> In my case, I'm working on an 486 running embedded DOS. I have my RS> choice of formats, so I'm using .PCX slides with .WAV narration. RS> Currently, I'm adding .FLC cartoons with .VOC narration. Next month, 'll RS> be adding full MPEG-1 multimedia support. Before I started, I looked RS> around for the least expensive, easiest solution and wound up using RS> commercial libraries from Genus Microcom-puting, which I can recommend. RS> When I do the MPEG version, I may change both environments and ibraries, RS> but that remains TBD. > Wow... Lots of features there that aren't needed here... Although it ight > be a nice option later on to be able to allow the enduser to record a hort > sound image (ie 30 secs) into the image before saving it to output and > sending it on. But that would be at a MUCH later stage in development. Genus makes the following specific modules: GX - The graphics kernel GR - Vector graphics TX - Text PCX - .PCX images FX - Sounds, sprites, .FLC, animation, joysticks, and palette fading PR - Printer support GIF - .GIF images Genus' latest product makes all these available, with source, on CD-ROM. As previously noted, a wide assortment of DOS extenders are supported, and Windows versions are available for several of the products (at least the PCX and GIF libraries). Individual products are something over $100 each (I don't recall the exact prices), but the CD-ROM with everything is available as a $500 upgrade for customers who've bought at least one of the individual packages. (I believe this is the way it works, but check with Genus if you're interested before taking my word on it.) Contact them at: Genus Microcomputing 1155 Dairy Ashford #200 Houston, TX 77079 281.870.0737 800.227.0918 sales@GenusMicro.com > So... I guess what we're looking at NOW, is an executable for the esigner > of the image to use to incorporate the graphic into another executable hat > could in turn be sent to the user, and would allow the user to enter args > on the cl (or datafile) to fill in the fields (location of which would be > set by the graphic author), and then save the resulting graphic with > overlaid text in a COMMON format graphic file that could then be > distributed to others by electronic means. You can do all this using Genus' GIF and TX toolkits (the GIF toolkit includes the GX graphics kernel). The TX toolkit gives you a choice of 661 bit- mapped and stroked fonts. You can even add printer support with the PR toolkit. In case you could't tell, I'm really happy with this product. --- QM v1.00 * Origin: MicroFirm : Down to the C in chips (1:106/2000.6) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: EGU00032 Date: 12/23/97 From: ROBERT WILKINSON Time: 06:41am \/To: ALL (Read 2 times) Subj: Where are they? Hello All! Does anyone have a routine for determining which serial port a person is calling in on to a Linux system? Or, perhaps know where I can look for that information? Thanks! Happy Coding! Bob --- FalkenRdr V1.9d * Origin: Kennewick,WA <509-586-3157> - (1:3407/7) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: EGU00033 Date: 12/23/97 From: ANDY HAIGH Time: 07:41pm \/To: SIMON AVERY (Read 2 times) Subj: Re: C++ turbo for dos 3.0 Hiya Matey, about this ]] command ( <--but not this) can I just enter it from the eyboard or do I have to use the alt job. When I use my borland 4.5 compiler for windows I can just press the key next to the shift and the char appears but not in dos. its a bit crazy. If I want this OR command I have to use alt to get it. oh well cheers anyway. Haighy. andy.haigh@zetnet.co.uk on the net. ... The last thing I saw was this Big Blue Wave! --- Blue Wave v2.12 [NR] * Origin: Alba Maximus, Glasgow 0141 880 7845 V34+ (2:258/4) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: EGU00035 Date: 12/23/97 From: SIMON AVERY Time: 06:44pm \/To: SIMON HUGGINS (Read 2 times) Subj: Tagline program Howdy Simon! 20 Dec 97 20:30, Simon Huggins wrote to Simon Avery: SA>> I'm not sure I'd be allowed to give you specific functions. You SA>> can, however, freq "SNIPPETS.ZIP" from me which'll give you SA>> everything. (It's /all/ useful, anyway) SH> :) Will it be your first FREQ this is the question Not quite... SH>>> Thanks for your comments/advice. Much appreciated. SA>> No worries. I've done about as much as you can with taglines and SA>> often wished I had someone who'd been there before to ask. ') SH> :) Believe me it's *VERY* useful!! Glad to be able to help. Any more Q's you know where I am. SH> Merry Christmas. Et tu, Simon Simon --- FMail 1.22 * Origin: Tag-O-Matic - Freq T-MATIC from Origin (2:255/90) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: EGU00036 Date: 12/24/97 From: SIMON AVERY Time: 02:57pm \/To: BRIAN MCCLOUD (Read 2 times) Subj: Tagline program Howdy Brian! 19 Dec 97 06:43, Brian McCloud wrote to Simon Huggins: BTW, background info - I'm the author of Tag-O-Matic (one of the most featured tagtools around - but enough of the plug...) SH>> srandom((unsigned) time(&t)); //seed random function SH>> do { SH>> tpos=(random() % length); SH>> fseek(tag, tpos,0); SH>> fgets(tstr, 999, tag); SH>> fgets(tstr, 999, tag); BM> This seems rather inefficient, since you're reading up to 1998 bytes, BM> but most taglines don't exceed about 70 or 80 characters. This also It's very efficient. The TAGLEN macro depends on what you do. Simon's a DOS Tag-O-Matic user, which allows for tags up to 2048 chars /each/ and I guess he likes the multi-lined ones which is why he's including that facility in his program. IMO, fixing a low tagline length is dictating to users what they /should/ do, not what they /could/ do, IYSWIM. BM> gives different probabilities for each tagline (especially if they BM> vary in length). I can think of two ways to solve this: 1. make the BM> tagline file be of fixed-size records (though at the size you BM> were suggesting, that file would be too big). 2. make a separate file BM> with indexes to the beginnings of each tagline (another utility could BM> generate this file from a text list of taglines) 1. - Even more wasteful. if you've a collection of taglines of an /average/ of 50 chars, and several are 75, you would need to make the max 75 - which adds 25 chars to each tag, which adds up when you've got over a 100 thousand tags. 2. - This is a good idea, but will take up even more space if you index every single tag. For example, my main tagfile is around 5Mb in size, containing 350,000 tags. An index, assuming a 32-bit index value for each tag would take up a lot of space. And you'd probably need two such values. Tag-O-Matic has tackled this problem by having a small index file for each tagfile which holds a few basic ints. Simon's come up with the same solution to a tricky problem that I did several years ago. I've looked around and this method is by /far/ the fastest and most efficient one especially for large tagfiles. Tagtools have moved on apace in the past few years - most work from pure ascii tagfiles, and it's considered taboo to re-compile a tagfile to make it easier for the programmer! Not least because it can as much as triple the disk space used, not to mention the huge delay when it recompiles a large file. It's all silliness of course, but it's a very good way of learning string manipulation, file I/O, and lots of other programming basics. A basic tagliner is one of the simplest programs to write, here, I've got five minutes to spare, I'll plonk you a dinky; /* BRIANTAG.C Simplistic, SLOW tagliner for small tagfiles. Untested. */ #include int main(int argc, char *argv[]) { FILE *tag, *msg; // note not ULONG as random() only returns an int and not // bothering to include snippets' longrand.c unsigned int tot_tags=0, chosen_tag=0; char tagline[101]; printf("BrianTag!\n"); if (argc !=3) { printf("Usage: %s {tagfile} {msgfile}\n",argv[0]); return 1; } if ((tag=fopen(argv[1],"rt"))==NULL) { printf("Unable to open tagfile: %s\n",argv[1]); return 2; } if ((msg=fopen(argv[2],"at"))==NULL) { printf("Unable to open msgfile: %s\n",argv[2]); return 3; } // count number of tags in tagfile: while (fgets(tagline,100,tag)) tot_tags++; rewind(tag); chosen_tag=(random(tot_tags)+1); // re-use tot_tags as it's no longer needed. for (tot_tags=0; tot_tags!=chosen_tag; tot_tags++) { fgets(tagline,100,tag); } // check for EOF too if you like fclose(tag); fprintf(msg,"... %.75",tagline); // no \n as tagline will include one fprintf(msg,"~~~ BrianTag v.000001A\n"); fclose(msg); return 0; } There! This uses the other main method of tag-picking, which is only really usable with small tagfiles. Anything larger and you need the fseek method. Max usable taglines 32,000 (or whatever maxval of a signed int is). You should write an index file and check for it to cut down the initial counting (which is the longest delay). [Disclaimer: Source was written blind, no testing, little error-checking and could be re-written much better. It is, however, completely free if anyone wants it.] Simon (A bit of a tagline freak...) --- FMail 1.22 * Origin: Tag-O-Matic - Freq T-MATIC from Origin (2:255/90) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: EGU00037 Date: 12/23/97 From: BILL BIRRELL Time: 09:44am \/To: JOHN RICHARDSON (Read 2 times) Subj: Greens Hey John, >> actually a blind alley? Sorry! :-( > I picked up a tutorial on C++ the other day and I > think I agree with you. Thanks for that, John. I've had some constructive input from Bob Stout, and it appears that we may be maligning it without meaning to. The idea of user defined data types with their own private functions could be useful for database or GUI programming I guess, but I think we are very much on the borders of being off topic so I'll leave it at that. Happy Christmas, Bill. --- * Origin: bill@escan.demon.co.uk (2:2504/200)