Re: Defining many classes in a single file

From: Senapathy (senapathy.k_at_siemens.com)
Date: 07/14/04 

Date: Wed, 14 Jul 2004 14:03:48 +0530

"Aguilar, James" <jfa1@cec.NOBOTSwustl.edu> wrote in message
news:cd2m8j$sj8$1@newsreader.wustl.edu...
>
> "Senapathy" <senapathy.k@siemens.com> wrote in message
> news:cd2l4e$t0u$1@news.mch.sbs.de...
> >
> > [snip]
>
> Followup question:
>
> Won't having a whole bunch of different source files (say, put in a
> subdirectory) be hell for the makefile? I can imagine a rule that says:
>
> 2dphysics.o: $(CCC) $(CFLAGS) ...(200 shape implementation files) shape.h
>
> What do you do about that?
>
>

I suppose, you meant the linking part.
Each source (implementation) file would contribute to 1 object file each. So
the make file would contain some 200 lines for producing these 200 .o files.
Hmm... the _linker_ would need some 200 object files.

But I suppose the IDE should remove the complexity from the build procedure.
Even a batch mode should not be too much of a problem if you want to
automate the build procedure. Some IDEs provide a mechanism to export a make
file from the present source file / header file list.

I would still prefer factored implementations because of the maintenace
aspect. Ultimately that would matter more than the build procedure.
If you have some source control / configuration management scheme, all these
things would not matter at all. Source code readability, maintainability
would server you in good stead.

However, since you mentioned that there would be around 200 implementation
files, maintaining these files also would prove cumbersome.
So I guess you need to arrive at a logical grouping of these files and club
some implementations together. I have done it also under some circumstances,
so I can't say it is such a bad thing either :-)

Senapathy

Relevant Pages

  • Re: Bug/Gross InEfficiency in HeathFields fgetline program
    ... Antonius' replacement is terse to the point of being painful to read ... superior for production level code in at least two ways: ... Less so than readability and maintainability*. ... Correct (it doesn't matter ...
    (comp.lang.c)
  • Re: D7 revival? stirring the old pot + Delphi 64 suggestion
    ... Probably more a matter of overall responsiveness and flickering: I just can't stand a flickering UI, and that's one of two common points IME between TD2006 and Lazarus. ... IME flickering issues are cheaply solved if taken care of early, all it takes is a few good practices, but once they're all over the place, they become an expensive issue to solve. ... I just wonder how long CodeGear will keep on these lost causes (IDE + Help system), IMO they really need to start thinking out of the hype box, and start realizing how many man-years have been wasted on these experiments... ...
    (borland.public.delphi.non-technical)
  • Re: fstab and LABEL=
    ... it doesn't matter what the drives are actually labelled as. ... even parallel ATA disks (IDE) will be called /dev/sdx. ...
    (Fedora)
  • Re: final for get/set methods?
    ... Which is better, factoring in speed, maintainability, ease of coding/ ... apply "final" for the same reason you'd ever do it anywhere else: you specifically have some good cause to want the member not to be overridden. ... I find the use of 'final' as the preferable option quite appropriate - it documents and warns future maintainers of its enforcement. ... Final variables are another matter - there are performance and concurrency implications there. ...
    (comp.lang.java.programmer)
  • Re: Help with Array
    ... Not only can one often produce code more quickly using an IDE than with a "standad" editor, or with punched cards for that matter, but with the IDE's assistance one is likely to leak fewer mistakes into the code repository. ... As programmers we tend to get monomania about code production; that is the least of software development tasks. ...
    (comp.lang.java.programmer)