TCLib example for Patrice

[James C. Fuller]

Patrice,
  I doubt very much you can live without STL but here is a C++/TCLib example using my version of Fred's TCLib (included).
You cannot use the Visual Studio IDE. All compiling is done from the command line using the included batch file.
TCLib.lib kernel32.lib user32.lib are the libraries linked by default from the batch file.

Give it a go!

James

[Mike Lobanovsky]

You cannot use the Visual Studio IDE.

But why not? Actually you can! 

Below is a VS2013 Ultimate solution for TCLib and ForPatrice01.CPP. A similar one can be used in VS2015 too; just change the C++ toolset in the project General Configuration properties from v120 to v140 and add the compiler /Zc:sizedDealloc- option unavailable in VS2013.

The project compiles with warnings (Strings.h/.cpp seem to redefine a lot of VC common stuff and they also use "deprecated" functions) but without errors. The resultant executable (get it in the \VS2013\x64\Release subfolder) is exactly as large and functional as the one generated with your batch file.

[James C. Fuller]

Mike,
  Thank you. That's what I get for supposin'.
No use to me as I don't use the ide but might get Patrice started.

James

[Patrice Terrier]

Patrice couldn't understand this type of dialog code 

Couldn't get it to work on 2015, nor with my VS Pro 2013.

...

[James C. Fuller]

Patrice,
  I was able to create a VS2015 community version.
I created a VS2015 folder in the JCFULLER folder and copied the files from the VS2013 folder to it.
I right clicked on the JCF.sIn and opened it. It updated to VS2015 and I was able to build the solution.
  Now I am curious, and would like to know how to create a new solution from scratch preferably the sdk version not the rc versiom. Mike?

James

[Mike Lobanovsky]

@James:

No problem. Below is the ForPatrice02 solution with the SDK version of the file. It is exactly the same as the RC version except:

• its JCF project refers to the 02 versions of source and resource files; and
• it references two more LIBs in its link stage: gdi32.lib and comctl32.lib.

Creating a solution from scratch is pretty straight forward:

• create an empty C++ solution;
• add the existing CPP file(s) to the Solution Explorer's Source Files section;
• add the existing RC file to the Solution Explorer's Resource Files section;
• if you aren't planning to edit the header files and they are appropriately #include'd in your CPP file(s), then you may omit adding them to the Header Files section of Solution Explorer; and
• if your resources (like e.g. the manifest file) are appropriately referenced in your RC file and you aren't going to edit them, then you may omit adding them to your solution.

Then just open up your batch file, select your project in the Solution Explorer, goto your PROJECT->Properties->Property Pages dialog from your main menu, and looking in your batch file's compile and link options, try to find the matching entries and settings in the Property Pages dialog's Configuration Properties->C/C++ and ->Linker options. Note however that the Property Pages options are not 100% exhaustive and there are always some compiler/linker options that you will have to add manually to the appropriate <edit...> fields in the respective entries. E.g. while you can set the /STACK: reserve[,commit] option directly in the linker settings, to the best of my knowledge there's no option for the /GsNNNN stack size parameter, which you will have to add as an extra in the Additional Options entry.

Make sure to click the Apply button if you've just changed some setting or option before you proceed to another page in the Property Pages dialog! If you don't do that then your changes will not be reflected in real time in the All Options and Command Line summaries of respective C/C++ and Linker sections of this dialog.

(James, this isn't a .SIN file, it's a .SLN file - as in "solution", not "sin"...  )


@Patrice:

I don't know what your problem might be in either one of your Visual Studios. It's a valid VS2013 solution without any Ultimate or Professional specific dependencies so it should also be usable even in the VS2013 Community mode. And if you try to open it in VS2015, then the first thing Visual Studio is gonna do will be asking you to upgrade it to the VS2015 format, which in fact will boil down to promoting its declared toolchain from v120 to v140...

