TIP: Click on subject to list as thread! ANSI
echo: aust_c_here
to: Paul Edwards
from: Paul Wankadia
date: 1996-10-19 11:39:24
subject: Auto string-length deter

On 13 Oct 96, Paul Edwards wrote to Paul Wankadia --

PW> What sort of pointers does large model use?  Far?
 PE> Yes.

I read somewhere that far pointers are very slow -- is that true?

PW> Does huge model use huge pointers?
 PE> I don't know what a huge pointer is, although I can take a guess.

I guess that's another Borland-only thing, perhaps?

PW> I was told (prior to this) that global variables should be cut down as mu
 PE> I was told that too.  Then I saw people (or myself, can't remember)
 PE> writing functions such as:

[example deleted]

 PE> Then I realised that it was a complete yank.  Why is get_variable_x()
 PE> OK, but x is not?  I then started using global variables freely,

I don't quite understand "but x is not" -- where did
"x" come into this?  I
don't follow... <%-\

 PE> although that later got replaced by PDS0004.TXT (available for FREQ

What's in that file (I wanna know before I FREQ it :)

 PE> from 3:711/934).  I questioned someone giving a lecture once on
 PE> something similar to structured programming, and asked him what was
 PE> wrong with global variables over global functions, and the reaction I
 PE> got was amusing.  At the end of the lecture, he asked us what we were

Please give details of the abovementioned reaction... ;)

 PE> going to change in our methods after his lecture, and I offered "I'm
 PE> going to start using global variables".  :-)  God I'm a menace.

Tsk tsk tsk... ;)

PW> BTW the way you said "global functions" -- is it possible
to declare (th
PW> is a silly question) a "local" function, accessible from
inside another
 PE> No, but what you can do is declare a function that is local to the
 PE> current SOURCE file, which is perfectly fine.  You stick a
"static" in
 PE> front of it.  In that context, "static" means
"local".  Presumably
 PE> they ran out of keywords or something.

Or didn't want to bother creating a new one just for the purpose :)

PW> When you say portable, do you mean portable between DOS compilers, or
PW> between DOS and Unix, or usable on any platform, or what?  I have always
 PE> Portable to ANY platform.  If you follow ISO/IEC 9899:1990, that's
 PE> exactly what you get.  If you DON'T follow the ISO standard, then you
 PE> should have a good reason, and document and isolate that code. Or else

Oops...  Time to trudge thru my code and redo it to be portable, I guess...
Half of it is prolly a mixture of Borland-only and a pinch of ASM 

 PE> have a different strategy in mind for when your customer says "This is
 PE> a great program, here's $50,000, go and stick it on that computer over
 PE> there (the one with 67-bit longs, integers and chars).

Does any platform in existence have 67-bit data types?  BTW I was reading a
little and read something about the "Harvard architecture".  It is supposed
to be a linear addressing system (as opposed to segmented architectures).  I
presume that most portable C code would still work on those machines?

PW> been a tad confused about that term.  BTW what non-portable functions and
PW> stuff exist in Turbo C++ v3.0 that I should be aware of?
PE> Billions and billions of them.  What you should do is FREQ ANSI_C.*

I hope you're not the SysOp {at} 3:711/934...

 PE> from 3:711/934 and then use THAT as your reference INSTEAD of the
 PE> Turbo C++'s manuals.

I don't use the manuals.  I use the online help -- much easier to copy and
paste examples ;)

PW> haven't already replied about this, what EXACTLY does "extern
\"C\"" do a
 PE> That's used in C++ only.  It says "all the following functions are
 PE> actually written in C".  I am not a C++ expert though, so don't quote

Hmmm...  Thanks.

 PE> me.  :-)  BFN. Paul.

A bit late now :)

Chow.

Junyer Hakker.

--- PPoint 2.00
* Origin: Junyer's Workshop (3:640/772.3)
SEEN-BY: 633/267 270
@PATH: 640/772 531 201 820 711/409 808 50/99 635/728 633/267

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.