0

Currently creating a header file, and using the ifndef, define, endif, etc to create it.

However, every time I create it, Visual Studio Code is throwing errors.

#ifndef _roundemup_h_
#define _roundemup_h_

#include <iostream>
#include <fstream>
#include <string>

void file_name(std::ifstream &input) 
{
    std::string filename;
    while (true) 
    {  
        std::cout << "Please enter a file name: " << std::endl;
        getline(std::cin, filename);
        input.open(filename);
        if (input.is_open()) 
        {
            break;
        }
        std::cerr << "Unable to Process File." << std::endl;
    }
}

#endif

Current errors being show:

the #endif for this directive is missing[1,2]
unrecognized preprocessing directive[24,2]
expected a declaration[25,1]

I'm copying this from a header I've made from another program but have changed the header name and ifndef, so you would think there would be no issue?

jake
  • 23
  • 2
  • 6
  • 1
    Just a side question: why are you defining a function in a header file? – lurker Oct 08 '19 at 23:25
  • 1
    Since this is a header file, you'll need to show the context in which it is included in any source files. Simplify the problem to just one simple source file including the header, if you have multiples, to narrow the problem down. – lurker Oct 08 '19 at 23:27
  • to be honest, I'm not really to sure the reasoning or theory. My professor has said if you have multiple functions, define them in a header and call them into the main.cpp or implementation.cpp. It's feedback that has been given to me prior. – jake Oct 08 '19 at 23:28
  • 2
    Your professor may have said to *declare* them in a header, not *define* them, or may have meant *declare* but said *define*. There is a difference. You would just put `void file_name(std::ifstream &input);` (with any includes it needs) in the header, then include that header in any module that uses the function. Create a separate module to define the function body, or define it in an existing module. – lurker Oct 08 '19 at 23:30
  • Maybe don't get *too* hung up on the code-in-header issue, bods. It's not what I would consider best practice but it's not really relevant to the question at hand. – paxdiablo Oct 08 '19 at 23:39
  • I agree: the code-in-the-header isn't the issue, just a side conversation. I would still like to see one example of a source file that includes this header that exhibits the error, just to see the include in context. – lurker Oct 08 '19 at 23:45
  • Interesting fun fact: `_roundemup_h_` is an illegal identifier. For more on that, read [What are the rules about using an underscore in a C++ identifier?](https://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier) – user4581301 Oct 08 '19 at 23:45
  • @user4581301 does that apply to `#define` symbols, or actual variables, functions, etc? The Gnu C++ compiler has no issue with the OP's example. – lurker Oct 08 '19 at 23:49
  • Oddly enough, a came back to my Mac a few minutes later and the errors seemingly went away... I dunno if Visual Studio Code's IntelliSense took awhile to read through it or something underlying was hung up but it wasn't throwing an error in the "Problems" section. Also, thanks @lurker because I wasn't too sure why he was having me do so much in a header when a lot of books or examples use implementation files? So I guess I will try doing what you said. Also the main.cpp isn't fully written yet so it's why I didn't post it. – jake Oct 08 '19 at 23:51
  • @lurker Identifiers in general if I've been reading the standard, [C++17 at any rate](https://timsong-cpp.github.io/cppwp/n4659/lex.name#3), correctly. Unfortunately the Standard states no diagnostic required, so the soonest you're likely to know you broke a rule is when the identifier collides with something in the library implementation and suffers a painful and confusing death. – user4581301 Oct 09 '19 at 00:10
  • @user4581301 thanks for the link. If I read it right, an identifier that begins with an underscore is not stated as illegal but potentially reserved for the global namespace. So it's only an issue if the user chooses a name that happens to collide with one that's pre-defined. – lurker Oct 09 '19 at 00:33
  • @lurker Yes-ish. The reservation is overly broad because A) it's next to impossible to tell if you're going to hit something buried in the deep-dark of the library implementation until you hit it and B) You can't really even count on "Didn't hit anything" because you're one toolchain upgrade or port from potentially hitting something. You can't easily have the compiler reject all underscore-misuse because it still has to compile library headers where these identifiers are legal and would have to know which headers are and are not library headers. – user4581301 Oct 09 '19 at 00:45
  • A case where Nuke the Site From Orbit truly is the only way to be sure. – user4581301 Oct 09 '19 at 00:46
  • @jake For what it's worth, I copied your sample code, and my compiler did not complain. If it happens again in the future, you might want to erase the line and retype it. (Or, apparently, go take a walk and/or restart Visual Studio.) – JaMiT Oct 09 '19 at 00:46

1 Answers1

1

It seems clear that the compiler is first complaining that the endif is somehow deficient. First step should be a hex dump of the file to see if there are any weird characters in there, or a missing newline.

If in Linux, you can use something like:

od -xcb myfile.h
paxdiablo
  • 854,327
  • 234
  • 1,573
  • 1,953