Naggy problem with header-files

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I found a strange Naggy-behaviour dealing with header-files.

Otherwise my programming style may be wrong.

I have my main.c-file and according to this a main.h-file.

main.c includes main.h (Wooowwww :shock: )

in main.h other header-files are included, where several external functions are declared.

Compiling this, works fine, but Naggy Shows me warning about implicit declared functions.
I can get rid of Naggys warning by moving the include-statement to the main.c-file.

Is Naggy wrong/too sensitive, or is nested including in General bad manner ?

I program like a man:
COPY CON: > firmware.hex

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why would you have a main.h file ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why not? It is simply a header file, he can call it what he wants.

Quote:
Is Naggy wrong/too sensitive
I think that it is more likely that it is simply buggy.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Should you have a prototype for the main function in the main.h file ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Only if you have a call to main() in a .c file other than the one in which main() is defined (which would be rather unusual).

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The obvious first hypothesis is that Naggy can not cope with nested interrupts. I do not have Naggy installed so I can not test this hypothesis.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

with nested interrupts

Did Sir mean nested includes?

I just tried a test with Naggy including a file that includes a file that has a function declaration and everything just worked as expected. I'd be interested to see a test case.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

:lol: Yes, nested includes is the game.

I spent hours this weekend to find the reason for compiler errors.

- Naggy seems to keep error messages even if the problem is solved already.

Another question:

Is there any way to get an overview over nested includes ? I think of a uitility which shows me a tree graphics about my project which source files includes which header-file and so on.

I program like a man:
COPY CON: > firmware.hex

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah, Naggy re-parses a file only if there's some user input in the editor window containing the file. If the problem is fixed by editing some other file, errors will remain until the original file is edited. Also, Naggy uses the editor's buffer only for the active file being edited - everything else is fetched from disk, so unsaved changes in related files won't be reflected either.

Fixing this is a little involved - one part is obviously include file dependency detection. Now that someone's mentioned it :), I'll see if I can fix this this weekend. Should be easy to show the hierarchy as a tree visually, but the .d files in the Debug/Release directory already have this information.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

but the .d files in the Debug/Release directory already have this information.

And Atmel use that to show "Dependencies" in the Project tree - though it's a shame it's not shown as a hierarchy.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Looking at the Naggy problems on https://github.com/saaadhu/naggy/issues one sees that this is a known problem. Naggy nagged me so much with errors in header files that I removed it. As a good little programmer I don't #include header files in header files, but #include just as many as are necessary in the .c files.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jerryr wrote:
Looking at the Naggy problems on https://github.com/saaadhu/naggy/issues one sees that this is a known problem. Naggy nagged me so much with errors in header files that I removed it. As a good little programmer I don't #include header files in header files, but #include just as many as are necessary in the .c files.

I'll probably add an option to skip showing diagnostics in header files - would that work?

BTW, isn't it good practice to have header files "self-sufficient" i.e. people using the header file shouldn't have to figure out the transitive dependencies themselves?

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
isn't it good practice to have header files "self-sufficient"?
I have a feeling that this is a religious question - either make the .c files self-sufficient, or the .h files. In any case I NEVER define variables in a header, nor include code, and always have include guards.
Best wishes, Jerry