-1

Is there anything in C++ which is the "opposite" of header files? Instead of a source file including a header, this "opposite" file would specify the source.

For example, if I make a source.bpp ("bottom ++ file") and the last row is #outclude "target.cpp" then when building target.cpp, the build system would somehow find the file with the #outclude "target.cpp" line (source.bpp) and concatenate that file to the bottom of the target.cpp file.

This would be useful, because I cannot modify some source code in the project, but with these I could extend them. (Yes, I could do it manually, but there are 400 k rows in the project, and the rule is that I must use the old files without modification of the files.)

JaMiT
  • 14,422
  • 4
  • 15
  • 31
Darffire
  • 21
  • 4
  • 7
    `#include` is not necessary the first line of file, it can also be placed at the end (with appropriate content). – Jarod42 Nov 02 '21 at 12:46
  • 1
    why does adding a preprocessor directive not count as modifying the file, while adding the code the proper way does? – 463035818_is_not_an_ai Nov 02 '21 at 12:48
  • `#outclude`? If you are adding your own preprocessor, I suggest `#exclude` instead. – Ted Lyngmo Nov 02 '21 at 12:48
  • wrapped_target.cpp might then be `#include "target.cpp" #include "source.bpp"` and adjust buildchain to to build target.cpp (#include cpp file should be avoided when possible) – Jarod42 Nov 02 '21 at 12:49
  • @TedLyngmo: As I understand, it would be `#append_current_file_at_the_end_of "file.ext"`, so exclude seems the wrong term too. – Jarod42 Nov 02 '21 at 12:51
  • You could wrap modules in different #ifdefs. Then use a singular file contain said defs. This would allow you to easily adjust which files/modules are built. – Frebreeze Nov 02 '21 at 12:53
  • @463035818_is_not_a_number: OP doesn't modify the file with additional preprocessor. instead of having `#include "footer.xxx"` at end of target.cpp, OP wants footer.xxx have its custom preprocessor (`#append_current_file_at_the_end_of`) which refer to the unmodifiable target.cpp. – Jarod42 Nov 02 '21 at 12:54
  • @Jarod42 Yeah, I read the line a few times but didn't get it. You are probably correct. `#extrude_into "target.cpp"` to really push it out? – Ted Lyngmo Nov 02 '21 at 12:54
  • Looks related: https://stackoverflow.com/q/34928933/1387438 – Marek R Nov 02 '21 at 12:55
  • If you want to be an early adopter, there are the new-fangled [**modules**](https://en.cppreference.com/w/cpp/language/modules) in C++20. – Eljay Nov 02 '21 at 12:56
  • 4
    Why? What problem this thing should solve? This is clearly [XY problem](https://xyproblem.info/). – Marek R Nov 02 '21 at 12:58
  • The problem is: the project is huge and there are files witch cannot be modified because of the company rules. So, I cannot write anything inside to a lot of cpp files but I want to write code as I could do it. This feature could save me a lot of time. Most probably I have to write a script that generate new files and concatenate with the new code and the old code too and put it somehow to the linker process as an exe. The project is really huge and can change frequently, so there is not a nice solution to write everything manually. Other code parts are also generated by string parser scripts. – Darffire Nov 02 '21 at 14:10
  • "Imagine a world where is a restriction for some file. Those are read only and there are a tons of them. You have to behave like you can modify it but you can't. There is 2 option. 1. is what I want in the main question, a cpp feature what can extend an existing code with built in builder functionality. 2. is when you write a code that makes totally the same that I wrote in the first point. So, I want to save time and do the "1." instead of "2.". That is not comes from evil. Most of time we use built in language elements instead of assembly code... – Darffire Nov 02 '21 at 14:16
  • *"there are files witch cannot be modified because of the company rules"* -- what you propose is an attempt to virtually modify those files without literally modifying those files. You're still trying to violate the spirit of the rules. If the rules are justified, your attempt will run afoul of the justification and probably result in some degree of disaster. So I advise against pursuing this path, but it's your choice. – JaMiT Nov 02 '21 at 15:10
  • What's wrong with creating a new source file and linking it with the others? (Adding a new source file to the build process should be at least as easy as getting the build process to look at your proposed "source.bpp" file.) – JaMiT Nov 02 '21 at 15:15
  • @JaMit Yes, I know, you are right but partial. If I just extend the files and not make anything witch could change the behaviour that sounds great BUT according to bureaucracy the whole code must be revalidated does not matter if the change is really just an extension with generated automatic code which is just 3 rows. Furthermore, some code files are not visible for me at the moment or maybe at the future but I for the focused feature I should write code which works as I would see those codes. – Darffire Nov 02 '21 at 15:25
  • @JaMiT So, yes this is not "sweeping under carpet" and will be communicated in details, but if this kind of solution works, then the revalidation will be faster or maybe avoided. In my level I have to prove all the technical standpoints and the possibilities with some research for the stakeholders. – Darffire Nov 02 '21 at 15:29
  • @Darffire OK, if that's really what you want. I think people are misunderstanding your intent, though. Would it be OK with you if I fleshed out your question with more details? (You could of course revert my changes if it turns out I also misunderstand.) I believe your intent is that you create a new file, and use this proposed `#outclude` directive to insert the new file into the build process, with the same end result as if you had added your code to the end of `target.cpp`. Is that accurate? – JaMiT Nov 02 '21 at 17:49
  • @JaMiT Yes, this is exactly what I want. #outclude is just a clickbait word, I hope that is not mislead anybody. That was the first world what comes to my mind as the opposite of "#include". We can call it "#extend" or whatever just the behaviour should be what I wrote. (The builder should be start always with the those files which are contain #extend keyword I think, but this is just a hint. Non deterministic behaviour is possible with this solution which is depends on the file linking order. Something extra flag should be nice which determine the linking order. Like #Extern1 #Extern2) – Darffire Nov 03 '21 at 08:52
  • *"The builder should be start always with [...]"* -- The build system is independent of the preprocessor, and if you could change the build system, your proposal would be useless. (Using the names from the question, if you could change the build system, then you could use `#include "target.cpp"` in `source.bpp`, then in the list of source files you could replace `target.cpp` with `source.bpp`.) I think that if you wrote out a more detailed description of how you see this working, you might see more difficulties in implementing this than benefits to be derived from it. – JaMiT Nov 03 '21 at 14:37
  • We are trying 2 different approach to solve the problem. 1. What you mention. So, with a CMAKE script we try to check all the source files and if any of them has a "bpp" file with a specific prefix then we will use the new file instead of the old. (The old file will include to the top of the new file.) 2. We try to list all function headers in to he new "bpp" file. Most probably it should be work correctly. (Like a header file with extra code that we originally want to insert to the old file.) – Darffire Nov 03 '21 at 16:48

1 Answers1

0

If you mean "opposite" of header as in something that you can include at the bottom of a file, then header file is its own opposite. That's because the "header" refers to how the files are used and not how they can be used. It is entirely possible to include a file at the bottom. It's just not very useful.

If you mean "opposite" of include directive that includes content into other files then no, there is no such directive in the pre processor. You could write a pre-processor of your own, but I don't recommend it.

I cannot modife some source code in the project but with these I could extend them.

I recommend to create new source files that you can modify.

eerorika
  • 232,697
  • 12
  • 197
  • 326
  • This is what I want to avoid. I want to sign to the builder to extend automatically those files (with specific code) which used with the "outclude" or "extending" keyword from other files. Most probably this is not exist at the moment and I have to write a script which make it, but could be a useful technical feature for the next cpp version. – Darffire Nov 02 '21 at 14:05
  • @Darffire I don't see a downside with using separate source files for the new code. Why do you want it to be inside the files that you cannot modify? – eerorika Nov 02 '21 at 14:11
  • Company rules. And I should do it automatically in a lot of files. That is a lot of time especially if I cannot write into those files and I have to copy to another. – Darffire Nov 02 '21 at 14:19
  • For example. I want to store a function pointer from a file and use in another global container but I cannot write into that file to store the function pointer. So, I have a string parser which can go through all the necessary files and generate new files with generated source code but I do not want to copy all the source code from the original file I just want to extend the original with my current one while I avoiding to write anything to the original file. (I just sign to the builder how to use the new files.) – Darffire Nov 02 '21 at 14:24
  • @Darffire `That is a lot of time especially if I cannot write into those files and I have to copy to another.` How is the amount of time different when making those changes in one file versus another? I don't see how the target file affects the time it takes to modify it. – eerorika Nov 02 '21 at 14:25
  • Those are generated by script. Yes, I can extend the script to do this, but that is unnecessary extra complication and the source files will opaque. Not proper way for long term. This project is 40 years old and will be used minimum more 30 years. This is why this feature would be nice here. – Darffire Nov 02 '21 at 14:44