|
Hi everybody,
i added the function _putenv to my source code and now i have a linker error (LNK2019)
"Can't resolve external symbol"
_putenv is a system funtion of stdlib.h
How can i resolve this error?
Big thanks
|
|
|
|
|
rename your function.
Greetings from Germany
|
|
|
|
|
_putenv is declared in stdio.h i can't rename it...
|
|
|
|
|
Try to use
errno_t _putenv_s(const char *name,const char *value);
It is more secure
best of luck
Sivan
www.ktsinfotech.com
|
|
|
|
|
you have declared it and to use it you have to include the library here the "standard libraries" in the Linker
PS: I misundertood your question.
Greetings from Germany
|
|
|
|
|
I feel compelled to ask, why are you calling _putenv? what is it you hope to achieve here?
|
|
|
|
|
In a ConsoleProject i need to assign values to environment variables
(number of lines and cols)
I start a DOS-Console application via calling the Main of the DOS-Applic from out a MFC-Code
I even don't know if it's work, but i try it and see where it begins to crash
Because displaying a Console-Applic via starting a new process ( via the EXE of the Console )
and "redirect the display to a View of a Window" works already in a SourceForge and CodeProject Application
Now i try to start the DOS Applic directly without executing an EXE...
Or find the reason why it couldn't work
Have a nice day
|
|
|
|
|
Using Win32 has high performance but takes more development time.
MFC has low performance but development time is less.
Am I right and any more pros & cons
|
|
|
|
|
I think, one more thing is 'Size'. Size of the application will be more for MFC.
"a child will grow up to become an adult, but you can never stop the adult from acting like a child"
|
|
|
|
|
If you turn off GUI features MFC also gets as fast as Win32. If you really need performance you write a worker thread without GUI.
The signifikant time is for me the development time.
My bosses want almost the new features running next week.
Greetings from Germany
|
|
|
|
|
KarstenK wrote: My bosses want almost the new features running next week.
Wow, lucky you a full week
codito ergo sum
|
|
|
|
|
KarstenK wrote: If you really need performance you write a worker thread...
It's amazing how many folks think more threads equates to better performance.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
mandanani wrote: MFC has low performance
Why do you need performance ? Is it so relevant that you need to consider it ? Are you developping some 'time-critical' application ?
If no, why do you bother about performance ? Do you think the user will notice that your project takes 100 msec more to start ?
|
|
|
|
|
Please ask the questions like this.
I Always go for performance.
If i am creating the application which takes time 2 second to execute i will always try to minimize the time to even less than a quarter of a second.
Anurag Gandhi.
http://www.softgandhi.co.nr
|
|
|
|
|
So, to reduce the launching time of your application from 2 seconds to 1 second, you'll be ready to spend twice as much time for development ? Honnestly, it is a complete nonsense to me. And furthermore, your application will probably be much harder to maintain.
For a 'normal' application (I mean a standard desktop application), why do you even speak about performance ?
|
|
|
|
|
mandanani wrote: MFC has low performance
Rubbish.
Christian Graus - Microsoft MVP - C++
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
Christian Graus wrote: Rubbish.
Yeah... having been around a few years... I have seen the performance enemy.
|
|
|
|
|
Christian Graus wrote: Rubbish.
Finally, a rational post to this thread
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
|
mandanani wrote: MFC has low performance but development time is less
In most cases saving development time is the best option (and software reliability is even more valuable).
Moreover, IMHO, performace differences between MFC and WIN32 API are almost irrelevant for the average software developer (like me: I usually have to look for better designs and algorithms to improve the overall performance).
That said, I think that MFC is a good class library but you need to use it only if fits your needs, in other words, if you don't like the Framework, WIN32 API is an option.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
mandanani wrote: Using Win32 has high performance...MFC has low performance
What exactly do you think MFC uses?
Which part of MFC have you seen give worse performance than straight Win32 calls?
I'm not agreeing or disagreeing, but when I see this statement I want proof.
Most of the time it's just parroting what some uninformed peer has stated.
I'm calling B.S.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
As best I can tell, MFC is nothing but a convoluted "object-oriented" wrapper around the Win32SDK. My opinion is that object-orientation often serves to obfuscate functionality, hinder maintenance, and it certainly cannot improve performance any. If you look at the binary for a windows executable you'll see win32 sdk calls, not MFC. So for personal projects, why add another layer you have to learn which doesn't actually add anything.
It is worth noting that GDI+ is offered in its standard "object-oriented" guise as well as in a flat api. The same is true of the FreeImage Graphics Library. The Cairo graphics library, (which I highly recommend, BTW, along with FreeImage) is strictly a flat api and a model of lucidity. The web browser Mozilla uses Cairo instead of GDI+.
|
|
|
|
|
seem like folks had misunderstood me. I prefer to develop a project with MFC until and unless my boss compels. In fact bosses doesn't know basics of any languange.
This is just a question came to mind, and thought of getting all your valuable views
But MFC adds extra layer over Win32 and will have less (may be negligible to many ) performance to Win32. With MFC application can be written in fly :
Bottom-line those who love ooops prefer to use MFC and those traditional C programmers prefer Win32.
|
|
|
|
|
My project is the SDI project using CEditView.
And then I add another view(CFromView)in run-time to this project using CSplitterWnd.
The view can switch and work properly but the menu don't change follow view.
When I focus at CEditView I want to show the main menu and the other hand when I focus at CFromView I want show the another menu that come with the view.
How can I do this.
Please give me some link or article that can support this issue.
Thanks
Max
|
|
|
|
|
Change in the message WM_GETFOCUS or WM_KILLFOCUS your menu items.
Greetings from Germany
|
|
|
|