|
|
That one is you ... It is basically telling you it can't find the code for GetFloatInput.
GetFloatInput is defined in Input.H and Input.CPP which are included see here
#include <iostream>
#include "calculation.h"
#include "input.h"
using namespace std;
So we are down to either a typo error or you haven't included Input.CPP into your source files. I assume you cut and paste so unlikely to be a typo so lets try number two.
Did you use the menu system and do .... Project... Add files... to add the new .H and .CPP to your source files to the project? I don't use code blocks but it will be something like that.
Can I ask you to show me the line about the deprecated string function points to .. I am interested to see what GCC is complaining about.
There is possibly another warning you are going to get on the definition of main in Source.CPP can you change it from int main() to
int main(int argc, char**argv)
That is the technically correct definition, not the Microsoft shorthand I used.
In vino veritas
modified 15-Jun-16 12:50pm.
|
|
|
|
|
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;
int err = scanf_s("%hu", &iResult);
In vino veritas
modified 15-Jun-16 14:35pm.
|
|
|
|
|
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.
modified 15-Jun-16 17:27pm.
|
|
|
|
|
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.
In vino veritas
|
|
|
|
|
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...
how do i solve this?
|
|
|
|
|
lol i solved this....
i think glut was too old for my compiler ... so i downloaded freeGLUT and it worked
|
|
|
|
|
GLUT is deprecated on Visual Studio it no longer exists as a standard unit and is recommended not to use, which is what all the errors were about and why you needed to download freeGLUT.
In vino veritas
|
|
|
|
|
yea..
same is the case with codeblocks and bloodshed dev-cpp
|
|
|
|
|
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
|
|
|
|
|
|
If you don't know the answer by ur-self then keep quite.
|
|
|
|
|
|
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 you may want to review set theory
Set theory - Wikipedia, the free encyclopedia[^]
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.
In vino veritas
modified 12-Jun-16 5:18am.
|
|
|
|
|
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.
I'd rather be phishing!
|
|
|
|
|
We have 5 to 6 Fortran Libraries each of which contains at least 60 to 70 fortran source files (.for). These libraries are linked in an application developed in PASCAL language under Delphi 5 IDE.
Now, Since we want to redevelop the application using MFC, the Delphi Pascal application could be possibly redeveloped in MFC.
My question is...Is there any easy and quick way of converting the fortran libraries to C or C++ to be linked with the redeveloped application in MFC
|
|
|
|
|
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++.
|
|
|
|
|
The Fortran Libraries were built using Fortran compiler in visual studio 97 IDE in Winxp OS
As we had moved to Win 7 and later, We dont want to use the Fortran Compiler anymore. But the Libraries require periodical updations and rebuild.
Is that possible without conversion from Fortran to C++?
Please advise and provide any alternate suggestions if any.
|
|
|
|
|
I don't know if it is possible.
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>
#pragma comment(lib, "fortran_library_name")
extern "C"
{
void __stdcall some_fortran_lib_func1();
double __stdcall SOME_FORTRAN_LIB_FUNC2(double f, double *p);
}
int main()
{
some_fortran_lib_func1();
return 0;
}
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?
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++.
Please consider my above requirement too. How to do modifications and build library files from the Fortran library source without using Fortran compiler in VS97 setup?
|
|
|
|
|
manoharbalu wrote: What if I want to change the Fortran Library function code? Then do that.
manoharbalu wrote: 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).
manoharbalu wrote: 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++.
[EDIT]
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.
[/EDIT]
|
|
|
|
|
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.
In vino veritas
modified 9-Jun-16 10:56am.
|
|
|
|
|
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.
|
|
|
|