Home >> Support Board

Support Board

Date/Time: Wed, 15 May 2024 06:35:32 +0000

How to Post a Message for Support

Post From: Using Visual Studio C++ to create Custom Studies

[2020-11-07 16:06:18] Link To Thread - Link To Post [Go To First Post]
User972768 - Posts: 166
And here are some of my tricks that I use: 1) If you build something more complicated than Moving Average line, don't use "Remote build". I highly recommend to use Visual Studio (VS). I have Visual Studio C++ 2019 Community Edition (which is absolutely free for single developers, it lacks some team-related functions as a result, but that's fine). My VS 2019 is configured to use C++17. 2) I recommend you to use full power of C++ language and package actual study calculations into C++ class(es). Use ACSIL mostly to manage your class and let Sierra present results of calculations. This is perfect example of MVC model (model-view-controller) where your class(es) is/are the "Model", ACSIL is the "Controller" and Sierra is the "View". With this approach my studies have just 3 functions / procedures: - entry point (scsf_) - procedure to set defaults (the one called at sc.Defaults) - (optional) dynamic memory manager where I allocate / release memory for my class objects You might still have a question why do I do it this way, while Sierra support folks say tons of negative words about Visual Studio, its complicated way of doing things, etc. First, Sierra folks admit to use Visual Studio themselves. I agree with them that configuration of this monster is a bit complicated comparing to GNU text-file based environment for make and ld. But after you configure VS, you rarely come back to this area of the interface. Second, VS nicely integrates with Git (I recommend to use "Git Extensions" as VS Addon and as a standalone app). These 2 pieces of software allow you to use full functionality of Git with many functions available right from VS menu. Start Git repository as soon as you get first iteration of your study working. Start Git repo from VS, this way it will be properly configured to track changes in your code as well as configuration of the solution / projects. Why Git is important in any software development deserves separate thread, but in just few words: "you really really really have to use it" Third, Using "Remote compilation" through Sierra interface has a lot of disadvantages versus VS. To name few: - remote method statically links a lot of libraries (eg, STL) and makes you DLL huge while you might have just 100 lines of code in your study - you can't debug your code like in VS IDE interface with step-by-step, conditional breakpoints, etc - it is very painful to remote compile your study if its source code is divided into multiple files (.h, .cpp, etc) - you can't add functionality of extra libraries (eg, boost, zlib, etc) Fourth, If you detach your core calculations into classes, then you can write unit tests (eg, C++ Google Tests). This brings HUGE benefits and time saving in your development: - with test cases you can create specific data sets to test your code against, and then it takes less than a minute to run tests against dozens if not hundreds of test cases and see if new change in code breaks something that you didn't guess before. Or if you know that new change will break something, but you don't know extent of this breakage. In few words, you will see EXACT effect of the change and weed out all unexpected places much quicker - running test cases doesn't involve Sierra application and its dreaded cycle of "Release library - Compile - Allow DLL load - Test". Yep, you can say here that there is UDP call to do it more automatically, but it is still a big pain in the neck and still is VERY time consuming - you will never beat quality and time of automated tests by doing manual testing by opening specific moments in the charts that cover some test cases - if you come across some new edge case(s) where your study produces incorrect results, you just create new unit test; make sure that it fails with current code; fix code; make sure that you unit test is succeeding now - rule of thumb says that unit tests usually have 1.5 - 3.0 times of lines of code comparing to what they test (eg, 100 lines of code of your class might have 300 lines of tests to have good coverage of basic functionality and all edge cases). There is even a modern paradigm: "test-driven development", where you develop unit test and then build code that will produce expected results Fifth, Last but not least. Using Visual Studio, you can nicely split your code into many manageable files. In my example, I've build multiple Sierra Custom Studies libraries and some of them have more than 6000 lines of code. Instead of scrolling through huge multi-thousand line long single file, I have many files with biggest of them no longer than 300 lines. Each of my studies live in their own file. They have headers in separate files. Each class is in its own file. Each unit test follows the same structure. Please be warned, that it might be a bit painful to setup Visual Studio to produce Sierra Custom Studies, but the time spent doing it will well worth it. In the end you will get very nice environment. Date Time Of Last Edit: 2020-11-07 22:02:56*