Re: Some Advice.

• Previous message: Buck Rogers: "Re: Bloodshed C++ IDE compiler dos shell problem"
• In reply to: Robert W Hand: "Re: Some Advice."
• Next in thread: Mike Wahler: "Re: Some Advice."
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Sat, 14 Feb 2004 02:13:36 GMT

Robert W Hand wrote:
> On Fri, 13 Feb 2004 22:25:49 GMT, Joec <joec@annuna.com> wrote:
>
>
>>>Third, you should provide inclusion guards for headers.
>>>
>>>#ifndef H_BASE
>>>define H_BASE
>>>
>>>struct cord{
>>> int x;
>>> int y;
>>>};
>>>
>>>struct drs{
>>>int ud;
>>>int lr;
>>>};
>>>
>>
>>Not fimilliar with that will have to read up on it.
>>
>>
>>>#endif
>
>
> I have given the basic syntax for it. In this example, if H_BASE is
> defined, then everything between the #if and #endif is excluded. If
> H_BASE is not defined, then the next line defines it. The code in
> between the #if and #endif lines is included. The inclusion and
> exclusion is provided by the precompiler.
>
> In complex programs with many files and headers, a header might be
> included many times in any particular source file. So the resulting
> translational unit may have multiple copies of the same code. This
> technique culls out the multiple copies.
>
>
>>>Fourth, you need comments. I assume that cord is coordinate (note
>>>misspelling makes me somewhat uncertain), but what is drs? You should
>>>not make your identifiers a guessing game for a future maintainer
>>>(including yourself).
>>
>>Yes that is true. I I am afraid to go back and change a bunch of name.
>
>
> Yes, it is best to pick names carefully at the beginning. It is one
> of my failings too. I am forever changing identifiers with my text
> editor's replace command.
>
>
>>>Fifth, I would be careful about including other headers in your
>>>headers. It may be the best way to handle something, but it can lead
>>>to thoughtless errors, too. I usually try to do the including in the
>>>cpp file. Your game.hpp seems to have been put together by rote
>>>rather than by thinking.
>>
>>OK, I didn't know that. I saw that in an example somwhere. But it may
>>have been a different situacion. I have not seen amy large scale code
>>and I have been making it up as I go along.
>
>
> Primary it is a stylistic point. Without inclusion guards, mistakes
> could happen. And even with them, why include a header if it is not
> needed? My point was to think about what headers are needed for each
> file. If a header is needed for a class definition, then there is
> nothing wrong in C++ to add it to the header containing that
> definition. If it is not needed for the header, but is needed for the
> source file, then I include it in the source file.
>
>
>>>Sixth, I usually keep one source and header for each C++ class. And I
>>>try to pick names that suggest the class or its function. You seem to
>>>put several classes together in the same header. Again, it may be the
>>>best way to handle something, but it may not be the best way to handle
>>>every situation. In large programs, it is easy to lose a class if it
>>>is hidden among many files.
>>
>>True, but I am using several files and I was planning to copy them over
>>later. It is that the source is linked and I already had 3-4 windows
>>open working on a single problem.
>
>
> Yes, it is a work-organizational issue. As you mention below, you
> accidentally included another project's file with this one. If your
> OS allows directories, then use one directory for each project. It
> gets too complicated to sift out unwanted files when there are many
> files.
>
>
>>Wow thanks for the tips. Some of them I am learning as I go along. I
>>am learning that naming is far more important in C than in Perl.
>>Writing a program and learning is very fustrating. I want to learn. I
>>can read books on syntax and theory all day but it doesn't matter until
>>it is applied.
>
>
> I hope that they are useful to you. I am not necessarily the neatest
> person in the world, but I do keep my code and projects neat. I think
> that you will find most experienced C programmers are very careful in
> this regard. It is much easier to fix something at the beginning than
> to try to fix it when lost in thousands of lines of code spanning tens
> to hundreds of files.
>
> I do some PERL programming, too. C is a much different language
> although PERL was derived from C. I find C's design to be
> well-thought out. Although many of us are doing more C++ than C, I
> still find that some C code (compiled as C code) sneaks into most of
> my projects.
>
> Best wishes,
>
> Bob

On my page is my C++ and Perl work. I menat C++ not C. Still it is
good to hear from some people who know somenting about programming I
don't meet many in real life. I think I will hit the books and hope I
find something useful. Of course sometimes I just need a better book
and keep my hands off the keyboard.

• Previous message: Buck Rogers: "Re: Bloodshed C++ IDE compiler dos shell problem"
• In reply to: Robert W Hand: "Re: Some Advice."
• Next in thread: Mike Wahler: "Re: Some Advice."
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]