简体   繁体   中英

How can I include only few lines of header file(read-only file) in my .c file

I need to use some part(like from line 10 to line 15) of read only .h file into .C file.

Note: I can't edit .h file, because that is not from my module. Also I can't use all the .h file variables.

Is there any way to use like this ?

As the including client code, you don't have arbitrary control over which lines in the included header are used.

Some few headers explicitly grant control by using #if #ifdef or #ifndef such that you can set some preprocessor define before including that header and affect which lines are used.

Otherwise, you can sometimes declare the variables you need to access yourself, but that's something I'd strongly discourage: as the header evolves, it's easy to end up with your declarations being different from the headers. It's especially bad in C++, where authors of header files might reasonably expect to say change class X into template <...> class XT ...; typedef XT<...> X; template <...> class XT ...; typedef XT<...> X; without breaking client's ability to recompile cleanly, but if you've declared " class X; " in your own code this will conflict with it being a template.

You've explained more concrete details of your need in a comment:

I have to use only few variables from different modules( .h files). If i use #include for all .h files, then "redundant redeclaration of 'Tabc_st', previous declaration of 'Ta[b]c_st' was here" warning will come..... – laki

I would guess some kind of "Hungarian" notation's being used, and - after recovering from nausea - assume T was for type and _st for struct . If so, you've either got multiple struct Tabc_st declarations or typedef ... Tabc_st; s. To comment on the options listed in other answers:

  • #include the conflicting headers in separate namespaces: this is a moderately clean, structured approach to the problem but can backfire: for example - if the header is exposing functionality that you plan to link a library for, then the mangled names won't match and linking will fail.

  • #define Tabc_st WhateverElse around all-but-one of the problematic headers: this works great for typedefs, but for struct Tabc_st it does mean that any uses of the type later in the header will instead see "WhateverElse" - if you're meant to be able to take a Tabc_st and use it with any of the code from any of the headers, you'll find this doesn't pan out as they're all now expecting different types.

Another approach is to provide a .h/.cpp pair that wrap each problematic .h and expose it's functionality using new non-conflicting names. That's quite a lot of work to maintain.

A workable hack may be to script up a pre-compilation step such as:

TABC_ST=`fgrep 'struct Tabc_st;' header1.h`
fgrep -v --line-regexp $TABC_ST header2.h > header2_sans_tabc.h
fgrep -v --line-regexp $TABC_ST header3.h > header3_sans_tabc.h

Then use the ..._sans_tabc.h headers....

You can do

#define Tabc_st bogus_thing_I_can_ignore
#include <readonlyheaderfile.h>
#undef Tabc_st

and the header file will declare bogus_thing_I_can_ignore instead of redeclaring Tabc_st. if Tabc_st is a typedef name and the header uses that type, this will still work because typedefs are just aliases, not new types.

If you can't edit header file, there is no way to use only part of codes. I would strongly suggest that you use different namespace to solve variable name conflicts. And if you are trying to include only some part of codes to save memory....don't do that. Having few useless variable is not big deal.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM