|
SLOOOOOOOOOOOOOOOOOOOOOW (and that is on a dual 1ghz system).
Now what is this about classes having to be dynamically linked etc? Did the linux compilers do something really stupid and add extra overhead to C++ classes? C++ and C bindings should use the same mechanism with just slight variances in calling standards.
Tim Smith
Descartes Systems Sciences, Inc.
|
|
|
|
|
Well, KDE apps are classes to the core, as a result there is a lot to link up - a lot more than in a C app. The standard linker does and excelent job of what it's supposed to do, but it's not optimized for this everything-has-to-be-dynamically-linked situation.
I'll refer you to: http://www.suse.de/~bastian/Export/linking.txt -- that will explain it a whole lot better than I can. The immediate hack for 2.2 is to get apps that are mostly pre-linked.
I forget what's going on with 3.0 to fix this, but it is a issue being fixed for the next version.
I'm looking forward to evaluating 3.0 before I declare any real architecture issues.
|
|
|
|
|
Hmm, I wonder why this isn't a problem on Windows, or at least why nobody really bitches about it.
I totally forgot about the vtables which is why I didn't see why C++ would be slower. But of course, if the image is not based (or fixed), then the vtables would have to all be patched. Maybe that is why it isn't a big problem on Windows, many images are based.
Thanks for the info
Tim Smith
Descartes Systems Sciences, Inc.
|
|
|
|
|
I believe this to be because Windows is C based. True there are C wrappers (MFC) and such that just wrap the C libraries. As a result, there is a whole lot less low-level linking. (You're looking at 2-3 layers instead of about 7-9, IIRC and very small and few vtables.) Linux (KDE) developers, need not just to be correct, but poetic too, so everything is a class. This unfortuneately results in a lot of linking.
Well, partly answers your question. The other answer is because of "Quick Launch" apps. (Which has also been proposed for KDE) These apps clutter your bar, add time to your boot sequence, and pre-load the libraries for the application. So Windows isn't quite as fast as it seems either
|
|
|
|
|
You missed the point of my reply entirely.
This the is Visual C++ message board. Since Visual C++ is ONLY available for Windows, it would be completely correct to assume that everybody that moniotrs this board does so in the interest of Visual C++.
Kindly keep the linux discussions to the lounge or Rant/Rave.
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
This isn't entirely correct.
The situation is complicated by the aforementioned WINE and the fact that the VC++ sudio can be used as a nice editor for any C++ application on any OS.
And pardon me, but I really resent the fact that you attempt to censure this board as such. Let the lack of knowlege by members of the board be the force that makes people look for answers elsewhere, if there isn't the knowlege here to begin with. You will not stop me from helping people if I know the answer. If you wish to censure the board, maybe you should install some sort of moderation system.
One off-topic post really shouldn't warrent censure. Are you worried about pissing off the sponsors?
|
|
|
|
|
This is very easy question to answer.. for you.
Since you're of the C++ persuasion, go with KDE. It is C++ oriented, built with C++ and suffers from C++ problems.
If you were of the C persuasion, go with GNOME. It is C oriented, built on C and suffers from C problems.
I know bindings exist so you can use either in either, but it's best to stick with what it started from.
From the little bit I've looked into writing apps for these two, KDE looks a lot easier because of the classes.
|
|
|
|
|
If you want to earn any money, forget desktop programming for Linux. Linux has less than 5% of share on desktop PCs.
I vote pro drink
|
|
|
|
|
Was he asking about desktop programming or just which desktop is the best?
Tim Smith
Descartes Systems Sciences, Inc.
|
|
|
|
|
Well, he asked
"What is the best/prefer X (Gnome, KDE, etc.) for developers (C++)?"
I thought he meant programming for Gnome, KDE, etc, but who knows?
I vote pro drink
|
|
|
|
|
Good point.
Tim Smith
Descartes Systems Sciences, Inc.
|
|
|
|
|
Hi,
Checkout below site and tell me your idea about it
http://www.winehq.com/
My month article: Game programming by DirectX by Lan Mader.
Please visit in: www.geocities.com/hadi_rezaie/index.html
Hadi Rezaie
|
|
|
|
|
Hey, thanks guys. I appreciate the reponses.
Tim Smith made an interesting point about Linux X applications running slow. I find that to be true. I find some programs in Linux start slower than a similar if not more robust programs running in XP.
Second, I believe most developers prefer GNU C++, but I find that it takes may a fraction of a second slower to compile than Borland C++ Builder 5.5 and VC++ .NET. Again, maybe that is just an illusion because I use GNU C++ in console mode.
As for X, I have always used GNOME when I installed Red Hat and Debian. I did not know developers use C for GNOME and C++ for KDE. That is good information.
Kuphryn
|
|
|
|
|
Hello,
I am using an example posted in a article by Michael Dunn (I have modified it a bit to fit my needs).. Here is the sample of code that I am using..
void CConsoleView::OnCustomDraw(NMHDR* pNMHDR, LRESULT* pResult)
{
NMLVCUSTOMDRAW* pLVCD = reinterpret_cast<NMLVCUSTOMDRAW*>( pNMHDR );
*pResult = CDRF_DODEFAULT;
if ( CDDS_PREPAINT == pLVCD->nmcd.dwDrawStage )
{
*pResult = CDRF_NOTIFYITEMDRAW;
}
else if ( CDDS_ITEMPREPAINT == pLVCD->nmcd.dwDrawStage )
{
COLORREF crText;
long nItems = GetListCtrl().GetItemCount();
while(nItems > 0)
{
if(!GetListCtrl().GetItemText(nItems-1,7).Compare("Stopped"))
{
if (long (pLVCD->nmcd.dwItemSpec) == nItems-1 )
crText = RGB(255,0,0);
}
else
{
if (long (pLVCD->nmcd.dwItemSpec) == nItems-1 )
crText = RGB(0,0,0);
}
nItems--;
}
pLVCD->clrText = crText;
*pResult = CDRF_DODEFAULT;
}
}
The problem that I am having is that the first 2 columns do not get repainted.. the rest of the list gets colored perfectly.. Any ideas?
Thanks,
Rob
|
|
|
|
|
Unfortunately I don't know the solution, but why don't you use
int nItems;
there's no need to use a long
modified 12-Sep-18 21:01pm.
|
|
|
|
|
When I used a int and did the (pLVCD->nmcd.dwItemSpec) == nItems-1;
The compiler was giving me a warning (something like sign/unsign)so I looked it up on MS and they said it was a known bug and to declare my int as a long.. this seemd to fix the warnings.. But even when I used a int it still was drawing funny..
After the list is drawn if I click on the item that was drawn and then click off of it.. it is then drawn correctly.. Maybe I need to GetFocus or something..
I'll play with it some more.. if anyone else has any ideas I would love to hear them.
Thanks
Rob
|
|
|
|
|
Well, since this drawing code is executed for every single item I think it's not neccessary to use a while()-loop.
Give this code a try, however, it is untested:
void CConsoleView::OnCustomDraw(NMHDR* pNMHDR, LRESULT* pResult)
{
NMLVCUSTOMDRAW* pLVCD = reinterpret_cast( pNMHDR );
*pResult = CDRF_DODEFAULT;
if ( CDDS_PREPAINT == pLVCD->nmcd.dwDrawStage )
{
*pResult = CDRF_NOTIFYITEMDRAW;
}
else if ( CDDS_ITEMPREPAINT == pLVCD->nmcd.dwDrawStage )
{
COLORREF crText;
if(!GetListCtrl().GetItemText(pLVCD->nmcd.dwItemSpec,7).Compare("Stopped"))
crText = RGB(255,0,0);
else
crText = RGB(0,0,0);
pLVCD->clrText = crText;
*pResult = CDRF_DODEFAULT;
}
regards
Gregor
modified 12-Sep-18 21:01pm.
|
|
|
|
|
Your code works fine.. It seems to do exactly the same thing as the loop.. I'd rather use your example vrs the loop, your example is much cleaner..
But the darn thing is still not drawing the correct color on the first 2 columns.. But if I click on the item and click off it draws correctly.. or if I scroll the first 2 columns out of the view of the list and scroll them back into view they are drawn correctly.
Weird..
Rob
|
|
|
|
|
really weird...
put the line
GetListCtrl().Invalidate();
after
*pResult = ...
This should redraw the listbox, but usually it needn't be called
Maybe it helps
modified 12-Sep-18 21:01pm.
|
|
|
|
|
Yeah, I tried that yesterday.. Unfortunatly because of how often I update the list it causes it to flicker so bad that I cant read anything..
I really do appreciate all your help
Rob
|
|
|
|
|
Thanks
Well, one more try:
You could Invalidate() your control, after all items have been added.
If you add the items via a loop you could call Invalidate() after the loop has finished
modified 12-Sep-18 21:01pm.
|
|
|
|
|
Actually I put the Invalidate inside of my Populate function.. and this worked great!!
Thanks for all your help!
Rob
|
|
|
|
|
When I'm debugging a DLL that uses DirectShow, and I make a call to OleCreatePropertyFrame, the program produces an access violation (0x00000005) and all i get is a window with this:
00000000 ???
00000001 ???
00000002 ???
00000003 ???
00000004 ???
00000005 ???
00000006 ???
...
...
FFFFFFFF ???
One of the lines is highlighted, but it also reads "???".
What the heck have I done to get this? How do I find out what's really wrong?
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Seems like execution has jumped to the low area of virtual memory. Maybe some callback that has not been properly set?
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Maybe, try to delete a object twice, or use the object had been deleted
|
|
|
|