When I compile this extremely simple program I get this cryptic error:

  "warning: passing argument 1 of "printf" from incompatible pointer type"

  Here is the program.

  # include <stdio.h

  int main()

  {
  printf(stdout, "this is a test\n");
  }

  What ever could be wrong? :)

  -----------------------------
  Never mind. Incompatible versions of C.
  The program source was from an earlier version.
  Here is the corrected source:

  # include <stdio.h

  int main()

  {
  printf("this is a test\n");
  }


  Now it apparently compiles it but I can not find the executable.
  Anybody have any idea where gcc  hides it? :)

  Paul Lamar

  With no other options, I think the object file (executable) is named
  a.out.


  Matt-


  If you want the output of the compiler to name it something else, use
  "-o <filename"..


  Matt-

  You are right. It does default to a.out. Who would of thunk. Weird :)
  Also -o <file name  worked. Thanks Matt

  C is incredibly dumb and picky :)
  The QB IDE was head and shoulders above this nonsense.
  Too bad MS killed it.

  I have Anjuta IDE but so far it crashes when I try to build a file
  or execute it. QB and PB never did/do that silly stuff.

  I get the impression that the C IDE and the C compilers are not
  using the full power of the computer to help the programmer.
  The complier must be told exactly what to do in excruciating detail.
  QB would correct your variable spelling automatically.


  Paul Lamar

 --Kenny A.
 http://websites.expercraft.com/kennya/

 Try using the 'eclipse' open source IDE. It will create makefiles for you,
 integrated debugger, etc. Much more civilized. Be warned, it takes my
 interns all summer to master just the toolset when working directly with
 gcc, ln, gdb, etc.

 --Kenny A.

 Oh boy! I am too old to learn all these new tricks :)
 Thanks Kenny. I'll try the eclipse IDE.

 Paul Lamar


C is a relic.  A very powerful, excellent relic, but it was designed
in a different time.  In some ways C is like a manual transmission.
Maybe a manual without synchromesh.  You have to double clutch at
least some of the time, and it's possible to break things if you
aren't careful.  At the very least it's going to make some crunching
sounds occasionally.  But, it's possible to understand what's going on
because there really isn't that much going on.  And, it's actually the
simplest, most efficient way to get the job done.  Not for the
operator, but for the manufacturer.

I get the impression that QB might be like a powerglide, or maybe a
Turbo350.  You can get around with it.  It works better with a big
engine (processor) because it's not actually very efficient.  Aspects
of its operation are completely hidden from the operator.  And may be
very difficult to understand.  It probably won't jerk or shake or make
any bad sounds.  But, it uses a lot of gas (processor power).  If fuel
is cheap, and you have a big engine, who cares.  Nowadays, processor
power is basically free for many applications, so using a slushbox is
kinda nice for some tasks.

Matt-

I think QB was just scratching the surface of what was possible.
I wanted an automatically generated variable data base.
All one had to do was comment the variables and labels and
the background data base would record them for search or sort.

Of course a 32 bit DOS never materialized so 64K memory was
the limit for QB. The entire IDE was right at the limit at 64K.
It compiled to tight and fast code. My moving map program proved
that. With todays processor and a real time 32bit DOS
it would be unbeatable. There is no correlation with
the speed of execution and the level of the programming
language. It is all in the compiler. QB and FB are far
higher level languages than C. Almost plain English.
C by comparison, is hieroglyphics

Here is my 30 year collection of programming books.

Paulo Lamar