|
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.
|
|
|
|
|
|
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
|
|
|
|
|
|
Your first link is bad.
I would not use system() to spawn a console app. Use ShellExecute() or CreateProcess() instead where you have (some) control over the ensuing window.
As far as WinMain() goes, see here.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
modified 9-Jun-16 9:12am.
|
|
|
|
|
It is impossible to guess what that code is supposed to be doing, or why it starts with a message box about a memory access error.
Please edit your question and explain exactly what you are trying to achieve. If this is just code from the internet that you do not understand then it would be better to contact the author.
|
|
|
|
|
Sometimes I just shake my head at answers offered ... anyhow moving on 
Basically your definition of WinMain isn't correct it has parameters and a call directive, it will look like an overloaded function in that form
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow){
I haven't done this in ages but you had a console app and are trying to turn it to a windows app so there will be a project setting somewhere. To be honest the fastest way to do this will be to set the project up from scratch. Delete all the files in your directory except the source files and stuff you made. Then goto "new project" and select your directory but make sure you select Win32 Application not Win32 Console Application. On the next screen click on the "application settings" and tick the box "empty project". Ok all that and you get an empty project.
Now on the source files entry in solution explorer simply select "add existing item" and bring your source files in as you need.
With the right WinMain you are then good to compile and all should be fixed.
If that all gets too hard here is one I prepared earlier Skeleton Windows App project setup[^]
In vino veritas
modified 9-Jun-16 4:21am.
|
|
|
|
|
leon de boer wrote: Sometimes I just shake my head at answers offered
I get much the same feeling with more and more of the questions posted here.
|
|
|
|
|
1.dev enviroment：VC++ 6.0
2.build program in 'release'
3.store 1000000 simple objects in CArray
4.run the program without debug
After running the code , it's about 85M memory cannot be release on my computer.
Can anyone explain and solve the problem for me? Thanks.
BTW：Because of the legency project code,my dev IDE is not allowed to update to the latest VisualStudio. So i have to solve the problem in VC 6.0 IDE.
#include "afxtempl.h"
long int g_cCount = 0;
long int g_dCount = 0;
class CMyTest
{
public:
CString m_str;
CMyTest()
{
m_str = "test string";
g_cCount++;
}
~CMyTest()
{
g_dCount++;
}
};
typedef CArray<CMyTest,CMyTest&> CArrayTest;
void Test()
{
g_cCount = 0;
g_dCount = 0;
CArrayTest testArray;
int count = 1000000;
for(int i =0;i < count; i++ )
{
CMyTest testObj;
testObj.m_str = "test string";
testArray.Add(testObj);
}
testArray.RemoveAll();
testArray.FreeExtra();
}
void CTestMemDlg::OnOK()
{
Test();
CString strInfo;
strInfo.Format("Object construction: %d destruction: %d \r\n",g_cCount,g_dCount);
AfxMessageBox("finish\r\n"+strInfo);
}
|
|
|
|
|
It's a long time since I did any MFC programming, but I suspect that the problem is the definition of CArrayTest. Try making this
typedef CArray<CMyTest,CMyTest> CArrayTest;
(no reference). This will cause every element to be copied into the array, but should work.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
I think you will find that RemoveAll will remove all the elements from the array but will not actually dispose them (i.e. call their destructors). Should be easy enough to test.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
