Home Bug Reports

C++ Include Directives

rmerriamrmerriam Member Rud MerriamOrganization: mystic lake softwareProject: Entry in NASA 2013 Sample Return Robot Centennial
The way Slice generates the #include directives in C++ is not correct.

The #include<> form of the directive is used to reference system files. By Slice using it for all include files it requires developer to explicitly declare more paths for include files than is required.

The #include"" form is the correct form Slice should be using for include files that it generates directly (hello.h) and, probably, the ones generated from the cpp:include meta statement ("cpp:include:GridCoordinate.h"). That does get tricky if the developer includes something like "stdio.h" but will not generate errors.

The intent of the different include statements is to allow the compiler to skip searching local directories for system files (stdio.h). But it also, as mentioned above, simplifies the include path declarations since the "." directory does not have to be specified.

Otherwise I have been impressed by the proper usage of C++ in the system.

Comments

  • D. FleuryD. Fleury Member David FLEURYOrganization: ConsertoProject: GSM Capture
    rmerriam wrote: »
    ...
    The #include<> form of the directive is used to reference system files.
    ...

    Are you sure of this ? (do you never use some libs others than reference system files ?)
    Using #include <> is not related to reference system file but more on include list specified on command line for example. There are a lot of differences on compiler interpretations for <> include, better to check your compiler documentation.


    Anyway, I was encountered an issue more or less related to this thread.
    In my slice, I use the
    #include <MyLibs/File1.slice>
    #include <MyLibs/File2.slice>
    

    but in the C++ generated files, the path are removed, I have
    #include <File1.h>
    #include <File2.h>
    

    Is this behaviour correct ?
    Because I have to add ".", ".." and each time for each parts of my project into the include list
    (instead of only ROOT/MylLibs sometimes).

    Sorry to have vampirized this thread for my own need... but still related (I will create a new one if needed)

    Regards,
    David
  • cepsteincepstein Member Caleb EpsteinOrganization: Volant TradingProject: Options Trading System
    D. Fleury wrote: »
    but in the C++ generated files, the path are removed
    See the documentation on Include Directives.
  • cepsteincepstein Member Caleb EpsteinOrganization: Volant TradingProject: Options Trading System
    rmerriam wrote: »
    The way Slice generates the #include directives in C++ is not correct
    Totally disagree. Treatment of angle-brackets vs double-quote include directives is implementation defined according to the standard. Conventionally angle-brackets are used for system includes as well as additional libraries that might be used (e.g. Boost). But developers are free to
    #include "stdio.h"
    
    if they like.

    Slice2cpp-generated code may be used both within a project as well as without (e.g. as an external library), so its not fair to say that either approach is more correct. Both will work, and I personally find the angle-bracket convention more typical.
  • D. FleuryD. Fleury Member David FLEURYOrganization: ConsertoProject: GSM Capture
    cepstein wrote: »
    See the documentation on Include Directives.

    Probably thanks, I will see if the last part help me.

    Edit : After some tests, I still have an issue. The include line generated in the .h is not the same as the one generated in the .cpp file.
    The .h include <MyLIbs/File1.h> but the .cpp file include only <File1.h>

    Edit 2 : I add --include-dir and solve my issue. Thanks.
  • D. FleuryD. Fleury Member David FLEURYOrganization: ConsertoProject: GSM Capture
    cepstein wrote: »
    Treatment of angle-brackets vs double-quote include directives is implementation defined according to the standard.

    Can you point out where this is in the standard ?

    C++98, 16.2, par 2 : How the places are specified or the header identified is implementation defined,

    the same for "" include.

    May be C++11 is more precise than "implementation specified"
  • cepsteincepstein Member Caleb EpsteinOrganization: Volant TradingProject: Options Trading System
    D. Fleury wrote: »
    Can you point out where this is in the standard ?
    You just did it yourself!
  • D. FleuryD. Fleury Member David FLEURYOrganization: ConsertoProject: GSM Capture
    cepstein wrote: »
    You just did it yourself!

    I missed read your answer. My english in not as fluent as I wish.
  • rmerriamrmerriam Member Rud MerriamOrganization: mystic lake softwareProject: Entry in NASA 2013 Sample Return Robot Centennial
    Stroustrup??
    D. Fleury wrote: »
    Can you point out where this is in the standard ?

    C++98, 16.2, par 2 : How the places are specified or the header identified is implementation defined,

    the same for "" include.

    May be C++11 is more precise than "implementation specified"


    Page 201 in Stroustrup's "The C++ Programming Language" 3rd Edition clearly states that the <> form is for "standard library files".

    Page 231 in Kernighan & Ritchie "The C Programming Language - ANSI C" 2nd Ed. clearly states the same information. They comment on "implementation dependent" with respect to the <> form to indicate that there is not a standard location for the "standard libraries".

    See Preprocessor directives - C++ Documentation which I realize is not the standard but certainly a definitive resource.

    It clearly is conventional behavior for <> to NOT search in the source directory while "" does.
  • cepsteincepstein Member Caleb EpsteinOrganization: Volant TradingProject: Options Trading System
    rmerriam wrote: »
    It clearly is conventional behavior for <> to NOT search in the source directory while "" does.
    But there is no requirement that the generated headers live with the source code that includes them. I build libraries of Slice-generated code and link to those from separate libraries and applications, and I'm sure others do as well.
Sign In or Register to comment.