Stephane Rodriguez. wrote: InstallShield is only a front end to Windows Installer. Gross over simplification, and thus not accurate. Installshield includes a lot more than what you get down at the MSI level, including a scripting language with built in libraries. William E. Kempf

Look out... you're maturity level is showing. Guess I bow out of this one now. William E. Kempf

Brad Jennings wrote: Repost, but I still can't believe he can get away with it. You can sue for anything, which is probably as it should be. Of course, a lot of law suits should be quickly decided, with the loser (multiple meanings) paying the court costs for bringing such pointless law suits. Brad Jennings wrote: If parents don't want their children to eat trans-fats then I guess they had better become Omish or something because I imagine there isn't much on the grocery store shelves that doesn't have them. This is very true. Unfortunately, it's also the reason that I'm not totally against this particular law suit. There needs to be some sort of pressure on the food industry to stop using trans fats and partially hydrogenated oils. I'd prefer economic, but currently not enough people are aware of the issue to apply economic pressures. I hope they lose this case (as in the Oreo producers prevail), but just having the case brought about will exert some pressure. Further, the publicity of the case may also make enough other people aware of the problem that economic pressures can be applied as well. Brad Jennings wrote: And plus, Oreo cookies are awesome, I can imagine that I won't be the only irritated consumer if they do decide to ban them. And this is evidence of the average consumer not being aware of the issues. Trans fats and partially hydrogenated oils are not required ingredients for any product. Health food stores have cookies that are indistinguishable from Oreos that contain no trans fats. In fact, Newman's "O" cookies are available in most groceries, are basically indistinguishable from Oreos, and contain no trans fats. This lawsuit won't cause Oreos to be banned. If they lose, all that will happen is that they'll stop using trans fats. Hopefully, this lawsuit will make them do that even if they don't lose. http://www.bantransfats.com/[^] Some of what's there is alarmist mumbo jumbo (for instance "There is no way that a child will be warned by the technical "Nutrition Facts" label, especially a child who is so young that he or she cannot read. Kids need prominent bright obvious graphic labeling, so that they know to steer away from those products."), but all in all there's a lot of good information. William E. Kempf

Stephane Rodriguez. wrote: William E. Kempf wrote: 1) Name a single standard they've destroyed HTML. Nope. The HTML standard still exists, and is still adhered to by *MANY* (including MS). Definately not destroyed by MS. Stephane Rodriguez. wrote: If you have been developing web pages expected to work on Netscape and Internet Explorer, you probably know. Getting pages to work as expected between *ANY* two browsers is an art form. However, the best way to do so is to stick to the standards, so you're arguing against yourself here. Stephane Rodriguez. wrote: The fact that it isn't obvious to you means you have never developed serious web pages. Quite incorrect. I've done more than my share of serious web development. I hate it, but I'm not clueless of the issues. Stephane Rodriguez. wrote: Man there is no discussing ! Discuss all you want, but expect to be called on things you get wrong, or on things that are pure FUD. William E. Kempf

Stephane Rodriguez. wrote: This sums up your post. I can't disagree more with this. MS has been destroying others standards while imposing their own standards, for two decades. 1) Name a single standard they've destroyed. 2) AFAIK, this is the first standard MS has championed. And they aren't "imposing" it on anyone. William E. Kempf

Stephane Rodriguez. wrote: It should be 100% free. It's only a service pack. Uhmm... right. The C++ compiler alone has undergone enough development to discount this. IMO, charging only $29, which barely covers the shipping/handling and CD costs, is a gift from MS, which we should be gratefully giving thanks for. Service Pack my @$$. Sheesh! Stephane Rodriguez. wrote: I don't like the idea of .NET being a patented technology, and a technology which is on the side of Microsoft, unlike MFC/WTL/... MS can break the API at any moment and force us to adapt (that's what they are doing for instance with the broken VS.NET 2003 project file formats). 'Scuse me?!?!! Java is owned, wholly, by Sun. They can do what they want with it, and you've got no recourse against them. .NET, on the other hand, has been standardized by the ECMA and is slated to be standardized by the ISO as well. (Sun has yanked Java from standardization at least twice, and won't ever go down that road again.) MS does hold some patents and proprietary libraries, but so what? That's what a capatilistic market is all about. They can't destroy standards, no matter what chicken little thinks. If you don't like MS, so be it. I won't try and change your mind. They have exhibited enough business tactics to deserve some of that. But if you're going to spread FUD, at least try to get your facts straight. William E. Kempf

