|
|
pix_programmer wrote:
Any other answers?
Thats is rude. I dont think I am going to get paid for sharing my thoughts with "your excellency". 
|
|
|
|
|
overloaded Name wrote: Thats is rude.
Actually that's not so rude, because your answer is apparently incomplete.
Veni, vidi, vici.
|
|
|
|
|
but I think it depends upon feature that a particular language supports.
Thats what I wrote in first line. I think I should have replaced this line with: "Features such as OOP". I just said a more generalize sentence. I assumed OP knew that C++ was named "C With Classes" at first, but was renamed later.
CPallini wrote:
Actually that's not so rude
OK That is rude to some extent. Yet I confess my answer may have been incomplete and did not help, so no more replies from my side.
|
|
|
|
|
Don't get offended. I was joking, after all.
However introducing iostreams like one of major C++ achievements it is a common mistake.
Veni, vidi, vici.
|
|
|
|
|
IMHO, the most compelling reason to use C++ rather than C is 'classes', allowing Object Oriented Programming (OOP). Classes makes code more structured, easier to write, understand and maintain (and more stable). This is important, especially with complex applications. Polymorphism and other features are nice extras but I wouldnt say to choose C++ just for these features alone.
|
|
|
|
|
The advantage of C++ over C is Object Oriented Programming (OOP). C++ supports OOP while C doesn't. That means you may write an OOP application in a fair clean and elegant way using C++ (you may write a C application following the OOP paradigms but your code would be more messy and your development time would be longer).
It is worthy nothing that OOP is not a panacea: it is best suited for rather big projects (say more than 100,000 lines of code) involving team of developers. Form smaller projects, in my opinion, OOP is overkilling and structured programming (the paradigm supported by the C language), is better.
Veni, vidi, vici.
modified 6-Apr-12 3:48am.
|
|
|
|
|
Spot on answer. 5!
==============================
Nothing to say.
|
|
|
|
|
Agreed on pretty much anything, except that I consider 100,000 lines rather small, and don't see any advantage in using C over C++ on smaller projects, as long as there are at least two developers working on it. OOP and the stricter syntax of C++ is great for avoiding errors based on misunderstandings of code use.
|
|
|
|
|
Stefan_Lang wrote: Agreed on pretty much anything, except that I consider 100,000 lines rather small
Well C and C++ are pretty concise languages.
Of course you may feel 100,000 'small' (I feel it 'large'), however, probably 10^5 is the right order of magnitude.
Stefan_Lang wrote: and don't see any advantage in using C over C++ <layer>on smaller projects, as long as there are at least two developers working on it. OOP and the stricter syntax of C++ is great for avoiding errors based on misunderstandings of code use.
I think structured programming is better than OOP for small projects.
You may use C++ (as 'better C') with the structured programming paradigm, of course.
Veni, vidi, vici.
|
|
|
|
|
in terms of program output, yes, C can do everything C++ does. but C++ makes OOP much easier.
|
|
|
|
|
you can do all the things in C itself(Constructor, Destructor,
Polymorphism,
Templates every thing is possible in C) -
All the things that performed by compiler you should do by yourself.(for example constructor - init, etc)
Templates may be the thing - that really hard to performed - but generally macro can be used
Why C++ Instead of C - some of the features realized and checked by compiler.
but from the other side for C there are - small footprint,speed and etc.
like assembler and C.
At the end it is binary code.
|
|
|
|
|
C++ is an object oriented (OO) programming language. C isn't.
OO has been widely accepted as a technological idiom hus it can be presumed to have merit. Arguments claiming it is popularity contest ignore the fact that there are many 'popular' technologies that have short runs and which are then abandoned or even outright condemned. So to the extent there is any objective criteria for picking a technology idiom OO seems to accepted as being better.
Although one can program using OO in C it requires a great deal more manual attention to detail and additional code than doing it in C++.
Both of those make it more likely that additional bugs will show up.
Even more worrisome at lot of that additional code will involve pointers. And pointer bugs in C (and C++) are some of the more difficult bugs to find and thus cost more to fix.
Of course one could just use structured programming rather than OO. Although having done OO for many years I find it extremely difficult to think in structured terms for anything more than trivial bits of code. And at one time I used to do structured programming so at least I know how to do it.
|
|
|
|
|
i have i3 processor and windows7 os
i installed dev c++ which not suport graphic while i m devloping some graphical app. plzzzzzzzzzzzzz sugest me what can i do for graphics.
|
|
|
|
|
Brijesh_kumar wrote: i installed dev c++ which not suport graphic
As far as I know that's not true, why do you think so?
Veni, vidi, vici.
|
|
|
|
|
|
In VC++ and MFC:
is it possible to find out that one or more Windows Explorer windows are open?
|
|
|
|
|
I think you could use the EnumProcesses() function as described in this sample[^].
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
I think that normally Explorer is permanently load in memory. My interest is that it opened a window or more windows,
|
|
|
|
|
Here is one way to do this -
Use EnumProcesses to enumerate all running processes.
For each process id returned, call GetProcessImageFileName to check if it belongs to explorer.exe
You will need to do OpenProcess on the process id to get its handle.
After you get the process id of explorer.exe, enumerate all open windows using EnumWindows.
For each window handle returned, use it in the function GetWindowThreadProcessId to check if it belongs to explorer.exe
This process of finding open explorer.exe windows could be time consuming.
Another way to do this would be to write a Browser Helper Object (BHO) which explorer.exe windows will load on startup.
In the BHO you can keep track of open explorer windows and more.
Here is some more information on BHOs - Browser Helper Objects: The Browser the Way You Want It[^]
Here is how to build a BHO using Visual Studio - Building Browser Helper Objects with Visual Studio 2005[^]
|
|
|
|
|
|
Hi,
You could create a ShellWindows object[^] and call get_Count();
Something like this:
INT GetExplorerCount()
{
LONG lCount = 0;
IShellWindowsPtr shell;
shell.CreateInstance(__uuidof(ShellWindows));
shell->get_Count(&lCount);
return lCount;
}
Don't forget to CoInitialize. Also keep in mind that Internet Explorer and Windows Explorer are integrated... you will need to add some code to filter out instances of IE. Control panel windows are also shell windows.
Best Wishes,
-David Delaune
|
|
|
|
|
I have dll where I am creating a dialog whihc is shown from the mfc client application. I loading this dll as an extension dll, then by implementing Do.Modal() function I am showing the dialog which has menus, toolbars,black model visualization screen. When trying to display this screen, it's crashing as debug ASSERT failed, at appcore.cpp
ASSERT(AfeGetThread()==NULL)
My App class is like this in the header file I have the App constructor and in .cpp file I have the construcor and also one instance of ViewApp as below
//MyViewApp.h
[code]
//Inside the class definition
MyViewApp(); //constructor dclaration
//outside the class definition
extern MyViewApp theApp;
[/code]
//MyViewApp.cpp
[code]
MyViewApp::MyViewApp()
{
}
MyViewApp theApp;
[/code]
It's crashing with this code (ASSERT failure in appcore.cpp), and when I am removing this constructor declaration and definition and also removing the one instantiation, then it's not crashing but coming out of the application, My Dialog GUI is not launching.
Please help me whats going wrong in this. Thanks a lot for help in advance.
|
|
|
|
|
My guess would be that you already have a CWinApp derivate instantiated while CWinApp (and so your MyViewApp since it is also a derivate of CWinApp) expects to be the one and only. Sad that in wincore.cpp there seems to be no comment whatsoever around those ASSERT-s to give you some additional information about what's wrong.
I suspect that you have MyViewApp inside the DLL and you are loading it into your application which already has a CWinApp derivate. If so, you should try displaying and handling your dialog in the "context of the original application".
Could this be it?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
how can I do that please give me some hint..
I have one api exposed for mfc client called 'runAppli'
[code]
__declspec(dllexport)runAppli(CString fileName)
{
CDlgsViewDlg dlg(fileName, NULL);
dlg.DoModal();
return true;
}
[/code]
Using this I am calling the dll after loading.
So how can I
displaying and handling your dialog in the "context of the original application".
Please give me some hints.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
