|
PIEBALDconsult wrote: Kids these days expect everything to be handed to them.
He is no kid 
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
unusable? I'm offended. 
Last week I was debugging some ancient FORTRAN, and it did just fine.
Seriously though, it takes a while for the muscle memory to kick in to remember the keypad commands.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
You are obviously hoopier frood than I.
The main issue I had was that I couldn't get the debugger to display the source lines involves. (DEC C)
"User error" I'm sure.
|
|
|
|
|
when you start moving source files to different places, sometimes the debugger cannot find what it needs - usually "set source <location>" takes care of the problem. Not that it will come up again...
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
Ah Turbo C. I miss thee.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Well, if you're used to Turbo C, try Embarcadero C++Builder, though I personally don't like the price tags anymore...
That's why I switched for my daily programming work to FreePascal+Lazarus instead of Delphi more than a decade ago.
|
|
|
|
|
I selected static library project, set the parameters that were given. It has everything to do with VS.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
If you selected 'static library project' it is set to CREATE a static library. It has everything to do with understanding VS. If you need one static library to depend upon another then you must understand how to add the dependency to VS. Setting the project type does not make it recursively able to link to other projects of that same type. I believe you would have had to add the dependency to Borland products in a similar manner. (At least I recall having to do so in the past - just the extension differed if memory serves. Or COFF vs LIB, or something.)
And, logically, it is more common for an executable to link to the libraries, not one library to link to another. I've never heard of nested libraries, but I suppose it is possible.
|
|
|
|
|
It makes a lot sense to nest libraries.
I have used that approach many times. Everyone has.
My Font library uses GLFW library to handle rendering.
The font library is used by a higher level application to
handle I/O to screen.
My biggest problem with VS is that it cannot see my includes files and libraries.
Grrr.
#include <glfw glfw3.h="">
fails not matter how I reference that the directory it is located in. D:\code\glfw3.3.8\include
NOT A TYPO ANYWHERE
VS BAD
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
jmaida wrote: My biggest problem with VS is that it cannot see my includes files and libraries.
The steps for each step are outlined in the article I linked to. After dragging the include files into VS you must still specify the paths in the include section of the project settings, and you have to set libraries in another place in the settings as I outline there. Pretty simple once you understand it, but learning that was not as simple as it could have been - I agree with that. It would be nice if dragging a file into the explorer automatically added the appropriate path to the settings, but would require looking at relative paths as well as absolute, since both are acceptable in the project settings page.
|
|
|
|
|
Typo in the post
it's
#include GLFW/glfw3.h (with <> brackets. If I explicit put them this post incorrect displays them)
which VS flags with red underline of #include which is the signal it cannot find the file
even though I have the complete path
d:\code\glfw3.3.8\include in the additional includes field of the applications properties
and it is a valid path to the required file
VS says it cannot find the file
and recommends I use some strange application called vcpkg to install it
Like I say VS ______s
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
If you read my post, I said to use quotation marks around the include, not '<' and '>', so #include "somefile.h". There is a big difference. And don't put an '=' or a ' ' inside the include file (so not #include "somefile somefile.h=""" - just #include "somefile.h". It isn't VS - it is GIGO.
|
|
|
|
|
tried that quotes still no go
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Like Jeremy, I can guarantee it isn't something on VS's end. It is responsible for more pieces of software than you or I can count to in a day. It must be something on GLFW's end with malformed headers. Does the header immediately include another header that is at another location? Is that malformed? Go that direction or another with GLFW taking responsibility, quit blaming VS.
Build the code in my article on your end and go through all the instructions. Then create a GLFW project starting one file at a time without using any CMAKE or any other shortcuts. You will figure it out that way. You will never figure it out just by blaming VS.
|
|
|
|
|
I will. Thank you.
I blame VS because
1. Have 2 copies of exactly the same C file.
2. Put them into VS "exactly" the same way (here is where the rub is, because VS makes that more complicated than it should be as "exactly" is not what has happened)
3. one works fine, the other does not.
4. Did a difference on .project files. Not "exactly" the same. That is what I am trying to resolve.
If it is user error then shame on VS for making it easy to do.
"A little time, a little trouble, your better day"
Badfinger
modified 23-Jan-23 16:02pm.
|
|
|
|
|
Find the main header that controls everything. Make a single VS project with just that. Comment out all of the included headers. Even comment out the code. Get that to compile. Then uncomment one header and get that to compile. Etc. etc. If it is a big project it will take quite a while. I have gone through a process like that before. It wasn't fun, but I found the stupid effing mistake. It was my own mistake.
|
|
|
|
|
doing so as we espeak.
BTW reading your article too.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Here is a suggestion. Stop ranting about something you are having problems with. Go to https://www.codeproject.com/Questions/ask.aspx[^] and post the full details, so people can try to help you. And make sure you check what you post, so you can fix any typos, and ensure that all code snippets are surrounded by the appropriate <pre> tags so it is readable, like:
#include "somefile.h"
int main()
{
printf("Hello, World!");
return 0;
}
Tags used in the above case are:
<pre lang="C++">
and
</pre>
|
|
|
|
|
Thanks Richard,
When I can compile more specific details I will do so. I have some weird problem where VS compiles the same simple C file (single file) with two different results. It's a test file from vendor's web site that uses their libraries.
Very good suggestion. A helpful one that I should have used right off. I have even suggested in the past to others. Oh well.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
jmaida wrote: VS compiles the same simple C file
No it doesn't. You need to understand the difference between Visual Studio (an Integrated Development Environment) and the C language compiler and the object linker.
|
|
|
|
|
I know the difference, Richard.
I select the same compile option in VS IDE for each C file in VS editor.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
I think I have figured it out.
Something to do with project properties and whether one has code selected or project selected. They look very similar expect one has linker options. The "additional includes" are showing blank in project properties even though I have set them in project properties when code file is selected.
Very confusing. It was the includes that giving me different results between the two C file projects.
These additional includes do not always resolve the include in code.
Plus a user error in the path, but I corrected them only have them come back later.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
I favor your pain. VS does things to help that simply are never documented.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
PS - #include <someHeader.h> - the '<' and '>' included headers indicate that they are in the compiler's PATH (or something like that - files like 'stdio.h' and 'vector's (without the '.h' suffix) in .cpp). #include "someHeader.h" are for files included via the projects settings includes. I have never came across the ="" nomenclature - my first instinct is to tell you to ditch it and use the "" include method. But I'm not an expert on that - all I can say is what I've done has always worked.
|
|
|
|
|
jmaida wrote: #include <glfw glfw3.h="">
fails not matter how I reference that the directory it is located in. D:\code\glfw3.3.8\include
NOT A TYPO ANYWHERE
Apart from the fact that the include statement is totally incorrect.
And again, that is nothing to do with Visual Studio, but one for the compiler. Well, strictly speaking, it's the preprocessor, but we'll let that pass.
modified 23-Jan-23 5:21am.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