There are a lot of "shared source" licenses by Microsoft at this point. See http://www.microsoft.com/resources/sharedsource/default.mspx[^]. There's nothing that indicates a shared source license for WTL would mean "'look but don't touch' or 'non-commercial use only'". Shared source may not be open source, but their respective licenses can be identical. The differences are political, not necessarily technical or legal. And personally, I prefer the politics of shared source over open source. After all, I live in a capitalistic society. William E. Kempf

Really? Hmm... coulda sworn I did that with VC++ and got the same results as Nish. Now, let's see Nish do GUI programming with results the same as the "Hello World" from Petzold using his GWBasic. ;) William E. Kempf

Olli wrote: Those were the good ole days.... When you were able to print out text in only 2 lines of code... #include <iostream> int main() { std::cout << "Hello, World" << std::endl; } There... I printed out text in only 2 lines of code. So what's your point? ;) :-D William E. Kempf

That depends. There's no real risk of data loss. Subversion has been self hosted for a very long time, which speaks volumes towards it's stability in this regard. Many people are using it already in production and non-production environments, and there's been no reports of data loss. What would prevent me from using it in production environments is only that the alpha status indicates heavy development, which means a high likelyhood of having to deal with frequent upgrades and/or conversions, which is a time constraint more than anything else. William E. Kempf

Nearly every X-Men member has been a villian at some point or another. Heck, that's true of most Marvel heroes. Kinda like the soaps for adolecents and geeks, but on over priced paper. (And I'm included in this category, so don't take offense.) I have to admit, though, that I don't recall any time in which Nightcrawler was a villian... In any event, Nightcrawler most certainly was not a member of the original X-Men. The roster was: Jean Grey (just Jean Grey, not any of her other monickers, and before her Pheonix powers were realized), Cyclops, Angel, Ice Man, Beast and Professor X. This was in X-Men Vol. 1. Nightcrawler didn't show up until Giant-Size X-Men Vol. 1. This was 12 years later. I believe he was a founding member of Excalibur, however. The first movie, as good as it was, hardly followed comic history (which ever rewrite of said history you want to take as gospel), so why should the second? William E. Kempf

As the article indicates, a consequence of the implementation using dynamic memory allocations. But the "experimental Boost library" is soon to be the official library, AFAIK, and it performs favorably in all test cases. William E. Kempf

Chris Maunder wrote: Curious from the point of view that I've used enough RegEx stuff to wish that there was one true regular expression syntax... Good luck ;). C++ will shortly have a standard RegEx, however. The Boost.RegEx library author, Dr John Maddock, proposed a library based on it (there are differences between the proposal and the current Boost.RegEx, however, AFAIK), and the committee voted it into the TR. (Hope I used the proper verbiage here.) William E. Kempf

