Excellent. Working fine now however I have to remove scanef_s. that _s was creating problem so i only remove _S and scanef remain as it. Now code working fine. Thank you for ur guidance. Now i got the clear idea how to write the code. I will copy the way you wrote this code. I am not a bad student however I like programming but problem is I think i am unable to think like a programmer. I am trying hard for that but no success yet I want to excel in this field but sometimes I stuck
We all get stuck at times It is really pleasing to see you are willing to apply yourself to learn. None of us are born able to think like a programmer it is like any profession something you get good at by application of lots of time and effort.
Your long single file code is sort of normal basic student level code, it works in a fashion. You are now seeking to move beyond that and I can only encourage that. All I did was really shorten up your code by making functions with more parameters and putting in error checking for things like typing letters instead of numbers etc. There are improvements you could do by using objects or classes but that is more stuff you are yet to learn.
I looked up the problem with scanf_s it is they have changed security with this, you now need to use "%hu" rather than "%u" as meaning a pointer to an unsigned short. That tells you how many years since I have written code for a console application
So there are two fixes to remove the warning correctly
unsigned short iResult; // Define iResult as unsigned short not unsigned int
int err = scanf_s("%hu", &iResult); // Use %hu this should be error free on GCC
You are right. i am completely new and it was my class assignment number 1. I finsihed it and submitted it already but then I came to know professionals never write everything in main that's why i decided to search in this direction. By your improved code I can see a boundery wall is set for wrong inputs. Which i wanted to set in my project as well but was not sure how to set those powerful boundaries as you set. I want to excel in this game of programming, I am not an extera ordinary student but i will keep on trying it day by day
Following are few things I extracted from ur code which I am going to follow for the next time code or will at least try my best to do similar things. Correct me if I observed wrong. I did not follow the following things in my code. If I missed any point then point me that as well.
1) You are using braces by giving one space and starting 1st curly brace in-front of the statements like while and if.
2) All variable you wrote in small letters and to make them more clear u out _ sign to link them.
3) Function name 1st character and then the 2nd meaning name of function is capital.
3) 1 step indentation on each step involving in some kind of computation.
4) You used unsigned when you feel that value are in +ve.
correct on all counts, you have correctly identified that the standard makes the code much more easily readable and helps you identify errors. I enforce the standards at our company and I therefore never write without using that standard. The standard we use is essentially an extension of C99 or sometimes called ANSI-C standard and is used heavily in the sector I work, which is embedded programming.
Companies in the game market you are looking at tend to use C++ (UNREAL GAME ENGINE etc) or C# (UNITY GAME ENGINE) and there standard may differ slightly as the majority of the code won't be C compliant, and they have other pressures for readability. So generally in large companies you will be expected to write to a standard and there will usually be a process to check code into the active repository.
So while learning coding try and have your own standard but just remember you may have to adapt when you are employed. The company is not going to rewrite an entire repository to your standard even if you could argue it was better. So my standard is not the "absolute best" it's just a standard I would generally have to write to at work.
i need to set up glut on my windows machine.
i have glut.h in the include\GL folder , libglut32.a in the lib folder and glut32.dll in the windows\system folder
i compile as follows:
g++ -Wall main.cpp -mwindows libglut32.a -lopengl32 -lglu32
i also have the windows.h , gl/glut.h and gl/gl.h included.
and actually my compiler is tdm-gcc (mingw64)
it gives me lots of errors like:
undefined reference to _glutmainloop...
What is the main reason even till day-today there is no boundry condition set for C++. Why not compiler resist that we are pointing something out of the range of our array or we are pointing to a memory location which we cannot points to as it is not in the allowed range of our source code. Why not C++ creator or the IOS committee which build the standard put a check on this thing. There must be some reason of this freedom to point anywhere. I want to know that reason why they are doing like this. If a person like bjarne stroustrup can write such an advance programming language then there must be something special he left this imporant check to move in memory anywhere. If you know about this please share with me. I am curious to know the logic behind it. I asked this question from my teacher but instead of answering me he said this is not a part of my course I am new student to programming
You are assuming that there are ordered limits to the set and that boundary has meaning. In a nutshell you seem to be inferring that sets are something like ordered numbers. It's a construction class so lets expand it to the general form, I have a set I called animals in which I inserted an chicken, a pig and a dog.
I now have a Lion is this inside or outside the boundary condition of my animal set? Do you see the problem with your question? What if I told you that my animal set was domestic animals does that change your answer?
Do you get that even if I have a set of numbers in a generic set, those numbers are just place holders for "things" such as animals ... they aren't really numbers like you are using them.
So the correct answer is if you want boundary conditions on your set because there is some logical order to them, then extend the class yourself. That behaviour is not natural to a generic set class so why would you expect it to be in a generic set class. Nobody has ever asked for that behaviour because it's wrong under set theory, as you are making some very specific sorted or ordered set.
It sounds an awful lot like you're asking - why does a fast and powerful language like C++ not have one of the performance killers of languages that require less skill to use.
Simply, because with C/C++ you're given the power to shoot yourself in the foot. If you do so, it's your own stupid fault, not that of the language that lets you do it.
If you have an array of a million elements and you wish to access each of them, you're expected to know that you're not trying to access an element before or after your allocated memory. The alternative is to assume you have or will screw-up and to perform 1 million bounds checking operations. No - that's not cool. That's a nice feature for sub-par programmers.
Also, hassan syed1 - it's Bjarne Stroustrup, not bjarne stroustrup. You capitalized your own name but thought his not significant enough to afford him the same respect?
It does offer boundary condition, just use modern C++ constructs (vector, array, string...) instead of their unsafe C equivalent (pointers, char*...)
If you are using a modern version of Visual Studio, there are additional checks made by the compiler and runtime to check boundary conditions (Security Features in the CRT[^]) and also they offer a set of safer runtime API (all the _s functions like strcpy_s instead of strcpy)
Remember that if the language let you shoot yourself in the foot, there is no excuse try not to by following best practice when coding.
There might be no need to convert the libraries. It should be sufficient to create header files defining the exported functions and the calling conventions and linking the MFC application against the libraries.
Depending on how the libraries has been build, you may also try to rebuild them using options for C/C++ access. Your FORTRAN compiler/linker documentation should have some information about building libraries to be accessed from C/C++.
When using an old Fortran compiler with a newer C/C++ project, the libraries must be build as static libraries.
It depends also on the dependencies of your Fortarn libraries. You can use the Dependency Walker (depends.exe) Home Page[^] to load your Fortran DLLs and check which other dependencies exist. If there are some, you might have problems because those might refer to quite old DLL versions.
You can check it using a small test project:
#include<stdio.h>// Link with library. Copy library to build path (debug / release),// specify full path here, or add path of libraray to project settings.#pragma comment(lib, "fortran_library_name")
// Functions exported by fortran_library_name and used in this program.// Note that function names may be all upper case.// The function name may be also exported with a leading underscore.// You can see the names in the DependencyWalker.void__stdcall some_fortran_lib_func1();
// Another example with Fortran code// REAL*8 FUNCTION SOME_FORTRAN_LIB_FUNC2 (a, b)// REAL*8 a [VALUE]// REAL*8 b [REFERENCE]// b = SQRT(a)// SOME_FORTRAN_LIB_FUNC2 = a * a// ENDdouble__stdcall SOME_FORTRAN_LIB_FUNC2(double f, double *p);
// Print result here if functions returns a value or modfies parameters return0;
Use the above code snippet to try first with a simple function (few parameters). If that works proceed with all functions declaring and testing them for correct results (I assume that most - if not all - are just doing some calculations).
What if I want to change the Fortran Library function code?
Then do that.
If I have to change it in the Fortran Library source and rebuild in the old setup, then I require to change all my Fortran Source to be converted to C++.
Why? As long as the function return type or the parameters are the same there is even no need to touch the C/C++ code (provided that you can import the library created by the old compiler as suggested by me).
How to do modifications and build library files from the Fortran library source without using Fortran compiler in VS97 setup?
That makes no sense. To compile Fortran code you need a Fortran compiler.
If you want a more recent Fortran compiler without paying for it you can use GNU Fortran[^] which can be also used with Windows.
If you don't want to use any Fortran compiler, you have to rewrite the code in C/C++.
There is no "easy" way. Even when using some kind of automatic conversion you have to do some manual work and check if the results are identical to the original version. This often requires understanding what the functions are doing. Then it is better to do the conversion manually too.
I am going to interrupt here because Jochen may be misleading you, while not meaning to.
While he has shown a simple function with a double in out etc that is all nice and easy like he has indicated because they are all standards in both languages.
The thing that gets a bit fun is if your interface exchanges has string, multi dimensional arrays and variant records and the like which he hasn't mentioned. So do you have any pascal specific structures being exchanged, stuff your Pascal compiler would have known but C++ doesn't have. For example your pascal string the first byte is the length and then the string data follows with no ending #0 character so C++ will crash and die if you interface that as a C string, you have to marshal it. Any multi dimensional array will similarly be backwards row major in C++, column Major in Pascal/Fortran. Complex numbers are another thing that doesn't exist in C++ so if you have them on the interface they need special handling. If you have Pascal/Fortran variant records you will need structures with unions and packing control with C++ and a lot of marshalling. Probably look at the library interfaces and write out all the different types exchanged on the interface as a start.
So it's exactly like how you link it to Delphi but sometimes C++ will have no idea of the type you are exchanging, unlike Delphi which natively knows them as the languages share the type definitions.
There is also an added complication we need to talk about, your library files will be strictly ANSI and strictly 32 bit to link. If you select 64 bit complilation and unicode or wide character set on the C++ compiler you will not be able to link the old libraries, they would require what is referred to as a thunk interface which would have to be then written.
Since your existing libraries can be linked, you need not convert them all at once. However, if you really do intend to abandon the Fortran compiler, then convert them you must, eventually. However, C++ and Fortran are enough alike that the conversion may be simpler than you think. For instance, the control structures should be fairly straightforward. While you may have to visit each one briefly, I suspect that a lot of the conversion can be handled by editor macros or Perl scripts written around regular expressions.
If the libraries use PRINT and FORMAT statements, all of which will need to be completely rewritten to use something like sprintf(), you may not be able to do quite as much with automation, though I would explore it. It's been too long, and I've forgotten most of what I once knew about FORMAT statements, but it's quite possible that you can accomplish much of that conversion with regular expressions, too. Along that line, since they are essentially literal constants, consider replacing the FORMAT statements with #define macros or string resources, so that they incur little or no runtime overhead. There is a trade-off between #define macros and string resources.
A #define resolves to a constant that is baked into the code, and costs basically nothing to use.
A string resource requires a Windows API call (LoadString) every time you need a new pointer to the string. If you set your character set to Unicode and null terminate your string resources, LoadString can return a pointer to the string, right where it sits. There is a resource compiler option, settable in the project configuration, to null terminate your resource strings. Otherwise, you need a buffer of up to 4097 TCHARs to hold each string. Better yet, let MFC look after all of that by using its CString class, which even sports a LoadString method that looks after the memory for you.
Another potentially thorny issue is COMMON blocks, either blank or labeled. Blank common is essentially process global storage that must be externally linked, and is usually easiest to define as part of the source file in which main() is defined. If there are also labeled COMMON blocks, consider putting each into a static class. Regardless, the actual common block definitions should go into header files. If you surround them with preprocessor guard code, you can define the common blocks and the routines that use them in the same header. Using the guard code lets you get away with defining the same common block in two or more headers, even if the same program includes all of them.
To be able to advise you I need to know a couple of things
1.) Are we talking Fortran 77 or Fortran 90 code in the libraries and what complexity on exchange interface.
2.) How closely are you trying to mimic the functionality of the Delphi Application.
For point 1 there are some real complexities in linking Fortran 90 libraries to C++ as most of the advanced features are more closely related to Pascal than C++. Things that will give you nightmares are things like multi dimension arrays in column-major order, variant data fields require special conversions and any strings exchanges. So conceptually the linking of the libraries is easy but if the exchanges out of the Fortran libraries are complex the problem turns to a nightmare. So it's pretty much the same as linking them to Pascal but there are less consistency with datatypes used in the languages.
With point 2, I would first question why you want to use MFC and C++ for that matter? Delphi is much more structurally similar to C# this will give you the idea Delphi vs. C# comparison | vsChart.com[^].
C++ is a level lower than Delphi, so what I am wondering here what is driving the want to bring the development onto C++. Don't get me wrong if you have a good C++ programmer they can easily convert it but the exact mimic of the framework well that is another story. I wrote the complete clean room copy of the Borlands objects unit that is in FreePascal (you will find me on the credits). I have also actually written a mimic of the whole Delphi 3 framework in C++ for an application I needed to exactly mirror and it took me just under 2 years. So is this being driven by a programmer wanting to make this choice or is it just a thought bubble.
I have similar reservations about MFC. It's still "current" and "used" but even Microsoft has now released it as free to use in VS2015 as it's commercial value is receding. Commercially most would select a different framework and to do that you start asking yourself do you need cloud access and the new technologies. If you don't need these you might select MFC but there are other choices.
In vino veritas
Last Visit: 31-Dec-99 19:00 Last Update: 26-Feb-21 20:33