[jamming] Complete, and utter automation with Jam

[Daniel White]

Hi John,

>> > How should it "know" to link to data.c ?
>> > Is this purely by naming convention?
>>
>> Well the same issue is involved with stdlib.h and print.h, but they  
>> manage
>> to get round it for some reason.
>
> When you #include stdlib.h, you are not getting any source code, just
> definitions of functions / etc.
> The actual code is compiled in a static library, which is typically
> linked in by default so you don't have to specify it manually.

Right okay, that makes sense.


> What I mean is that there is no "stdlib.c" file that gets
> automatically put along with your sources.
> In fact, the functions in stdlib.h are defined in a variety of
> different .c files - the rand() function is in rand.c, strtod() is in
> strtod.c, and so on.
> They are all compiled into a library so they can be included as a
> single unit by your program.

Woudln't it be more space efficient for C to only include the necessary
functions required for the operation of a particular program? Mind
you, I suppose the cost would having to recompile the source each
time...

> Thus in response to your question:
>> So there is a use to naming the .c files different from the .h files?
>
> Yes, there is - at least that is how it is done in this copy of the c
> standard library source I have hanging around.
>
> Have you been programming C/C++ for long ?
> I have, for instance, seen similar conceptual issues come up with some
> Java programmers when switching to C/C++, as Java has no notion of
> headers/sources.

Rumbled! :) Okay, it's true, I came from a Java background, and
switched to C because of the speed. However, the language D, which
is an upgrade from C, doesn't bother with them. Hmm... I wonder why ;)

Dan

>
> -John
>
> On 8/19/06, Daniel White <twinbee41 at skytopia.com> wrote:
>> Hi all,
>>
>> Thanks for all your responses!
>>
>> Brian said:
>>
>> > But from his original post, it sounds like he's doing something  
>> EXTREMELY
>> > non-standard (and bad). Just to clarify: do you actually #include all
>> > yoursource code (.c files) in a single file!?
>>
>> Sorry, when I typed the three source files, I accidentally put #include
>> in front of them. Instead, the only #include listed in "main.c" is
>> "data.h".
>>
>> > solutions, but they're all really fragile, and will only work in very
>> > constrained situations. Do you have source files in multiple  
>> directories,
>> > for example?
>>
>> Well not at the moment, but of course I may in the future. I think I can
>> see
>> where you're coming from, but as long as .h and .c files are kept  
>> together,
>> there shouldn't be a problem. After all, if we can keep things like
>> stdlib.h
>> and print.h in the source file, and that can compile without the need of
>> a makefile, then the same should apply one's own .h files ?
>>
>>
>> John said:
>>
>> > How should it "know" to link to data.c ?
>> > Is this purely by naming convention?
>>
>> Well the same issue is involved with stdlib.h and print.h, but they  
>> manage
>> to get round it for some reason.
>>
>>
>> > There are plenty of cases where XXX.h may be included and that may  
>> mean
>> > that
>> > AAA.c, BBB.c, and DDD.c are the ones it should "know" to include, but
>> > that
>> > does not have the advantage of a naming convention.
>>
>> So there is a use to naming the .c files different from the .h files? Is
>> that
>> something to do with two or more different .c files having the same set  
>> of
>> function names or variables as one 'master' .h file? Do you think it  
>> would
>> be
>> a good idea to have a naming convention where at least one c file must  
>> be
>> named the same as each .h file?
>>
>> This is going a bit off topic, and I could well be mistaken and maybe
>> header
>> files have some intrinsic use. But I'm wondering if maybe they are used
>> these
>> days only because otherwise the whole c structure / compiler situation
>> would need a rewrite otherwise. Ideally, I think that the programmer
>> should be
>> able include c files directly into other c files (no .h files at all).  
>> As
>> long,
>> as the compiler (or make) is super intelligent, and doesn't recompile  
>> files
>> unnecessarily, things should go fine. I could be hopelessly misguided on
>> this,
>> but I'm sure it's possible in principle, without compromising any of the
>> power
>> of c/c++.
>>
>> It's the same principle as having to declare the functions (a waste of
>> time).
>> Okay it's useful info for the programmer, but ultimately this should be
>> left
>> to the IDE enviroment to display for automation.
>>
>> Cheers, Daniel
>> http://www.skytopia.com
>> _______________________________________________
>> jamming mailing list  -  jamming at perforce.com
>> http://maillist.perforce.com/mailman/listinfo/jamming
>>



-- 
www.skytopia.com