Jeremy Falcon wrote: William E. Kempf wrote: I don't think you understand the point I was making. You are making assumptions again. Read the quote again. I very explicitly said "I don't think". I'm not making an assumption, I'm trying to understand what you've said. Jeremy Falcon wrote: William E. Kempf wrote: You didn't answer the first question. What question? The one about Bjarne's quote? I already did answer that. If it's not that question, then I'm afraid I have no idea what your question is. The first question in the full quote you just made. To whit, why do you find the numbers to be crap. Jeremy Falcon wrote: William E. Kempf wrote: I'm not trying to prove C++'s supremacy. No, but you are going back and forth between OOP's performance (in C++) versus its overall validity in the first place. No, I haven't been. Jeremy Falcon wrote: I used the OOPACK reference when on the topic of performance, but overall and performance aside I believe OOP is not my savior. (Also take no implications from that because I did not say it was yours either - you seem to assume a lot). (You asked earlier why I thought this was degenerating into a flame. Constant implications that I assume a lot and other language you use has been escalating from the first posts, and is nearing the point of being offensive. I may drop out of this discussion very soon because of this, and because I have no vested interest in where the argument is going.) Obviously OOP isn't your savior. No one has ever suggested that it should be. The fact that you continually go back to this is more of an indication that you're the one "going back and forth between OOP's performance (in C++) versus its overall validity in the first place". OOP *is* valid. The reasons for it's validity have nothing to do with performance, however, and it's validity does not mean that it's the magical silver bullet that will solve all of our problems. I've not made this argument, so there's no reason to continually try and go back to this. Jeremy Falcon wrote: As far as performance, I still don't see any gains over C when using C++, even in a non-OOP fashion. Blitz and other libraries provide a speed benefit that you'll be hard to get from C. This occurs because of the compile time constructs (as opposed to runtime calculations) that can be achieved using templates. But I've not be

Jeremy Falcon wrote: I can see your point with the callback schema. But, considering this is a Win32 and not a C issue (directly) this overhead would apply to all Windows applications. So, you wouldn't really get a benefit from using C++ (in this manner) over C when coding for Win32 (or many other GUIed/message-based OSes as they implement similar techniques). I don't think you understand the point I was making. There's no "benefit" to using C++ in this case. What I'm pointing out is that you can do no better in C when implementing a polymorphic call than occurs in C++. The myth of virtual method overhead lies in two factors. The first is simply that the overhead is no different from any such techniques you'd employ for polymorphism even in Assembler. The second is in the fact that polymorphic calls are usually abused by beginners in OOP, which leads to the mistaken belief that they add uneccessary overhead. Jeremy Falcon wrote: William E. Kempf wrote: How are they crap? And why should I do your research? I thought you were trying to prove the point of C++ supremacy? It takes some work ya know. 1) You didn't answer the first question. 2) I'm not trying to prove C++'s supremacy. I don't believe in such forms of advocacy. Use the right tool for the job, and when multiple tools will do just as well, choose the one you're more comfortable with. I'm only trying to dispell the notion that C++ causes unecessary overhead. Jeremy Falcon wrote: William E. Kempf wrote: BTW, I did find other sites showing similar figures. Fine then, but if they present things like the other one I don't think I'll be thoroughly convinced. As they did not present the grandiose pile of information that I was hoping for. Again, you have to answer my question before I can hope to provide the data you want. After all, the link I sent you shows the actual output of running OOPACK, so I can't fathom what else you'd want? William E. Kempf

