Compiler issues w/ VS2013

[jeremyerdmann]

Hi John,

Thanks for your work with this project. It's a bit young, but I like the direction it appears to be heading and it seems like it could be a nice fit for me and some of my peers.

I'm having issues building with VS2013 and am curious if that is meant to build in that environment or only VS2015 & VS2017. I get the following 3 build errors in Visual Studio 2013 (after updating to use the V120 compiler):

1. In src\power.h, it is looking for a declaration of uint64_t and not finding it. I am able to resolve by adding #include <stdint.h>, although that may not be the preferred way to go.
2. In src\private\pvoidvector.h, it is not liking typename on line 75. This seems to be the same issue as one you fixed days back.
3. In test\test_string_u16.cpp and test_string_u32.cpp, it doesn't like the STR macros (lines 40 in both). It doesn't like U or u (yield error C2065: 'u' : undeclared identifier).

I have fixes for 1 & 2, but am not familiar with Git enough to issue the right Git request for you to review and possibly merge if it makes sense (hence I'm opening an issue to notify you instead). It gives me a permission error when I try a "pull request", but perhaps I'm doing that incorrectly.

I don't yet have an answer for #3 yet (other than to exclude those 2 test files from the build). I don't understand the various 16bit and 32bit string variants to know if there is even a way to fix this with VS2013.

Perhaps of bigger concern, what is the best way to observe master functioning (without modifications). I'm not helping my cause by using VS2013, but I'm an embedded guy who doesn't update my Microsoft tools every year. If there's a quick start guide to get my setup configured the way you test, that would be awesome. I have a team of colleagues who are evaluating ETL as a potential replacement for our present home grown equivalent, but we'd like to know the PC test infrastructure can be built and run ideally without any modifications. Our embedded targets are typically ARM STM32s (using IAR tools) with the occasionally TI DSP (using CCS tools). I see the IAR support is very rough, we'd be willing to help beef that up a bit if we can convince ourselves that this library is in a stable state more often than not.

I'm curious about the Microsoft command line VS option (http://landinghub.visualstudio.com/visual-cpp-build-tools). I haven't looked into that much yet, but may peek as a possible resolution to my VS2013 woes. I'm only looking for a way to test what is checked in (and to possibly verify any fix I might propose before I issue a pull request back to master).

Thanks,

-Jeremy Erdmann

[jwellbelove]

HI Jeremy, I’m currently on holiday in Spain at the moment and I don’t have my usual tools to hand, only an underpowered netbook and a shared apartment WIFI connection. I shall be back in the UK in just over a week’s time. 1. Yes, #include <stdint.h> is the way to go. The other compilers probably indirectly included that header through one of the others. I should be able to do that small change from here. 2. Same as above, I should be able to address that from here, though I doubt I will be able to check whether it compiles OK. Can you do the mod and let me know if it’s all OK for your setup? 3. In the unit tests I’ve tended to use C++11 and above to make life a bit easier, but I can see your issue. The U/u is undoubtedly a newer edition to the language. I’ll have to give it some thought. Ideally I suppose I should write all of the unit tests using a C++03 compiler. Depending on your company size and turnover, it’s possible that you could use the community edition of VS2017 in parallel with your current setup. I’ve also been trying to keep a Code:Blocks/GCC version of the test environment up to date. I almost got the VS & CB projects synced before I left but had one last issue to resolve. I was also about to push a set of intrusive flat map/set classes. I didn’t push my luck though as I managed to screw up with Git the night before my last holiday and erased a lot of my changes in a merge I pulled from another PC! Thank God for backups! Re: IAR support. I would love to be able to test on IAR more often, but they don’t have a ‘free, code size restricted’ version like many other compiler vendors do, and I’m not currently prepared to buy their whole kit just to support them. Any heads up on incompatibilities would be much appreciated. The whole issue of checking compatibility with the myriad of embedded compilers on all of the target processors is a bit of a logistical nightmare, so I sort of have to rely on feedback from users of the library. I do currently have a guy working with TI Code Composer tools and with his help I was able to resolve a couple of compatibility issues he had. Thanks for the interest in the library. I intend to do all I can to support and resolve all of my end user’s issues. John Wellbelove. Aster Consulting Ltd. Sent from Mail for Windows 10 From: jeremyerdmann Sent: 24 April 2017 23:08 To: ETLCPP/etl Cc: Subscribed Subject: [ETLCPP/etl] Compiler issues w/ VS2013 (#25) Hi John, Thanks for your work with this project. It's a bit young, but I like the direction it appears to be heading and it seems like it could be a nice fit for me and some of my peers. I'm having issues building with VS2013 and am curious if that is meant to build in that environment or only VS2015 & VS2017. I get the following 3 build errors in Visual Studio 2013 (after updating to use the V120 compiler): 1. In src\power.h, it is looking for a declaration of uint64_t and not finding it. I am able to resolve by adding #include <stdint.h>, although that may not be the preferred way to go. 2. In src\private\pvoidvector.h, it is not liking typename on line 75. This seems to be the same issue as one you fixed days back. 3. In test\test_string_u16.cpp and test_string_u32.cpp, it doesn't like the STR macros (lines 40 in both). It doesn't like U or u (yield error C2065: 'u' : undeclared identifier). I have fixes for 1 & 2, but am not familiar with Git enough to issue the right Git request for you to review and possibly merge if it makes sense (hence I'm opening an issue to notify you instead). It gives me a permission error when I try a "pull request", but perhaps I'm doing that incorrectly. I don't yet have an answer for #3 yet (other than to exclude those 2 test files from the build). I don't understand the various 16bit and 32bit string variants to know if there is even a way to fix this with VS2013. Perhaps of bigger concern, what is the best way to observe master functioning (without modifications). I'm not helping my cause by using VS2013, but I'm an embedded guy who doesn't update my Microsoft tools every year. If there's a quick start guide to get my setup configured the way you test, that would be awesome. I have a team of colleagues who are evaluating ETL as a potential replacement for our present home grown equivalent, but we'd like to know the PC test infrastructure can be built and run ideally without any modifications. Our embedded targets are typically ARM STM32s (using IAR tools) with the occasionally TI DSP (using CCS tools). I see the IAR support is very rough, we'd be willing to help beef that up a bit if we can convince ourselves that this library is in a stable state more often than not. I'm curious about the Microsoft command line VS option (http://landinghub.visualstudio.com/visual-cpp-build-tools). I haven't looked into that much yet, but may peek as a possible resolution to my VS2013 woes. I'm only looking for a way to test what is checked in (and to possibly verify any fix I might propose before I issue a pull request back to master). Thanks, -Jeremy Erdmann — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[jwellbelove]

Hi Jeremy, Just a thought on point 2. The standard says that dependant types should have ‘typename’ prepended to the declaration. Earlier versions of Visual Studio were not strict about this and would accept declarations without it. If VS2013 doesn’t accept its presence then I may have to add some conditional compilation so that users of later versions of VS & GCC (and any embedded compilers that eventually support C++11) do not get errors. John Wellbelove Aster Consulting Ltd. Sent from Mail for Windows 10

[jwellbelove]

Hi Jeremy, Forget that last email, It’s a bit late at night here and I wasn’t thinking straight! The typedef is not a dependant type and of course doesn’t require the ‘typename’. John Wellbelove Aster Consulting Ltd. Sent from Mail for Windows 10

[GatorQue]

John,

Do you have any interest in using Travis CI and AppVeyor to test the code base? I have had some experience with these tools along with using Conan.io and could contribute this to the project to automatically compile each push against multiple versions of VS, Gcc, Clang, etc.

[jwellbelove]

They sound interesting. It would certainly reduce the workload testing cross compiler compatibility. John Sent from Mail for Windows 10 From: Ryan Lindeman Sent: 27 April 2017 04:38 To: ETLCPP/etl Cc: John Wellbelove; Comment Subject: Re: [ETLCPP/etl] Compiler issues w/ VS2013 (#25) John, Do you have any interest in using Travis CI and AppVeyor to test the code base? I have had some experience with these tools along with using Conan.io and could contribute this to the project to automatically compile each push against multiple versions of VS, Gcc, Clang, etc. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[jwellbelove]

Hi Jeremy, I remember (in the cold light of morning) now why I use C++11 and above in my test suites. Some of the ETL library has been revered engineered from components found in the post C++03 libraries. To ensure that the ETL versions are exact duplicates in form and function. I test the output against the C++11/14 versions. This would be difficult and error prone if I were to try to make the unit tests purely C++03. Sent from Mail for Windows 10

[jwellbelove]

I’ve made the first two changes in both the development and master branches. Sent from Mail for Windows 10

[jeremyerdmann]

Hi John, Thanks for the updates for 1 & 2. I'll do an update and check that out when I get a chance. I see your point on C++11 vs. C++03. The easiest option for me to verify the latest in master would be to simply buy VS2017. Unfortunately, my company is too big to legitimately use the Community version, and I'm not willing to sell my accountants on the cost of upgrading every time Microsoft releases a new version when I mostly use IAR for day-to-day work. Ryan's comment has some intrigue for managing the various configurations out there. I'm not at all familiar with those tools, and I would guess it might require some build configuration modification (e.g. I might look at the command line visual studio solution when I have a spare moment in case it might play into such a solution). One additional thought. It doesn't help for IAR, but TI's CCS is now free. A guy and I here recently set up our build to run it through the command line if there was ever a desire to integrate that as well.

…

-Jeremy

On Fri, Apr 28, 2017 at 11:49 AM, John Wellbelove ***@***.***> wrote: I’ve made the first two changes in both the development and master branches. Sent from Mail for Windows 10 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#25 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHhR8_cSBSyfKjSkxjJA6JWpxiuKaf1Aks5r0hisgaJpZM4NGxjl> .

[jwellbelove]

Hi Jeremy,

>The easiest option for me to verify the latest in master would be to simply buy VS2017. Unfortunately, my >company is too big to legitimately use the Community version, and I'm not >willing to sell my accountants on the cost of upgrading

On the Microsoft site it says... An unlimited number of users within an organization can use Visual Studio Community for the following scenarios: in a classroom learning environment, for academic research, or for contributing to open source projects. It would seem to suggest that you could use VS2017 Community Edition if you were to only use it for open source. One option I am also considering is to create a non-IDE makefile based option using GCC, which is of course, free. If you’d like to communicate other than via the GitHub ‘issues’ pages then send me a quick message via the ETL contact form and then we can email directly. https://www.etlcpp.com/contact.php What part of the world are you based in? Just so I can get an idea of how time-shifted we are. John Wellbelove Aster Consulting Ltd. Sent from Mail for Windows 10

[jwellbelove]

I had a quick try of AppVeyor, but it had issues due to the fact that the unit test suite I use is not part of the ETL project. I have added Unittest++ as a submodule and I will have to modify the ‘addition include‘ paths in the projects when I get back. Hopefully that will solve the problem. Sent from Mail for Windows 10 From: Ryan Lindeman Sent: 27 April 2017 04:38 To: ETLCPP/etl Cc: John Wellbelove; Comment Subject: Re: [ETLCPP/etl] Compiler issues w/ VS2013 (#25) John, Do you have any interest in using Travis CI and AppVeyor to test the code base? I have had some experience with these tools along with using Conan.io and could contribute this to the project to automatically compile each push against multiple versions of VS, Gcc, Clang, etc. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.