Top Mud Sites Forum - View Single Post

Yui Unifex · 04-04-2003, 05:33 PM

My issue is not necessarily with you ignoring the feature, but with you believing that I'm judging based on the history rather than the feature here:
I used it for a little while on a project, but I ended up moving the development to a Linux machine with valgrind. I honestly didn't give Rational Purify as much use as I've given valgrind, though, so I wasn't aware of any of the bugs it had with C++.

gprof has a switch that can be toggled for C++ name mangling. Interestingly enough, I just checked the manpage on FreeBSD 4.5 and 5.0, and couldn't find the switch in the manual. I'm positive it's in the Linux manpage, though. I haven't used ElectricFence.

I don't think that this conclusion follows from my statement. I'm in favor of language designers adding features that make a language more useful than it is, and properly weighing the constructs involved in any given feature to make them consistent, clean, and unobtrusive. Some constructs (like Ruby's incredible object orientation and concept of iterators) do away with things like the 'for' loop, but since there is a satisfactory alternative, I don't think that the designers should concentrate on adding a for loop. From what I hear about C99 and the C++0x standardization process, designing a language is very, very difficult and time-consuming. So while I agree that there are very few features that I would *not* want to have in a language, designers often have other overriding concerns and adding 'ugly' features simply becomes a matter of priority, as they fall to the bottom of things to be done. To be idealistic, if I could have a language that did anything I could ever want and much more, so long as the 'much more' part did not impact the performance of the 'anything I could ever want' part, I'd use it. For now, I simply have to pick and choose various languages based on how well their particular philosophies fit what I want to build, which makes crossovers (such as a rapidly-developed but performance-critical application) much more difficult to write (because of interface concerns) than I believe it should be.

I'm not sure if I'm a fan of it... I've never used it =).

This is an interesting question, but I don't think I'm in a position to answer a yes or no here. Oftentimes the common and advertised uses for something fall by the wayside as people think up innovative uses for things, so it's difficult to tell where something really fits in with one's goals. If someone else has an interest in the tool, who am I to tell him that the tool should not exist? If noone has an interest in the tool, why is it worth my time to even consider its existance? If many people hate the tool, and I have no interest in it, I probably wouldn't stop them from causing it to cease to exist, but I would take no action myself. If I have an interest in one of the tool's uses, then I would probably think that it should exist. This is presumably because I have evaluated my options in relation to the particular use and the tool, and have decided that using the tool over some other tool was in my best interests.

The signals and slots are dynamic, and type-safe.

04-04-2003, 05:33 PM	#55
Yui Unifex Senior Member Join Date: Apr 2002 Location: Florida Posts: 323	My issue is not necessarily with you ignoring the feature, but with you believing that I'm judging based on the history rather than the feature here: I used it for a little while on a project, but I ended up moving the development to a Linux machine with valgrind. I honestly didn't give Rational Purify as much use as I've given valgrind, though, so I wasn't aware of any of the bugs it had with C++. gprof has a switch that can be toggled for C++ name mangling. Interestingly enough, I just checked the manpage on FreeBSD 4.5 and 5.0, and couldn't find the switch in the manual. I'm positive it's in the Linux manpage, though. I haven't used ElectricFence. I don't think that this conclusion follows from my statement. I'm in favor of language designers adding features that make a language more useful than it is, and properly weighing the constructs involved in any given feature to make them consistent, clean, and unobtrusive. Some constructs (like Ruby's incredible object orientation and concept of iterators) do away with things like the 'for' loop, but since there is a satisfactory alternative, I don't think that the designers should concentrate on adding a for loop. From what I hear about C99 and the C++0x standardization process, designing a language is very, very difficult and time-consuming. So while I agree that there are very few features that I would not want to have in a language, designers often have other overriding concerns and adding 'ugly' features simply becomes a matter of priority, as they fall to the bottom of things to be done. To be idealistic, if I could have a language that did anything I could ever want and much more, so long as the 'much more' part did not impact the performance of the 'anything I could ever want' part, I'd use it. For now, I simply have to pick and choose various languages based on how well their particular philosophies fit what I want to build, which makes crossovers (such as a rapidly-developed but performance-critical application) much more difficult to write (because of interface concerns) than I believe it should be. I'm not sure if I'm a fan of it... I've never used it =). This is an interesting question, but I don't think I'm in a position to answer a yes or no here. Oftentimes the common and advertised uses for something fall by the wayside as people think up innovative uses for things, so it's difficult to tell where something really fits in with one's goals. If someone else has an interest in the tool, who am I to tell him that the tool should not exist? If noone has an interest in the tool, why is it worth my time to even consider its existance? If many people hate the tool, and I have no interest in it, I probably wouldn't stop them from causing it to cease to exist, but I would take no action myself. If I have an interest in one of the tool's uses, then I would probably think that it should exist. This is presumably because I have evaluated my options in relation to the particular use and the tool, and have decided that using the tool over some other tool was in my best interests. The signals and slots are dynamic, and type-safe.