Jeremy Falcon wrote: William E. Kempf wrote: Depending on how you use the term "STL", it *IS* part of the standard libs. I meant as in "non-templatized". Since your perception is so keen, I figured you'd pick up on it. I missed this part in my first reply. What does "non-templatized" have to do with anything? If you choose not to use templates, that's your choice (though I can't see any rationale reason for the choice), but I see no bearing to this subject? William E. Kempf

Jeremy Falcon wrote: Funny how you aggreed with Richard that there's nothing I can't do in C that can be done in C++. And yes you shoot down my choice (that coincides with his) of saying OOP is not the gratest things since sliced bread. And, as far as marketing nuts, rookies, etc. OOP is a buzz word still. I see no contradictions in anything I said. And I certainly did not "shoot down your choice... of saying OOP is not the greatest things (sic) since sliced bread." We'll have to agree to disagree about OOP being a buzzword, but regardless, it's a well proven methodology. Jeremy Falcon wrote: Don't confuse "as much experience" with "no experience". I never assumed anything along these lines. Jeremy Falcon wrote: This is extremely rookie crap you're showing me here. And furthermore, I've never referred to coding when talking about overhead, but rather what the computer must endure (taxation-wise) to account for this methodology. The code I presented was meant to show there's nothing "the computer must endure (taxation-wise) to account for this methodology." The resulting overhead should have been identical for both the procedural design as well as the OOP design for my simplistic example. Jeremy Falcon wrote: William E. Kempf wrote: but no more so than similar techniques employed by C libraries such as the Win32 API. As an FMI, can you name a technique the Win32 API uses that has as much overhead? Certainly. WNDPROCs are a C way of getting polymorphic behavior, with the same amount of overhead as most C++ implementations of polymorphism (i.e. a vtable with a single level of indirection). Jeremy Falcon wrote: William E. Kempf wrote: http://www.oonumerics.org/MailArchives/oon-list/msg00073.php\[^\]. There has to be a lot more info than this, but I found this one with a 10 second Google search. These stats are crap. You're quick to argue, but slow to search. What gives? How are they crap? And why should I do your research? I don't have a vested interest in this. I showed that a simple Google search can get you the data you want, so go do the search. (BTW, I did find other sites showing similar figures.) Why are you taking this so personal? This is getting very close to degenerating into a flame war. William E. Kempf

Jeremy Falcon wrote: Yes, I know OOAD, but I think OOP is just another buzz term. Buzz terms don't have life spans of the length that OOP has already endured ;). I think you're falling afoul of the initial "buzz" over OOP being that it was a silver bullet that would solve all of our problems. Obviously it's not, as there is no such thing as a silver bullet. So, because of this "buzz", you've mentally aligned yourself to think that OOP is bad. There are two problems with this, as it pertains to this thread. First, OOP *IS* a very good solution for many problems... including some problems not easily solvable with other paradigms, such as you're favored procedural. Secondly, C++ is *NOT* an OOP language, or at least not exclusively. It actually lets you program using many different methodologies, including your preferred procedural. Good C++ developers make use of each paradigm, choosing the most appropriate one for the task at hand (of course, that's not always an easy thing to determine). Jeremy Falcon wrote: In fact I heard something new that's supposed to be called "Application Oriented." I believe you're referring to AO, which is Aspect Oriented (http://aosd.net/[^]), not Application Oriented. Jeremy Falcon wrote: What's next, we use "Procedure Oriented" and we go back to the way I we all did things in the first place? When it's appropriate. BTW, you've missed several other methodologies/paradigms which can be used in C++. Functional is one of the more intersting ones being explored right now. Jeremy Falcon wrote: I don't use much STL, but rather the standard libs. Depending on how you use the term "STL", it *IS* part of the standard libs. Jeremy Falcon wrote: And, it's just as easy to reuse a well-written function as it is a class. Absolutely. But it's more difficult to achieve things like lifetime management, for instance. Both methodologies have their strengths and weaknesses. The nice thing about C++ is it let's me choose ;). Jeremy Falcon wrote: Anyway, I've always read since the dawn of ages that C++ incurs overhead simply because of it's extra functionality. To me that makes sense. Now, if compilers these days are closing the bridge on that - that's great. But, I'd like to see stats. Act

Nemanja Trifunovic wrote: My question is: what are the benefits of generics + constraints vs passing an interface old way. If it was C++, I would think about optimization being a reason. Mostly code reuse. However, you can also get some optimizations here as well. The constraint is checked at compile time, so the compiler can perform more efficient forms of casting since it won't have to make a runtime check that the object is of the appropriate type. William E. Kempf

This is not generic, and forces the use of casts, as is the case today. With your signature, I could Add() ANY key to Dictionary, so long as it implemented IComparable. However, given what the article had:

public class Dictionary<KeyType, ValType> where KeyType : IComparable
{
public void Add(KeyType key, ValType val)
{
...
switch(key.CompareTo(x))
{
}
...
}
}

and an instantiation of Dictionary<Foo, Bar>, then you can only pass in Foo instances to Add(). So you get strong type checking, but because of the generic usage, I can instantiate multiple types of Dictionary: Dictionary<Foo, Bar>, Dictionary<Bar, Foo>, Dictionary<Duck, Quack>, etc, as long as the KeyType meets the constraint (i.e. implements the interface IComparable). I'm not sure that I care for the fact that you HAVE to constrain a type or cast it in the code in order to use members not part of the base object type, coming from a C++ background, but it does lend to easier implementation of strongly typed generics, which means better compiler diagnostics. William E. Kempf