Only works one way. This way there is no way to ask netscape about anything. Specifically there is no way to tell which page it is displaying at present. Since I had to render in a specific named frame that knowledge was critical. Hence I had to go through the X properties. What I had to do is improvise a two way communication and I also had to find out which if any netscape windows were available and connect to the existing one or fork a new one if none were available then make sure that every time i sent data to it it still displayed the frameset that I had told it to display (user input could have changed that state). Otherwise refresh it with that frameset.
Again, believe me it was all simpler and much more elegant and under Windows. When you have two way IPC it gets _much_ more complicated with fork(), system() or X properties that the simple dealing with COM's IWebBrowser interface.
Of course all you said in this thread is correct and to the point. And yes COM/DCOM is a great implemantion of object technology that is much more suited to desktop development than anything that *nix has achieved so far (and that includes Corba).
I had a dubious pleasure to implement a class that talks to IE on Windows and to Netscrap 4 on *nix platforms. The IE bit is about 40 lines to implement the class whereas the Netscape one is well over 600! And all it does is opens a browser and sends it a URL and tells it which frame to use. The Windows implementation is inherently more robust because of the simpler, more standard way of doing things.
However, slashdot is not a place for reasonable technical discussion anymore. It's a gathering of zealots and trolls who won't listen to sensible arguments because they never had a need to talk to a web browser from their own code. Why not? Because they never wrote a single line of code and hence they know fuck all about programming.
So my plea to you TummyX is to go away and post your comments on a forum that still has developers on it not just bored high school kids. Let this forum live in its own well misinformed hype driven little world.
You went to explain a lot of thing here but unfortunately you are wrong about most of them. Let's go over nice and slowly shall we?
It'd be difficult for the toolkit to go about making decisions about what should have focus, and being wrong about that could be dangerous.
Neither of these is true. The initial focus needs to go somewhere and if you have an input field with an OK and a Cancel button on a single window it is quite desirable for the input field to have the focus FIRST. After all most of us input the data and then press OK not the other way round. So in certain cases it is dead easy to tell which widget takes the initial focus and in most cases the tab order is obvious too.
Blame the author, not the toolkit : )
This is exactly what the initial poster did. The subject of this thread is GNOME not GTK+. Besides I share the initial poster's view: GNOME w/o the mouse is completely unusable. KDE on the other hand has a full keyboard support. I use it without the mouse (yes that's right my computer doesn't have a mouse!). And the only troublesome application is Netscape but even they have some keyboard support. Gnome and Mozilla have NONE or have it in the places where the programmers were arsed to do it which is just as useful as not having it at all.
The function names are hardly longer than those in many other toolkits.
Don't know about this one but good C++ usuually yields much more succinct syntax. Consider the theretical example:
plain C context:
struct rect { int height, width; };
struct circle { int r; };
int getRectWidth(struct rect* r); int getCircleWidth(struct circle* c);
USAGE:
void rectFoo(struct rect* r) { //need to reserve space for the shape: int w = getRectWidth(r); }
void circleFoo(struct circle* c) { //need to reserve space for the shape: int w = getCircleWidth(c); }
C++ context:
class Shape { virtual int width() const= 0; };
class Rect : public Shape { int width() const {/* implementation of width for rect */ } };
class Circle : public Shape { int width() const {/* implementation of width for Circle */ } };
USAGE: void foo(const& s ) { //need to reserve space for the next shape: int w = s.width(); }
Hopeuflly you can see straight away which syntax is shorter and more elegant in this case. And this is a trivial example of a common problem in a GUI toolkit. To abstract a set of items so they can be used more generically. The C names are longer because more information has to be conveyed. Unless you are willing to resort to void* hell you have to have two different functions in C to deal with two different shape types. C++ has only one and if the names are chose in the way they should be the flow of the code is more logical too. Back to the main topic though...
The casts help insure correctness.
Since when are casts used ot insure correctness? Do you know what cast are? They are a sign of sloppy coding in C++ and a necessary evil in C because C doesn't support polymorphism. Casts don't insure anything. They are type conversion enforcements that are brute force compiler directives which force it to treat one type as a different data type. To continue our shape example in C this is a C "generic" getWidth function:
void getShapeWidth(void* shape) { int w; if( isRect(shape) ) { w = getRectWidth((struct Rect*)shape); } else if( isCircle(shape) ) { w =getCircleWidth((struct Circle*)shape); } }
If you like this sort of approach you should spend less time reading slashdot and more time reading your OO course.
And as for C++... it's a great language, but it's a lot more difficult to link against other languages.
Here you are either grossly misinformed or you bought into the (misinformed) slashdot crowd views. Ever heard of extern "C"? It gives you _exactly_ the same functionality as C. binding to C++ code is no more difficult because the same linker is used for C++ and C. C++ decorates function names to allow for overloading and that's what extern "C" prevents. It allows C++ to import/export plain vanilla C functions. Naturally you can't overload the functions exported in such way but that's logical because you've removed the decoration from them.
I'm sure if you look through the linux kernel archives, you'll see why C++ is discouraged in the kernel
Did you? I did and the main technical one was that Linus is a C coder.
low level libraries, like libc... have to be developed in C because they are an integral part fo a *NIX system. It's a part of the spec! Nothing to do with size or efficiency.
I think using C for GTK+ was absolutely the way to go.
Fuck the Karma and develop your own views. Learn about both languages and try doing at least one significant project in each. Just because Miguel De Icaza said that C rulez doesn't mean it holds true for evey situation in every case. In fact for what he chose to develop C very much sucks and he either realized it already or will realize it in the future.
Lesson finished. Go home get some sleep and get those C++ books out and look again but beyond chapter 2 this time. Good luck.
...Some more spin doctoring from Euro telcos. It is as 'free' as a ride on a bus that charges you per mile of journey.
This thing has existed in most EU countries for a few years now and has been used by all the Telcos as an argument against introducing unmetered internet access. It is a pile of crap because in most EU countries local phone calls are around $0.03 per minute. Figure out how "free" that is for yourselves. Besides, offering you that "free service" is actually quite profitable for the free ISPs since they get paid by the the telecos when you use their dial in numbers (they get a share of your per minute charge). Go to CUT to see what kind of deal we really get with the European ISPs.
I agree with you entirely. In fact I'd like to expand your point a little here. Far too many people get frustrated with C++ because of the poor grasp of the language. However, it is not their fault entirely. Good C++ coding can take considerably longer to learn than good C because of the sheer size of the language. But there is a more fundamental reason for C++ vs C flamewars. This has to do with the fact that programming requires a very unusual mixture of qualities: a high degree of creativity and a lot of attention to detail. Most programmers have these two features planted in their brains in a reasonable quantity but they never have a perfect 50% balance.
On one end of the scale we have the abstractionists who think in terms of the big picture design and 'see' projects in terms of components that interact with each othere. They are easy to spot in meetings because they are always the ones that tend to draw lots of UML and convoluted design graphs and they don't talk to people who haven't read the Gang of Four.
On the other end of the scale we have 'bit fiddlers' (sorry i find this expression rather amuzing). These guys tend to worry about the low level implementation details and often think in terms of actual lines of code and often ignor the design issues. They are very good however, at spotting design flaws that make the implementation hard.
Now, the problems lies not in the fact that we have these two groups of coder (see which category you fall into) but because these groups don't interact with each other very well. The abstractionists find it irritating that the implementationists don't see the 'big picture'. On the other hand the Bit Fiddlers get frustrated because abstractionists tend to overlook implementation issues. However, it takes both groups for a healthy software engineering project to thrive in my opinion.
What I find is that abstractionists tend to like and 'get' C++ more because of the natural gift of abstracting their ideas. The implementationists prefer C because they live in a constant fear of what happens 'under the hood'. That's why they lean towards C. Having said that you do find abstractionists coding graphics pipelines and implementationists writing C++ frameworks. Unfortunately the results are often mediocre in such cases. So to summarise this already prohibitively long post I'd say find out what category you fall into and choose the language for you. You'll feel more comfortable and your code will thank you for it:-).
Yes, I know that there is integration across Applixware apps but I doubt that their data exchange standard is either as powerful or as open or as flexible as KParts. KParts is more than just a way of embedding charts. It's a whole component paradigm. I believe that that is the future of desktop applications but it's just my opinion.
Applix stuff may have better functionality right now but in the long run it will lose out to KWord. Why? Because KOffice as a whole is greater than the sum of its parts. The real edge of Koffice lies in KParts my friends: for a start the individual components of KOffice wil interoperate in a way that is standardized across KDE. What it means is that all the new applications will be able to take advantage of KOffice rendering capabilities (it should be possible to attach an audio file to a KPresenter presentation or automagically play a movie file embedded in an HTML document).
Basically the strength of Windows is the high degree of applications interoperability that Unix world haven't had up until the dawn of KDE.
Yes, I know that Gnome is trying to do the same but it seems to me that KDE is much further down the integration root.
I can already hear those crying that *nix should avoid desktop integration and rely on small utilities to do everything. Bullshit, I say to them. There is nothing bloated about having a standard protocol for applications talking to each other and exchanging the data (if you do it properly that is).
This is what COM and KParts are all about and it's good. COM was the best idea Bill Gates ever conceived and even his implementation is pretty stable now. KParts is doing the same for Linux. If they don't end up writing a desktop environment that offers a comparable to Windows level of integration I'll be really upset. They have the right ingredients (GUI, OS)and the last time I checked KParts I was truly impressed. Its structure is much cleaner than COM/DCOM - they certainly learned from Bill's mistakes. I'd say, give them a year and we should see something that will make even the Redmond guys take a very close look.
C++ is a brillinat language. It's what I use for everyday coding at work and at home. The C++ language standard is also very nice on paper but there are at least a couple of major problems implementation-wise:
Template instantiation is something all compilers nowadays struggle with to some extent. All mainstream compilers seem to have a varying degree of problems compiling and linking template functions/classes/members. Do you think the compilation process should be redesigned to cater for the needs of the C++ language? Surely you don't find that the current state of things is what we want do you?
Name mangling. One of the main ways of implementing function overloading is name mangling. While it's a good way of resolving the issue of overloading it creates compatibility problems between compilers and even different versions on the same compiler because of the different name decoration schemes they deploy. Do you think name decoration should be part of the C++ standard the way it's standard in C?
member templates are supported as long as they are inlined. Namespaces and the templateized io classes as well. I don't use templates extensively besides the STL so I'm not gonna tell you much more about it.
Namespaces support has been much improved in version 6.
I still insist that VC6 is fairly ANSI compliant. I'd say it's on par with GCC 2.95
Actually even viewing complex data structures is more efficient with modern debuggers. DDD has a nice graphical panel for displaying complex data types. It's very powerful.
BTW. Why don't intelligent posts get moderated up anymore. Moderate the parent message up to "insightful" now.
Fuck. This is the first itelligent post in this topic. I'm switching my preferences to display lower scores first. Most slashdot readers are so fucking stupid now that they don't deserve attention anymore. Sensible posts start at 0 (intelligent) through to -1(amuzing). The rest are morons.
You've pretty much summarized what I felt. Thanks.
If the compiler can emit symbols that are compliant with the old VC7 format then you can definitely use the MS debugger and perhaps even the windows port of gdb (though I'm not sure about this one at all). There _used to be_ a standard format for debugging symbols in the old windoze compilers. However, the introduction of VC5/6 has pretty much eradicated that. They do have backwards compatibility with the old symbols though. Does anyone have some more detailed info on this one?
Visual C++ 6 is OK as far as ANSI compliance goes if the Service pack 3 is installed.
You can't link against VC++ dlls if they are C++ dlls because of the name mangling issue. The name mangling is not defined in the standard and VC does it differently from BC. So if you want to mix and match stick with c where name decoration is standardized. Hope this helps.
It's a scientific application used for 3D visualisation and manipulation of geological data. The compilation of the whole source tree with make clean (including the data structure libraries) takes up to 5 hours. We use different compilers depending on the system. gcc is used on Solaris because Sun Workshop has compatibility issues but I find gcc to be on par with commercial compilers in terms of compilation speed. And the make clean is only done occasionally but it's still nice to speed up even a half hour build.
BTW. I'm still waiting for a single on-topic reply to my original post;-)
Lots of people. CAD users, 3D graphics designers, programmers (compilation speed!), etc. If you are thinking about posting another "who cares" comment think twice: just because it doesn't affect you doesn't mean it won't affect others. Being a programmer I know that five hours compilation is the norm on a 500MHz PIII. 1.5GHZ Willamette should do the job in just over an hour. That's a lot of time saved on compilation.
As for "Intel can't supply Coppermines at decent clock speed so Willamette is vapourware" comments is simply rubbish Coppermine is an old design and Intel could only push it so far (I heard they had to reroute the chip to get it to 1GHz). However, Willamette is a new design altogether so if it's done properly they shouldn't have so many yield problems. Having said that I don't think that their design can match that of Athlon which was designed by one of the main Alpha guys (and it shows).
What truly sucks about this announcement however, is that Intel is trying to make us buy Rambus crap. And I don't want it. And nobody else apart from Intel wants Rambus. It's expensive, has latency problems and carries implicit Rambus tax in it. I hate intel pushing those political decisions down our throats. That's why I stick with AMD.
Well this thread is now old and probably you won't bother to read this comment but I'm really compelled to write this with a tiny hope that you might glance over it.
Linux jobs abound these days. Can you program? If so, maybe you won't be poor as a church mouse for long. Remember, free software does not require you to take an oath of poverty.
GPL is very harmful. Do you guys have a slight recollection of whatever happened to Netscape. Yes it couldn't compete with the giant that gave away its software for free. The Open Source, Free Software and GPL are to many software houses what Microsoft once was to Netscape. You guys are riding the hype and probably getting ridiculously rich in the meantime but every Open Source project potentially cuts off the air supply of some third party company. Open Source may succeed but it will crush many small guys on its way.
Take Be Inc. for example. Do you recon they would give BEOS away if it wasn't for Linux and other Open Source projects? They are now desperately trying to catch the wave but I think without a source of income and the hype that linux gets they are unlikely to sustain a reasonable income for much longer. I think they are just the first ones others will follow: KAI and Inprise come to mind. With more and more companies giving some half assed pseudo open licenses it shows that software houses now come under increased pressure to release their work for free and that is a bad thing.
More and more small development companies begin to fear that there is a student developer somewhere who is 'scratching an itch' developing software under the GPL that will do 75% of what their software does. Can you guess what sort of effect it's going to have on them? Particularly if they are five person little startups with only a one or two products to sell.
More and more companies try to specialise their software and find themselves nice niches to develop in because the mainstream is already 'taken' by free software. To you and RMS it is all about Free Software but to 99% of the users it is simply software for free if you know what I mean.
Stop blowing this smoke and talk openly about the downside of Open Source. The revolution has began but as with any other revolution the heads are falling fast. And they are not necessarily the heads you wanted to chop off in the first place.
I'm sure that as far as income is concerned you are sorted out Bruce. But somebody has paid or will pay the price of your success. My guess is that it will be most of those small development companies whose income source you've managed to cut off.
There seems no real link between the drug culture and geeks to me in general. Having worked for a gamws company I noticed that artists were mostly the ones into drugs. Developers would usually stay away from it simply because the reality seemed exciting enough for them (and deadlines were severe too;-). In fairness there must be a percentage of geeks who do use drugs on a regular basis but I'd be very surprised if that percentage was any larger amongst geeks than the rest of the population. If anything I'd expect it to be lower. The most notable case of a geek who got into drugs was perhaps Matthew Smith (aka. Matt from Earth) but I think he got into class A stuff after he became a sort of celebrity in mid eighties. Unfortunately I don't think he conceived anything valuable ever since (in terms of coding that is).
Hello again. you quoted my comment above questioning your knowledge of DP. Frankly I don't question your coding cred but I think you just didn't get Vlisside's book. This book tried to show how the stuff they discussed in GOF fits together. And frankly I recon John did a very good job at that.
As the title implies the book was meant to show how the patterns are applied. When reviewing it you only managed to point out several minor issues that were actually well defeated by the comments here. Especially the delete this stuff. I still don't buy your argument that it's evil all the time every time. The garbage collection argument was commented on by somebody else and needs no repeating. However, even though you didn't find anything fundamentally wrong with your book you critisized it on the basis of those minor issues that were not to your liking.
I replied to your review quite compulsively because I recon that you have done a very bad thing here. You discouraged the purchase of a book that could otherwise enlighten a lot of people about proper code design. Listen patterns are not some fancy academic theory. They work in practice. People apply them on daily basis (conciously or otherwise) to solve real programming issues. Pattern Hatching is one of the more easily digestible patterns books but your silly review may detract a lot of readers from this book and possibly from the topic of patterns all together. Again I think your critisism of this book was quite groundless and you got the comments you deserved.
by this review. Having read the Design Patterns from GoF and the "System of Patterns" by some five guys and this little book. this one is definitely the most down to earth one. The subjects of destroying singletons is a very important and overlooked issue and the fact that singletons can be misused is in no way detrimental to Pattern Hatching. The examples from the book often touch on problems I encountered myself when coding.
The fact that the book is focused on C++ stems from the aim of the book that is to show the patterns applied. If he settled for some abstract or rarely used lingo would that be showing design patterns applied?!
I think the discussion on the Observer is the best I have ever read and the treatment is solid and all tradeoffs are discussed. It's a pleasure to read and very enlightening approach to the Most Misused Pattern in the World(tm).
By all means ignore this review and pick up a copy. It's a masterpiece from a guy that really knows what he's on about. If you understood the GoF book you'll find this a great addenum. This book deserves a place next to books like Writing Solid Code and Code Complete.
I'm embarrased to see slashdot giving this book such a poor review. The book deserves all the praise and I strongly suspect that the reviewer never tried applying desing patterns. Pattern Hatching shows you how it all fits together. It doesn't discuss individual patterns but brilliantly shows you how they all interact. Buy it!
This is why I think we should encourage young programmers interested in free software to think really hard before staring a new project. Aren't there some existing, related project they can contribute to instead?
Hmm, this one got me thinking. Perhaps it's quite possible that developers often prefer to start a new project because the semi-mature ones are fairly complex to understand for a newcomer. So they create smaller projects which often duplicate the functionality of the existing ones and if they (projects) reach some momentum they grow to a certain point where new developers are too intimidated to join in. Could this be the fundamental flaw of the Bazaar style development? Not a flame just thinking aloud...
Slashdot Mirror
system("netscape -remote ");
Only works one way. This way there is no way to ask netscape about anything. Specifically there is no way to tell which page it is displaying at present. Since I had to render in a specific named frame that knowledge was critical. Hence I had to go through the X properties. What I had to do is improvise a two way communication and I also had to find out which if any netscape windows were available and connect to the existing one or fork a new one if none were available then make sure that every time i sent data to it it still displayed the frameset that I had told it to display (user input could have changed that state). Otherwise refresh it with that frameset.
Again, believe me it was all simpler and much more elegant and under Windows. When you have two way IPC it gets _much_ more complicated with fork(), system() or X properties that the simple dealing with COM's IWebBrowser interface.
Of course all you said in this thread is correct and to the point. And yes COM/DCOM is a great implemantion of object technology that is much more suited to desktop development than anything that *nix has achieved so far (and that includes Corba).
I had a dubious pleasure to implement a class that talks to IE on Windows and to Netscrap 4 on *nix platforms. The IE bit is about 40 lines to implement the class whereas the Netscape one is well over 600! And all it does is opens a browser and sends it a URL and tells it which frame to use. The Windows implementation is inherently more robust because of the simpler, more standard way of doing things.
However, slashdot is not a place for reasonable technical discussion anymore. It's a gathering of zealots and trolls who won't listen to sensible arguments because they never had a need to talk to a web browser from their own code. Why not? Because they never wrote a single line of code and hence they know fuck all about programming.
So my plea to you TummyX is to go away and post your comments on a forum that still has developers on it not just bored high school kids. Let this forum live in its own well misinformed hype driven little world.
You said that C++ forces you to pay for RTTI whether you like it or not and I showed you that that's not the case. You get upset too easily.
Not true again:
In your source:
#ifdef DEBUG
#define down_cast(TYPE, VALUE) dynamic_cast<TYPE>(VALUE)
#else
#define down_cast(TYPE, VALUE) static_cast<TYPE>(VALUE)
...and in the makefile:
ifeq(BUILD_TYPE,DEBUG)
COMPILER_OPTIONS = --enable-rtti
else
COMPILER_OPTIONS = --disable-rtti
endif
Hope this helps.
plain C context:
//need to reserve space for the shape:
//need to reserve space for the shape:
/* implementation of width for rect */ }
/* implementation of width for Circle */ }
//need to reserve space for the next shape:
struct rect {
int height, width;
};
struct circle {
int r;
};
int getRectWidth(struct rect* r);
int getCircleWidth(struct circle* c);
USAGE:
void rectFoo(struct rect* r)
{
int w = getRectWidth(r);
}
void circleFoo(struct circle* c)
{
int w = getCircleWidth(c);
}
C++ context:
class Shape {
virtual int width() const= 0;
};
class Rect : public Shape {
int width() const {
};
class Circle : public Shape {
int width() const {
};
USAGE:
void foo(const& s )
{
int w = s.width();
}
Hopeuflly you can see straight away which syntax is shorter and more elegant in this case. And this is a trivial example of a common problem in a GUI toolkit. To abstract a set of items so they can be used more generically. The C names are longer because more information has to be conveyed. Unless you are willing to resort to void* hell you have to have two different functions in C to deal with two different shape types. C++ has only one and if the names are chose in the way they should be the flow of the code is more logical too. Back to the main topic though...
Since when are casts used ot insure correctness? Do you know what cast are? They are a sign of sloppy coding in C++ and a necessary evil in C because C doesn't support polymorphism. Casts don't insure anything. They are type conversion enforcements that are brute force compiler directives which force it to treat one type as a different data type. To continue our shape example in C this is a C "generic" getWidth function:void getShapeWidth(void* shape)
{
int w;
if( isRect(shape) ) { w = getRectWidth((struct Rect*)shape); }
else
if( isCircle(shape) ) { w =getCircleWidth((struct Circle*)shape); }
}
If you like this sort of approach you should spend less time reading slashdot and more time reading your OO course.
Here you are either grossly misinformed or you bought into the (misinformed) slashdot crowd views.Ever heard of extern "C"? It gives you _exactly_ the same functionality as C. binding to C++ code is no more difficult because the same linker is used for C++ and C. C++ decorates function names to allow for overloading and that's what extern "C" prevents. It allows C++ to import/export plain vanilla C functions. Naturally you can't overload the functions exported in such way but that's logical because you've removed the decoration from them. Did you? I did and the main technical one was that Linus is a C coder.
low level libraries, like libc... have to be developed in C because they are an integral part fo a *NIX system. It's a part of the spec! Nothing to do with size or efficiency.
Fuck the Karma and develop your own views. Learn about both languages and try doing at least one significant project in each. Just because Miguel De Icaza said that C rulez doesn't mean it holds true for evey situation in every case. In fact for what he chose to develop C very much sucks and he either realized it already or will realize it in the future.Lesson finished. Go home get some sleep and get those C++ books out and look again but beyond chapter 2 this time. Good luck.
This thing has existed in most EU countries for a few years now and has been used by all the Telcos as an argument against introducing unmetered internet access. It is a pile of crap because in most EU countries local phone calls are around $0.03 per minute. Figure out how "free" that is for yourselves. Besides, offering you that "free service" is actually quite profitable for the free ISPs since they get paid by the the telecos when you use their dial in numbers (they get a share of your per minute charge). Go to CUT to see what kind of deal we really get with the European ISPs.
On one end of the scale we have the abstractionists who think in terms of the big picture design and 'see' projects in terms of components that interact with each othere. They are easy to spot in meetings because they are always the ones that tend to draw lots of UML and convoluted design graphs and they don't talk to people who haven't read the Gang of Four.
On the other end of the scale we have 'bit fiddlers' (sorry i find this expression rather amuzing). These guys tend to worry about the low level implementation details and often think in terms of actual lines of code and often ignor the design issues. They are very good however, at spotting design flaws that make the implementation hard.
Now, the problems lies not in the fact that we have these two groups of coder (see which category you fall into) but because these groups don't interact with each other very well. The abstractionists find it irritating that the implementationists don't see the 'big picture'. On the other hand the Bit Fiddlers get frustrated because abstractionists tend to overlook implementation issues. However, it takes both groups for a healthy software engineering project to thrive in my opinion.
What I find is that abstractionists tend to like and 'get' C++ more because of the natural gift of abstracting their ideas. The implementationists prefer C because they live in a constant fear of what happens 'under the hood'. That's why they lean towards C. Having said that you do find abstractionists coding graphics pipelines and implementationists writing C++ frameworks. Unfortunately the results are often mediocre in such cases. So to summarise this already prohibitively long post I'd say find out what category you fall into and choose the language for you. You'll feel more comfortable and your code will thank you for it :-).
Yes, I know that there is integration across Applixware apps but I doubt that their data exchange standard is either as powerful or as open or as flexible as KParts. KParts is more than just a way of embedding charts. It's a whole component paradigm. I believe that that is the future of desktop applications but it's just my opinion.
Because KOffice as a whole is greater than the sum of its parts. The real edge of Koffice lies in KParts my friends:
for a start the individual components of KOffice wil interoperate in a way that is standardized across KDE. What it means is that all the new applications will be able to take advantage of KOffice rendering capabilities (it should be possible to attach an audio file to a KPresenter presentation or automagically play a movie file embedded in an HTML document).
Basically the strength of Windows is the high degree of applications interoperability that Unix world haven't had up until the dawn of KDE.
Yes, I know that Gnome is trying to do the same but it seems to me that KDE is much further down the integration root.
I can already hear those crying that *nix should avoid desktop integration and rely on small utilities to do everything. Bullshit, I say to them. There is nothing bloated about having a standard protocol for applications talking to each other and exchanging the data (if you do it properly that is).
This is what COM and KParts are all about and it's good. COM was the best idea Bill Gates ever conceived and even his implementation is pretty stable now. KParts is doing the same for Linux. If they don't end up writing a desktop environment that offers a comparable to Windows level of integration I'll be really upset. They have the right ingredients (GUI, OS)and the last time I checked KParts I was truly impressed. Its structure is much cleaner than COM/DCOM - they certainly learned from Bill's mistakes. I'd say, give them a year and we should see something that will make even the Redmond guys take a very close look.
- the function is global (not a member function)
- it's not overloaded
hope this helps even more...Namespaces support has been much improved in version 6.
I still insist that VC6 is fairly ANSI compliant. I'd say it's on par with GCC 2.95
BTW. Why don't intelligent posts get moderated up anymore. Moderate the parent message up to "insightful" now.
You've pretty much summarized what I felt. Thanks.
If the compiler can emit symbols that are compliant with the old VC7 format then you can definitely use the MS debugger and perhaps even the windows port of gdb (though I'm not sure about this one at all). There _used to be_ a standard format for debugging symbols in the old windoze compilers. However, the introduction of VC5/6 has pretty much eradicated that. They do have backwards compatibility with the old symbols though. Does anyone have some more detailed info on this one?
You can't link against VC++ dlls if they are C++ dlls because of the name mangling issue. The name mangling is not defined in the standard and VC does it differently from BC. So if you want to mix and match stick with c where name decoration is standardized. Hope this helps.
BTW. I'm still waiting for a single on-topic reply to my original post ;-)
FYI. I'm an NT developer. And yes, I do use C++. As for the rest of your comment I'll ignore it because it's just flamebait and offtopic.
If you are thinking about posting another "who cares" comment think twice: just because it doesn't affect you doesn't mean it won't affect others. Being a programmer I know that five hours compilation is the norm on a 500MHz PIII. 1.5GHZ Willamette should do the job in just over an hour. That's a lot of time saved on compilation.
As for "Intel can't supply Coppermines at decent clock speed so Willamette is vapourware" comments is simply rubbish Coppermine is an old design and Intel could only push it so far (I heard they had to reroute the chip to get it to 1GHz). However, Willamette is a new design altogether so if it's done properly they shouldn't have so many yield problems. Having said that I don't think that their design can match that of Athlon which was designed by one of the main Alpha guys (and it shows).
What truly sucks about this announcement however, is that Intel is trying to make us buy Rambus crap. And I don't want it. And nobody else apart from Intel wants Rambus. It's expensive, has latency problems and carries implicit Rambus tax in it. I hate intel pushing those political decisions down our throats. That's why I stick with AMD.
Who cares though. Either way it's pretty silly.
Take Be Inc. for example. Do you recon they would give BEOS away if it wasn't for Linux and other Open Source projects? They are now desperately trying to catch the wave but I think without a source of income and the hype that linux gets they are unlikely to sustain a reasonable income for much longer.
I think they are just the first ones others will follow: KAI and Inprise come to mind. With more and more companies giving some half assed pseudo open licenses it shows that software houses now come under increased pressure to release their work for free and that is a bad thing.
More and more small development companies begin to fear that there is a student developer somewhere who is 'scratching an itch' developing software under the GPL that will do 75% of what their software does. Can you guess what sort of effect it's going to have on them? Particularly if they are five person little startups with only a one or two products to sell.
More and more companies try to specialise their software and find themselves nice niches to develop in because the mainstream is already 'taken' by free software. To you and RMS it is all about Free Software but to 99% of the users it is simply software for free if you know what I mean.
Stop blowing this smoke and talk openly about the downside of Open Source. The revolution has began but as with any other revolution the heads are falling fast. And they are not necessarily the heads you wanted to chop off in the first place.
I'm sure that as far as income is concerned you are sorted out Bruce. But somebody has paid or will pay the price of your success. My guess is that it will be most of those small development companies whose income source you've managed to cut off.
Thank you.
There seems no real link between the drug culture and geeks to me in general. Having worked for a gamws company I noticed that artists were mostly the ones into drugs. Developers would usually stay away from it simply because the reality seemed exciting enough for them (and deadlines were severe too ;-). In fairness there must be a percentage of geeks who do use drugs on a regular basis but I'd be very surprised if that percentage was any larger amongst geeks than the rest of the population. If anything I'd expect it to be lower. The most notable case of a geek who got into drugs was perhaps Matthew Smith (aka. Matt from Earth) but I think he got into class A stuff after he became a sort of celebrity in mid eighties. Unfortunately I don't think he conceived anything valuable ever since (in terms of coding that is).
As the title implies the book was meant to show how the patterns are applied. When reviewing it you only managed to point out several minor issues that were actually well defeated by the comments here. Especially the delete this stuff. I still don't buy your argument that it's evil all the time every time. The garbage collection argument was commented on by somebody else and needs no repeating. However, even though you didn't find anything fundamentally wrong with your book you critisized it on the basis of those minor issues that were not to your liking.
I replied to your review quite compulsively because I recon that you have done a very bad thing here. You discouraged the purchase of a book that could otherwise enlighten a lot of people about proper code design. Listen patterns are not some fancy academic theory. They work in practice. People apply them on daily basis (conciously or otherwise) to solve real programming issues. Pattern Hatching is one of the more easily digestible patterns books but your silly review may detract a lot of readers from this book and possibly from the topic of patterns all together. Again I think your critisism of this book was quite groundless and you got the comments you deserved.
Thank you.
The fact that the book is focused on C++ stems from the aim of the book that is to show the patterns applied. If he settled for some abstract or rarely used lingo would that be showing design patterns applied?!
I think the discussion on the Observer is the best I have ever read and the treatment is solid and all tradeoffs are discussed. It's a pleasure to read and very enlightening approach to the Most Misused Pattern in the World(tm).
By all means ignore this review and pick up a copy. It's a masterpiece from a guy that really knows what he's on about. If you understood the GoF book you'll find this a great addenum. This book deserves a place next to books like Writing Solid Code and Code Complete.
I'm embarrased to see slashdot giving this book such a poor review. The book deserves all the praise and I strongly suspect that the reviewer never tried applying desing patterns. Pattern Hatching shows you how it all fits together. It doesn't discuss individual patterns but brilliantly shows you how they all interact. Buy it!