• Please review our updated Terms and Rules here

a c compiler

Turbo C++ 3.0 from Borland is an excellent choice. I'm running it on a 386-40.


Mike
 
I have a copy of Turbo C++ for DOS, that I'll sell ya for twenty bucks.

My only question is, why on earth are you running Win 3.0 on that machine? You'd do a lot better with 3.1 or 3.11 (with or without 32-bit extensions).

--T
 
What i want is a copy of "c" not c++ because all of my good programing books, except for two are c books. I have a copy of turbo c but i don't care for it much.
 
C is a subset of C++. Or C++ is a superset of C. Depends on how you look at it.

Either way, Turbo C++ 3.0 will compile C programs just fine.

If you don't like the Borland products, look for an old MS version or try a GNU based one.
 
jjzcp said:
I have a copy of turbo c but i don't care for it much
Click to expand...
??

What is wrong with that Turbo C compiler in that case? Or rather, is there something you want to do that the compiler is not compatible with?

Borland themselves offer the compiler part of C++Builder 5.5 for free download, but it only supports back to Windows 95, so it is out of your question. Gcc (or rather djgpp) might be interesting to you if you want a rather modern compiler which still may execute on your system.
 
Not sure about ANSI compatibility, if it even existed back when Turbo C was available. I reckon C was standardized sometime during the 1990'ies. I remember in Turbo C there was some issues regarding trigraphs and some constructs?

In any case, a somewhat modern gcc would probably both execute, be as compatible as you wish, include front ends to other languages like C++, Fortran and even Java, and practically be free of charge.
 
On Turbo C, When i am, say, asking it to print out 200 * 200 i get something like -72 as an answer, and the interger variables only go just past 30,000. Other than that though, it compiles all my, and code from my c books (wich are newer than 1990) just fine. Right now i am giving more AI to my tic tac toe game so it always wins.
 
I could never get in to any of the C's. I always thought the syntax was weird. (This coming from a life long BASIC and Visual Basic Programmer) Anyway the very few times I have used C (and I do mean FEW) I use GCC. Its free and compiles C what more could any one ask for? Personally I would ask for a bash prompt or even a DOS prompt rather than a C prompt. But hey, no ones perfect.

-Vlad
 
Ah, try unsigned int and you will get at least 16 bit integers in the range 0-65535. It is a while ago I worked a lot with C, but I think most older implementations regardless on platform and bitness will default to 16 bit ints? Maybe today, a regular integer is 32 bit though.

Of course, you can declare your variables as long if you know that you will hold large values. Any other oddities you have encountered?
 
Dude, not to be rude (hey that rhymes!), but you need to hit the books harder and learn some C.

Running under DOS in 'real mode' you have a 16 bit machine. As others have pointed out, that limits you to 16 bit numbers. If you don't need the sign bit you can get 200x200 into an unsigned int.

These dos machines also support unsigned long ints and unsigned longs, which are 32 bits.

Pointers are not 16 bits on these machines. For 'normal' programming you can use points just as you would on a non-segmented system. But for using DOS interrupts, peeking around memory, etc. you are going to need to get familiar with segments and offsets.

There are some other gotchas. It's not that C is inadequate - it is that most C programmers and books assume a flat 32 bit address space with 32 bit integers. In the world of 1978 on this architecture, integers are 16 bit and memory space is segmented.

As for 'how long is an int', it has always been defined by the architecture you are running on. On my 64 bit servers ints are 64 bits.
 
Oh, and a related word to the wise ..

I just spent an hour debugging a problem with my TCP/IP code and it was a wasted hour. The problem was that in one C++ part I added a new function at the top of the file to print an IP address to a buffer. It was a pretty simple function using sprintf to fill in the buffer. Should be easy, right?

Code: 
IpAddr_t is a typedef for unsigned char[4]

char *IP::formatAddress( IpAddr_t a, char *buffer ) {
  sprintf( buffer, "%d.%d.%d.%d", a[0], a[1], a[2], a[3] );
  return buffer;
}

Well, it wasn't giving output at all.. Turned out to be that the sprintf always returning 0, which means no error, but no bytes written.

After a lot of digging around I figured out that duplicating the sprintf line in the function would work. It just wasn't liking the first sprintf.

After more work I figured out that putting this function at the beginning of the file made my formatAddress function work perfectly, with no kludges:

Code: 
void dummyFunc( void ) { puts(""); }

rest of code starts here ...

So what I suspect is happening is that there is a linker error, and that the first call outside of this particular object file isn't being resolved correctly. There is certainly nothing wrong with the code - all I have to do is put that dummy function first, and life is great.

Moral of the story? I like Turbo C++ 3.0 and all of the Turbo C products in general. But they have more bugs than a dog has fleas. I generally avoid the hardcore C++ language features because I've run into other bugs, but this particular bug was a suprise, even for me.
 
You must log in or register to reply here.
Back
Top