[UPD] The zip below has been updated with cleaner, more precise solution project settings (see my Replies #7 and #9 below). Please re-download.

[Patrice Terrier]

This one works, and creates a 13kb exe binary. 

[Mike Lobanovsky]

Great! This is exactly how large (or in fact small) James' original executable is when generated with his batch file.

As an afterthought (a.k.a. "did you know..." a.k.a. "tip of the day"):

• you will probably be able to avoid the compile-time "deprecated" function warnings if you add the following extra macro to your Property Pages->C/C++->Preprocessor Definitions: _CRT_SECURE_NO_WARNINGS;
• even if you aren't (accustomed to) using VS solutions to compile your C++ projects, you may still find it useful to i) create a dummy solution for your project; ii) add its files to the appropriate sections in the Solution Explorer; and iii) add your existing .BAT file as a TOOLS->External Tools... facility in your VS main menu. In this way you will be able to enjoy VS' automatic highlighting, formating, and intellisense facilities for editing your source files while preserving total control over the build process via your own generic batch file. Just be sure to avoid the BUILD menu and instead, use your proprietary External Tool to create your project with.

[Patrice Terrier]

I have already removed all the warnings 

Or just add this at the top of the main section
#define _CRT_SECURE_NO_WARNINGS

and in the
Preprocessor Definitions _UNICODE;UNICODE;%(PreprocessorDefinitions)
to get rid of the WINVER_WIN32_WINNT_VISTA invalid macro definition.
and use (long) or (int) in front of all _tsize that are affected to int.

and

Code Select Expand

bool String::blnSuccess() {
    BOOL bRet = FALSE;
    if (this->blnSucceeded) { bRet = TRUE; }
    return bRet;
}

[Mike Lobanovsky]

I have already removed all the warnings 

That's cool, Patrice!

However:

• We agreed to create a valid solution, didn't we? We could define all preprocessing directly in the main CPP file through macros and pragmas but we should set the solution environmental options properly instead.
• With a view to Item 1, _CRT_SECURE_NO_WARNINGS is all right but it should be moved out of the CPP file and into Preprocessor Definitions _UNICODE;UNICODE;%(PreprocessorDefinitions).
• WINVER=_WIN32_WINNT_VISTA and _WIN32_WINNT=_WIN32_WINNT_VISTA should be left in their places with equal signs added (I did overlook them when copy-pasting though). After all, they were defined by the original author and these environmental variables may probably be still meaningful for proper linking against the library.
• C/C++->Code Generation->Runtime Library should be set to Multi-threaded (/MT) static library compilation. This will remove the DLL warnings.
• You shouldn't enforce your casts where the author has not yet had their say. Probably James or Frederick would first explain why their own parameter definitions were so lax as compared to what's expected in VC? In the meantime, the executable will perform as expected even while the remaining few warnings are still outstanding at compile time.
• I've replaced my original JCF4PT_02 submission with the new one where the above faults have been fixed. You can re-download it from my Reply #5 above.

[Frederick J. Harris]

There never really has been much doubt in my mind that TCLib could be utilized within Visual Studio.  Just not by me.  I'm the kind of person that's willing to put just about any amount of work into solving an intriguing programming problem if I think there's any chance at all of solving it, but when it comes to fighting IDEs, I just don't have much patience.  The sorts of things I had to do to achieve the kinds of radical size reductions I wanted are kind of unusual in the extreme, and I always knew VStudio would fight tooth and nail 'agin it.  And it takes all of about one minute to create a folder, paste a few files in it, open a command prompt window to it, and execute a command line string or batch file.   And one doesn't end up with piles of crazy directories full of crazy files.

There are more sinister aspects to all of this too, which I'm only just beginning to realize.  I don't know if its still there, but years and years ago Petzold put on his site an essay something to the effect "Does Visual Studio Make You Go Brain Dead" or something like that.  He picked up on it before anybody. 

Occasionally I've posted code in various C or C++ Forums which folks can't get to work because of the file redirection that goes on when executing through the Visual Studio IDE, what with all the folders and subfolders it creates.  Of course, there are all kinds of setting within the IDE where these kinds of things can be modified, if a body wants to take the time and expend the aggravation to figure it out.  If expending an hour of your time to save yourself one minute is your cup of tea. 

Using the IDEs for coding and project organization is fine for me.  I particularly like Notepad++ and CodeBlocks.  I'm sure there are other good ones too.  I had to give up on Visual Studio as an editor because I code on batteries a lot with my laptops, and Visual Studio eats through a battery in no time.  At least that's my experience.  Just my opinion.   

[Mike Lobanovsky]

Hi Frederick,

James and I initiated all this to get Patrice attracted to the project. Otherwise he wouldn't use TCLib for the life of him, without a decent VS solution appended.

[Frederick J. Harris]

There's another one of those thingies like CRT_SECURE_NO_WARNINGS something to the effect NONCONFORMING_SWPRINTF I occasionally need to use.

About the /MT thing.  It really has no place in the command line compilation string if linkage with TCLib is the goal, as its effect is to tell the build system that static linking with the C Runtime libraries is the goal, which is quite antithetical to the use of TCLib, whose goal is to eliminate the C Runtime.  However, it seems OK to keep it there as within TCLib itself there is a :NOEFAULTLIB switch which seems to cause the build system to then ignore the /MT switch. 

[Mike Lobanovsky]

No Frederick,

NODEFAULTLIB has already been there. Yet we need an /MT switch too because we can't avoid either /MT or /MD in the project settings. VS does have its own glitches but still it has its benefits too. (I'm personally more used to Code::Blocks and GCC too but having the honor of working with Patrice on a few common projects, I've been getting used to Visual Studio as well even if somewhat reluctantly, I must admit. )

[Frederick J. Harris]

James and I initiated all this to get Patrice attracted to the project. Otherwise he wouldn't use TCLib for the life of him, without a decent VS solution appended.

I was wondering why I hadn't heard anything from Patrice about his success or failure with TCLib.  I always felt it would help him achieve some size reductions with his code.  I don't personally do any heavy duty graphics coding like Patrice is famous for, but my limited understanding of it is that such usages rely exclusively on Windows Api code.  And I suppose some graphics libraries involving Direct X and so forth.  If those other libraries require loading the C or C++ runtimes then it might not work.  Only recently (last week) I came upon my first encounter with something I couldn't get TCLib to work with.  It was SQLConfigDataSource(), which is in odbccp32.lib, which is the ODBC Installer library.  I occasionally make use of that function to create Microsoft Access *.mdb files on the fly.  Try as I might I couldn't get it to work.  Don't know why.  That's one I did give up on.

But when I realized from reading here that Visual Studio was the culpret, I was about to go searching for Patrice's C++ rendition of the Address sample all of us were playing with a couple years ago in investigating PowerBASIC DDT verses SDK code.  I always wanted to test that with TCLib, but just haven't been able to find the time.  My guess is that could be done in 22 k or so x64.