Yeah - it would take a change to someone who was dumb on the concept of cost/benefit analysis.
I don't see how that changes his point.... It would be sort of like the US goverment not allowing the IRS to setup a web page to do peoples taxes because it will complete with the tax preperation companies. Even though the IRS pointed out that it would save the goverment money because more people would file online, and its cheaper than having people opening envelopes and scanning tax returns.
While XP did make a number of changes to the base OS it didn't really affect anything a desktop user is interrested in. Most of that stuff is truely only useful for servers, and XP is the desktop version of the OS 2003 is the server version...
Lets see here...
They removed the 200G limit on mapped files... Wow thats useful for... well nothing unless you have a 64-bit machine.
Larger than 220M driver images, again really useless, the average windows driver is less than a meg.
Larger registry's, so now you can consume more than 300M of memory for your registry, which is just silly, frankly if your registry is that big you need to run a registry cleaning utility
Changes to the default use of large pages.. primarly a debugging tool, and a slight performace decrease if you only have 128M of ram on XP
More efficent work set trimming, which is nice except it doesn't work as advertised with my tests which show that the 2000 VMM is acually faster for systems with fewer than 4 processors
Reduced lock contention, again won't affect the majority of desktop users which have 1 or two processors.
So i'm getting bored... about the only things in that whole list that might help desktop users are the "faster hiberate and resume, a the system restore/and driver rollback" options.
On the negative side, I have to call M$ every few months when I want to resinstall the OS on my PC because i've changed the motherboard or upgraded to a larger harddrive as my system drive.
No thanks, I will stick to 2000... and when it finally gets to the point where 2000 is completly unusable I will finally switch my primary OS to linux (even though I think it is an archaic piece of crap).
My nightly backups are almost half a terabyte..Media isn't cheap. 100 tapes is $10,000.00
What I was saying was that LTO-3 stores 400G uncompressed, the tapes are less than $70 and the drives are less than $2500. Sounds like its time for you to buy a new tape setup.
My nightly backups are almost half a terabyte. If I didn't reuse media, I would have a very hard time getting my budget approved. Media isn't cheap. 100 tapes is $10,000.00.
no need for real mode switch to access firmware/Bios
thread switches in less than 50 cycles
a memory table lookup in less than 50 cycles, or occasionally even COW and dirty pages flushing without table lookup at all
Register passing has always been supported, of course passing more than 4 parms was a problem, but not that much of a problem considering research about this pointed out that most C functions had less than 4 parameters. Even so, the x86-64 extended this enough that its really a non issue.
Modern BIOS's have 32-bit entry points, which are used by all major OS's. This has been true for a long time. This isn't really an x86 issue so much as a platform issue anyway..
Trust me on this one, the x86 compares very favorably to other high performace CPU's on actual absolute context switch times in major OS's. These numbers are a lot more complicated than just counting the cycles the manual says it takes for the sysenter call (for example TLB flushing if nessisary and associated reloads, etc). A quick google search provides an old example: http://www.ro.feri.uni-mb.si/predst/martin/4_12_20 00/301specs.html. and another http://www.ebsnetinc.com/RTKernel-RISC-real-time-p erformance.php. I've seen some more recent charts and they say similar things. The OS ive worked on had hundreds of lines of code (PPC based and another ARM based) to do the same thing the x86 was doing in just a few heavier instructions and the net result was a wash.
I'm not sure what in particular your talking about (memory table lookup? hu? sounds like your talking about indexed address modes). The talk about COW and dirty page flushing sounds like don't know about the INVLPG instruction. COW and dirty page flushing are OS functions having single TLB invalidate instrucitons like INVLPG make that as simple as updating the page, followed by TLB invalidate.
Your confused, or you may have been running a 486. The 6x86 line from cyrix was _VERY_ competitive with anything on the market. There only problem was one of perception, its like intel paid people to write bad reviews or something. When cyrix released the 6x86 it was suppost to work in every motherboard on the market. The only problem is that it required more current than the pentium's because it was a fab generation behind and a good percentage of the motherboards were unstable with the extra current draw. This caused a motherboard compatability list to come out, which everyone promplty ignored, then M$ disabled the L2 cache on cyrix for windows NT because the only cyrix they had (all of M$ had 1 cyrix) couldn't run it without crashing. Turns out that it was running on an unsupported motherboard which was getting bus reflections when it was doing burst transfers. The final blow was that everyone started using quake as a benchmark. While the cyrix 6x86-133 was labeled as a PR166 it ran more like a P90 in quake. This is not unusual even today, I can find benchmarks that prove the P4 is way faster than the P ratings on the AMD's. Its just a case of which benchmark you trust. Turns out that ID software had optimized quake for the pipeline arch of the pentium and didn't have an alternate code path for the cyrix which had a very strong math coprocessor but it didn't do back to back multiplies like the Pentium did. So some selective benchmarking pretty much was the final blow for a very good product. I ran linux on my 6x86 long after I purchased an MMX pentium to play unreal. The 6x86-166 was far more responsive running X and assorted other crap than the MMX-233 I had was. At that time AMD was draging its feet getting the K6 out.
BTW: I am old enough to remember the 286 and granted AMD's 286-20 and their 386-40 were reasonable processors, but they didn't compete with intel on the high end. By the time the fast (>16Mhz) 286's were out intel was selling 386's at the same clock rate and the fast 386's were competing with 486's.
while braking the car, you can slow it down by converting the forward motion of the car into electricity that can be redirected to the batteries. This is known as regenerative braking. From my perspective, the added weight and complexity of the regenerative braking system, plus the low absorption efficiency rate of conventional batteries, ultimately provides for little if any gain in range for the vehicle.
Battery absorption rate... maybe, that is why from what I understand everyone is moving to putting large capacitors in for this function. http://www.nasatech.com/Briefs/Apr00/LEW16876.html. On the other hand i'm not sure what he is talking about when it comes to added weight, since the regenerative braking systems don't really add anything when it comes to a direct drive hybrid, you have an electric motor that acts as a generator for braking and is used for driving when in battery mode. Compared to a pure electric vehicle there is weight gain, but that is not what we have here.
The diffrence is that each year porsche releases half a dozen porsche's and intel 2 dozen processors. Not only that but the porche numbers tend to stay the same from year to year, after saying I have a 944 the next question is which year. The product placment relative to the other models 914, 911 etc stays the same, porche never released a 914 that was faster than the 911. That is not what happens at intel, this years 640 vs next years 720 compares how? With numbers to designate product lines 914 was the low end car 911 the high end car. Easy to remember, end of story... Today I can't figure out what processors are better when I look at the list and I'm in computers, it takes 10 minuites to figure out which ones are the high end and which ones are the low end, then since the low end of the high end line is slower than the high end of the low end line which one is better? If they are going to pull this crap, they need to make 4 processors a year, one desktop processor, one inexpensive desktop model, one server processor and one low power model. Then they need to call the desktop processor the same from year to year, with maybe a minor series bump to detect the diffrences between years.
Chuckle, yah we are using XFS too, but there are limitation in some versions of the linux kernel at assorted places that keep it from getting very large too. There are a number of patches (from what I understand some of which have made it into the kernel recently) that allow it to get larger than anything we have here. Problem temporarly solved.
I have a few systems here at work that have many Tb of storage and bandwith requirements >1G/sec. It would be nice to see someone accually test this kind of setup with the linux file systems. From what I've personally seen XFS is just about the only legitimate solution for our application (its not exactly optimium either, its getting its butt kicked by NTFS). This is because linux simply uses to much CPU to maintain any reasonable throughput (aka >500Mb/sec) and the larger file systems tend to either get so slow as to be unusable, or they simply don't work.
Reiser does things other FSes don't do as well. It's a true 64-bit filesystem and it supports insanely large filesystems, up to 9 million terabytes in 64 bit mode (with a 64 bit kernel.)
I don't know about the setup being tested, but when I ran Reiser on a very large (many Tb) file system I discovered it gets slower the larger the filesystem, after a while its simply to slow to use. So while it may "support" large file systems, I'm betting no one has plugged it into a 50Tb file system to see if it really works.
Of this the only real line that gets inserted to create the form with the text box is the CreateForm() call. There are a few more comments and a couple lines of #include in the module for the form, the only real part is the empty constructor. I don't count the resource fork as code, since In a few years of using BCB I've never had to edit it so its effectivly transparent.
You must be from the Java school of OO-thought. If you indeed get into the situation that much of your code is setter functions (getter functions don't matter, these don't hurt), you should seriously consider if you shouldn't actually be using structs instead of classes and a library of functions to manipulate these structs.
Thats funny, you should talk to the java programmers here. It might be funny, I personally dislike the java OO model. I think it sucks. I do like C++ though, and I really like the VCL that borland makes (since C++ doesn't enforce an OO model). In my opinion what is taught as OO (especially with java) is so far away from what it was meant to be, i've decided to sign onto the "component" bandwagon. This better describes the way I use, and the way I write code. Small components which have definite purposes and are _SELF_ contained. In other words they don't tend to depend on big inheritance tree's and they can be used simply by learning smaller well contained interfaces. I'm not afraid of procedural code using objects, nor am I afraid of setting a public member variable. Hell I even create global classes to deal with global resources instead of passing a refrence around to every method in my program just to access 1 instance of a class. I rarely use static members, and I use constructors and destructors for what they were meant to do rather than making start() and stop() methods. Personally after having seen getter and setter messes created by other programmers I never use them unless they acually have work to do. I would rather go back and change 1000 x.y=z's to x.sety(z) than write a bunch of useless code that doesn't do anything and has to be maintained.
When I for instance look at the code 'window.width = 50', the principle of least surprise is violated (as is too often the case in C++ already).
I agree with this, and that particular example comes from the VCL, which tends to do a lot of things automatically for you. This means that you pretty much never have to call the repaint() method. It makes sense after using it for about 30 seconds. The VCL follows a simple rule. Variables (accually properties) which affect something have there affects felt as soon as they are changed. So you simply set the width and if the window is visible it resizes, you set the visible=true property and becomes visible, you create a new button giving it a parent window in its constructor and it paints on the window you specified. If you set a database field to something it updates the result set. The list goes on. Once you get used to this it is a _VERY_ natural way to program. There is sort of a unwritten rule about what ends up as a properly and what ends up as a method though. Its a fine line, and i'm sure a lot of people cross it (maybe even me sometimes). In general if the method accually does something then it gets a method. Which isn't very clear, but if the intention is to resize() the window then you make a method which takes the height and width. Its like operator overloading, a.add(b), a=add(a,b), or a=a+c. Which makes more sense, well in this case the last one does but it may not be clear all the ugly stuff going on behind the behind the scene especially if you didn't relize that a and c were vectors. Same with win.width=50; If the window isn't visible all I wan't to happen is have the width set, if its visible I want the width set and the window repainted.
Stroustrup lives in a fantasy world where the only reason C++ isn't as fast as C, or produce as small of assembly as C is because of the compilers- which he conveniently disavowes responsibility for.
Or is it you? Show me a piece of code that runs faster with a C compiler than the same piece of code with a C++ compiler from the same manufacture. Maybe you don't understand that if you write code that doesn't use the "slow" features of C++ its the same speed as C. Even then when you use virtual methods, compare them to the performace you get with structures of function pointers in C. Then there are things that acually make C++ faster than C, like for example templates and exceptions. Look up template meta programming on google if you don't believe me. I know of at least 1 compiler that accually generates faster code for the C++ virtual methods can get generated by the C function pointers. I think at this point most of the C compilers out there are acually just C++ compilers with a slightly diffrent parser running on the frontend.
I don't think C++ is now, or ever was (or with the way these "extensions" keep showing up) - or ever will be suitable for Systems Programming.
This is complete and utter BS, I have written a number of drivers using C++ in enviroments that didn't officially support C++. I have also written a microkernel that runs on a number of embedded ARMs in C++. C++ is a wonderful systems programming language, I no longer have to manage function tables, deal with a lot of error handing etc. System calls are a natural place to create a "transaction" that can be aborted by an exception, as are SLIH's the list goes on. I'm not the only one, a number of other people have C++ based kernels and drivers. Writting an OO kernel also encourages you to have interfaces between the diffrent subsystems, this is something linux strongly needs and doesn't have.
cout
cout is in my opinion stupid, and I don't use it, so I don't care if its slow (plus its not internationalized, and hard to convert, unlike the printf family). Plus most people don't understand that it tends to creates temp objects all over the place, and that is what is slow not cout.(this reminds me of Java, which isn't always slow, but it encourages practices that are)
Because the C++ programmer infrequently can understand what his runtime is doing- and is not encouraged to know the interface by which C++ does it's magic (because nobody knows- they're still trying to figure out how to make some C++ magic work in a way that isn't slow)- a C++ systems programmer needs a C++ runtime. Nobody has one in systems-space, so the C++ programmer (which isn't a programmer of C++) needs to write it.
This is utter BS too, it isn't any harder than C, in fact its almost the same as C except for virtual methods, RTTI, and exceptions. The rest is basically all compile time. RTTI is off by default on most compilers because it can slow things down, exceptions and virtual methods usually only take a little while to understand how they work with a given compiler. If its not documented then a few minuits in the RTI and stepping through the call or excption with an assembly debugger should make it perfectly clear. In fact as part of using C++ in a kernel mode enviroment I have implemented a number of C++ startup and basic support libraries, the biggest one was probably 200 lines of code (because you can't include the full C++ or for that matter C runtime for usermode, with C that code is usually already in the kernel so you don't need to generate it again). Mostly it was simply changes like overridding global new and making it call the kernel allocator, setting up the module/driver/kernel load routine to call the constructors/destructors for global objects, and other really simple things like that.
Syntactic sugar for getters and setters can be useful for providing a more natural interface (as long as people don't abuse them), but they don't really have any place in a language like C++, where almost everything is set in stone at compile time.
I don't see how binary compatability has anything to do with it. You can't change a member function to virtual or add a overloaded default parameter either without breaking binary compatabilty. Personally, I've used two diffrent C++ implementations with properites and you would simply be amazed at how useful they really are. Besides its not like C++ to force people to write code that is explicit. Look at the refrence syntax that allows you to pass a variable that may or may not be modified. Ex: in C Myfun(a) could never modify a, with C++ it can. Now I personally _NEVER_ use non const refrences, but it is there.
What C++ needs is some form of binary interface though. Part of the reason so many people are still using C or (extern "C") is because its still the only standard way to write a libary that other languags can access. Hell often times you can't compile your C++ program with one compiler, and another part with another C++ compiler and expect to be able to link them together. This has really got to stop. There are a lot of techical issues why this would be hard (while maintaing the ability for vendors to do a lot of vendor specific optimizations), but it can be done. Especially if another keyword were to be added to specify external interfaces, or the compiler were expected to dump some kind of meta file about the interfaces.
This is just a silly statement and refects a very shallow knowledge or programming. I've seen what happens when "no public variables" type people try to write real applications. 30% of the application code is just simply getter and setter methods, which really makes things ugly.
The whole OOP paridigm could be called "syntatic sugar" after all I can write code like myfun(var) rather than var.myfun(). The idea with properties is that its often times a _LOT_ clearer to simply say window.width=50; than window.setwidth(50). Especially when instead of 50 its another function call, or a complex expression. Its all sort of a matter of taste, also having the ability to design a class and then go back and change the behavior on the fly when someone changes a variable completely removes the need for shitloads of getter and setter methods.
Re:Why I won't use GTK.
on
Why Use GTK+?
·
· Score: 1
Well, then how do you define "object oriented"? GTK+ allows for subclassing, for instance. see here, which references subclassing. See also the GTK+ tutorial at gtk.org, which states, "GTK is essentially an object oriented application programmers interface (API). Although written completely in C, it is implemented using the idea of classes and callback functions (pointers to functions)." I believe GTK+ also allows for encapsulation
Like I said you don't get it. Passing function pointers around, and messing with tables of function pointers is not object oriented programming. Its procedural programming with a bunch of function tables. Object oriented languages support this kind of stuff without a bunch of manual code. Its like my comparison to macro assemblers, you can write all kinds of high level macros to simulate for loops, if then else conditionals etc. At the end of the day though your still programming in assembly not some high level procedural language. This means that the syntax will be clunky, and when the maintenance programmer shows up they have to learn a bunch of system specific macros. Running GTK in a language with OOP support doesn't make it mysteriously OOP either.
Re:Why I won't use GTK.
on
Why Use GTK+?
·
· Score: 1
(1) a GUI toolkit must be object-oriented: ok, as you mostly concede, GTK+ is object-oriented. Point (1) is moot.
That is not what I said. What I said was the people like you claim it is. Its not, anymore then it is possible to write high level code in a macro assembler.
In practice, does this happen very often? More pointedly, what evidence do you have that GTKmm is poorly maintained? Murray Cumming will be very interested to hear why you think that, especially as he puts out new releases with the Gnome release schedule, every six months.
Every time I go to use it, I find bugs. Which is every year or so, as such I conclude its poorly maintained. Or maybe poorly excercised is a better description. Maybe its just me, but the title of this thread is "Why I won't use GTK"
It sounds like your criticism is mainly that you don't like C for GUI programming and are therefore damning all of GTK+, even though many programs written in other languages use GTK+ happily.
Thats right, I think using C for GUI development is not the most intellegent idea. Sure it has better language bindings, and if your writting GUI code in perl, then go for it, GTK+ fits just with the midset of the kind of person that would consider writing a full GUI application in Perl. Personally I am going to use something that does more to assist my development than hinder it. I'm constantly amazed at the stuff you have to do manually in some of these GUI toolkits. As I sort of stated in another post GTK+ and Glade remind me of doing GUI programming in the early '90s with Borland's OWL and ResourceWorkshop. Today I expect an enviroment more like Borland C++ builder. The techical diffrences (why one is better than the other) are hard to point out, its more a collection of small things that come together to form a complete whole. Some of it is just synatic sugar designed to make things more intutive. For example being able to say MyForm.Width=500; and have the GUI redraw the form to match the given width (if the form is visible, otherwise to save the property) without having to call a function to redraw the form, or call a method to set a property. Another thing that is really nice is having icons/images/default properties stored in resource forks instead of hardcoded into the code somewhere that a resource editor has to parse out. The list goes on things that can be done in C++ for example code like `MyNewform SpecialForm(self);` to get a new form using default properites and have it automatically paint. In the short term it may not seem like much but when you have a GUI toolkit that allows you to write 1 line of code instead of 5 you only have to maintain a 50k program instead of a 250k one.
Yah good point, only since windows was originally running on DOS many of the good file name extensions were taken. For example '.MOV' was the RLE encoded movie format used by autocad, 3ds and others for the autoflix. '.SND' was the Tandy deskmate sound file..pict was to long (8.3 format) and a number of the pxx formats were used by paint programs. '.PIC' has the following hits http://www.google.com/search?hl=en&lr=&q=DOS+.pic+ +format. PCX was particularly popular.
Back then though all the mac people used to point to the file name extension in DOS/Windows as a bad practice and a reason why the mac was better (the filetype was hidden in the resource fork and tied to an application).
When MS or Mac plans to come out with a new system, they typically tweak the GUI appearance enough to make the consumer feel that buying the new system was a worthwhile investment. These are generally done as new calls to the underlying system, or maybe a new set of widgets that weren't available before.
This sort of belies the fact that you haven't done any windows programming. Much of the "look and feel" is determined by windows. AKA the window manager. If you write your application properly (ie don't invent to many custom components). Then things just tend to work when you go to new versions of the OS. Oviously there are special cases, but the majority of the look and feel of the OS is determed by the OS not the applications. Now if your application is written using GTK then when you pop up a file open dialog your getting the GTK version not the windows common dialog (which almost always changes between windows revisions) and as such the things the users expect (like being able to view image thumnails vs detailed view) don't behave the same way, if they even exist at all. This is why things like the scroll wheel on the mouse just work in windows (and always have for windows applications, applications ported from linux tend to have the same problems in windows that they had in linux with the wheel). Its because the mouse driver is simply sending WM_SCROLL messages to the top level application window. Because its just the right way to scroll a window, when M$ came out with the scroll wheel it just worked in applications that had never seen a scrolling mouse in thier whole existance.
Re:With the bazillion GUI toolkits out there..
on
Why Use GTK+?
·
· Score: 1
I assume when he says builder he is talking about the borland products. In that regard glade is more the the resource editor that came with borland C++ back in 1990, than anything that they currently ship. Techically its hard to pinpoint what exactly the diffrence is though. Its more a statement of integration and toolkit/framework/component design, combined with clean syntax. In this regard even borland extended C++ to add the property keyword (and Visual Studio now supports it as well). So its hard to describe, its more like the polish that comes from a bunch of tecnically minor things coming together to form something that just works.
Why I won't use GTK.
on
Why Use GTK+?
·
· Score: 1, Insightful
Basically its archaic. GUI development is one of the few areas where object oriented design makes a big difference to the programmability of the system. This has been known for the better part of 15 years. All those little buttons/menus/combo boxes/etc with the hundreds of properties to control behavior. The need to override behavior, the need to hook events. The list goes on. Sure you can make it work in a non object oriented environment, but I could be writing everything in assembly too. I don't choose to write everything in assembly, and I'm not going to use a GUI tool kit that isn't object oriented. You can argue that GTK is object oriented C but that completely misses the point since object oriented languages assist in a particular design methodology. Oh, and i'm aware of the C++ wrappers for GTK+ which are just that wrappers, plus they are ugly and poorly maintained. I'm not going to spend all my time debugging the wrapper when I could be getting useful work done.
I don't think his point was that they are recieved in orbit (but they could be given a directional antenna), but rather that they do go into orbit and could thereby be classified as international if someone was looking to stretch the definition of an international call.
Slashdot Mirror
Yeah - it would take a change to someone who was dumb on the concept of cost/benefit analysis.
I don't see how that changes his point.... It would be sort of like the US goverment not allowing the IRS to setup a web page to do peoples taxes because it will complete with the tax preperation companies. Even though the IRS pointed out that it would save the goverment money because more people would file online, and its cheaper than having people opening envelopes and scanning tax returns.
Lets see here...
They removed the 200G limit on mapped files... Wow thats useful for... well nothing unless you have a 64-bit machine.
Larger than 220M driver images, again really useless, the average windows driver is less than a meg.
Larger registry's, so now you can consume more than 300M of memory for your registry, which is just silly, frankly if your registry is that big you need to run a registry cleaning utility
Changes to the default use of large pages.. primarly a debugging tool, and a slight performace decrease if you only have 128M of ram on XP
More efficent work set trimming, which is nice except it doesn't work as advertised with my tests which show that the 2000 VMM is acually faster for systems with fewer than 4 processors
Reduced lock contention, again won't affect the majority of desktop users which have 1 or two processors.
So i'm getting bored... about the only things in that whole list that might help desktop users are the "faster hiberate and resume, a the system restore/and driver rollback" options.
On the negative side, I have to call M$ every few months when I want to resinstall the OS on my PC because i've changed the motherboard or upgraded to a larger harddrive as my system drive.
No thanks, I will stick to 2000... and when it finally gets to the point where 2000 is completly unusable I will finally switch my primary OS to linux (even though I think it is an archaic piece of crap).
What I was saying was that LTO-3 stores 400G uncompressed, the tapes are less than $70 and the drives are less than $2500. Sounds like its time for you to buy a new tape setup.
Time to get current with tape, LTO-3 Drives are
Register passing has always been supported, of course passing more than 4 parms was a problem, but not that much of a problem considering research about this pointed out that most C functions had less than 4 parameters. Even so, the x86-64 extended this enough that its really a non issue.
Modern BIOS's have 32-bit entry points, which are used by all major OS's. This has been true for a long time. This isn't really an x86 issue so much as a platform issue anyway..
Trust me on this one, the x86 compares very favorably to other high performace CPU's on actual absolute context switch times in major OS's. These numbers are a lot more complicated than just counting the cycles the manual says it takes for the sysenter call (for example TLB flushing if nessisary and associated reloads, etc). A quick google search provides an old example: http://www.ro.feri.uni-mb.si/predst/martin/4_12_20 00/301specs.html. and another http://www.ebsnetinc.com/RTKernel-RISC-real-time-p erformance.php. I've seen some more recent charts and they say similar things. The OS ive worked on had hundreds of lines of code (PPC based and another ARM based) to do the same thing the x86 was doing in just a few heavier instructions and the net result was a wash.
I'm not sure what in particular your talking about (memory table lookup? hu? sounds like your talking about indexed address modes). The talk about COW and dirty page flushing sounds like don't know about the INVLPG instruction. COW and dirty page flushing are OS functions having single TLB invalidate instrucitons like INVLPG make that as simple as updating the page, followed by TLB invalidate.
Your confused, or you may have been running a 486. The 6x86 line from cyrix was _VERY_ competitive with anything on the market. There only problem was one of perception, its like intel paid people to write bad reviews or something. When cyrix released the 6x86 it was suppost to work in every motherboard on the market. The only problem is that it required more current than the pentium's because it was a fab generation behind and a good percentage of the motherboards were unstable with the extra current draw. This caused a motherboard compatability list to come out, which everyone promplty ignored, then M$ disabled the L2 cache on cyrix for windows NT because the only cyrix they had (all of M$ had 1 cyrix) couldn't run it without crashing. Turns out that it was running on an unsupported motherboard which was getting bus reflections when it was doing burst transfers. The final blow was that everyone started using quake as a benchmark. While the cyrix 6x86-133 was labeled as a PR166 it ran more like a P90 in quake. This is not unusual even today, I can find benchmarks that prove the P4 is way faster than the P ratings on the AMD's. Its just a case of which benchmark you trust. Turns out that ID software had optimized quake for the pipeline arch of the pentium and didn't have an alternate code path for the cyrix which had a very strong math coprocessor but it didn't do back to back multiplies like the Pentium did. So some selective benchmarking pretty much was the final blow for a very good product. I ran linux on my 6x86 long after I purchased an MMX pentium to play unreal. The 6x86-166 was far more responsive running X and assorted other crap than the MMX-233 I had was. At that time AMD was draging its feet getting the K6 out.
BTW: I am old enough to remember the 286 and granted AMD's 286-20 and their 386-40 were reasonable processors, but they didn't compete with intel on the high end. By the time the fast (>16Mhz) 286's were out intel was selling 386's at the same clock rate and the fast 386's were competing with 486's.
Yah, right... all the ancient civ's that we have information about wrote on _STONE_.
Battery absorption rate... maybe, that is why from what I understand everyone is moving to putting large capacitors in for this function. http://www.nasatech.com/Briefs/Apr00/LEW16876.html . On the other hand i'm not sure what he is talking about when it comes to added weight, since the regenerative braking systems don't really add anything when it comes to a direct drive hybrid, you have an electric motor that acts as a generator for braking and is used for driving when in battery mode. Compared to a pure electric vehicle there is weight gain, but that is not what we have here.
The diffrence is that each year porsche releases half a dozen porsche's and intel 2 dozen processors. Not only that but the porche numbers tend to stay the same from year to year, after saying I have a 944 the next question is which year. The product placment relative to the other models 914, 911 etc stays the same, porche never released a 914 that was faster than the 911. That is not what happens at intel, this years 640 vs next years 720 compares how? With numbers to designate product lines 914 was the low end car 911 the high end car. Easy to remember, end of story... Today I can't figure out what processors are better when I look at the list and I'm in computers, it takes 10 minuites to figure out which ones are the high end and which ones are the low end, then since the low end of the high end line is slower than the high end of the low end line which one is better? If they are going to pull this crap, they need to make 4 processors a year, one desktop processor, one inexpensive desktop model, one server processor and one low power model. Then they need to call the desktop processor the same from year to year, with maybe a minor series bump to detect the diffrences between years.
Chuckle, yah we are using XFS too, but there are limitation in some versions of the linux kernel at assorted places that keep it from getting very large too. There are a number of patches (from what I understand some of which have made it into the kernel recently) that allow it to get larger than anything we have here. Problem temporarly solved.
I have a few systems here at work that have many Tb of storage and bandwith requirements >1G/sec. It would be nice to see someone accually test this kind of setup with the linux file systems. From what I've personally seen XFS is just about the only legitimate solution for our application (its not exactly optimium either, its getting its butt kicked by NTFS). This is because linux simply uses to much CPU to maintain any reasonable throughput (aka >500Mb/sec) and the larger file systems tend to either get so slow as to be unusable, or they simply don't work.
I don't know about the setup being tested, but when I ran Reiser on a very large (many Tb) file system I discovered it gets slower the larger the filesystem, after a while its simply to slow to use. So while it may "support" large file systems, I'm betting no one has plugged it into a 50Tb file system to see if it really works.
Not counting comments white space and other crap (couple of includes etc), here is the code that gets generated. Formatted to avoid the lame filter.
WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)
{try
{Application->Initialize();
Application->CreateForm(__classid(TForm1), &Form1);
Application->Run();
}catch (Exception &exception)
{Application->ShowException(&exception);
}return 0;
}
Of this the only real line that gets inserted to create the form with the text box is the CreateForm() call. There are a few more comments and a couple lines of #include in the module for the form, the only real part is the empty constructor. I don't count the resource fork as code, since In a few years of using BCB I've never had to edit it so its effectivly transparent.
Thats funny, you should talk to the java programmers here. It might be funny, I personally dislike the java OO model. I think it sucks. I do like C++ though, and I really like the VCL that borland makes (since C++ doesn't enforce an OO model). In my opinion what is taught as OO (especially with java) is so far away from what it was meant to be, i've decided to sign onto the "component" bandwagon. This better describes the way I use, and the way I write code. Small components which have definite purposes and are _SELF_ contained. In other words they don't tend to depend on big inheritance tree's and they can be used simply by learning smaller well contained interfaces. I'm not afraid of procedural code using objects, nor am I afraid of setting a public member variable. Hell I even create global classes to deal with global resources instead of passing a refrence around to every method in my program just to access 1 instance of a class. I rarely use static members, and I use constructors and destructors for what they were meant to do rather than making start() and stop() methods. Personally after having seen getter and setter messes created by other programmers I never use them unless they acually have work to do. I would rather go back and change 1000 x.y=z's to x.sety(z) than write a bunch of useless code that doesn't do anything and has to be maintained.
When I for instance look at the code 'window.width = 50', the principle of least surprise is violated (as is too often the case in C++ already).
I agree with this, and that particular example comes from the VCL, which tends to do a lot of things automatically for you. This means that you pretty much never have to call the repaint() method. It makes sense after using it for about 30 seconds. The VCL follows a simple rule. Variables (accually properties) which affect something have there affects felt as soon as they are changed. So you simply set the width and if the window is visible it resizes, you set the visible=true property and becomes visible, you create a new button giving it a parent window in its constructor and it paints on the window you specified. If you set a database field to something it updates the result set. The list goes on. Once you get used to this it is a _VERY_ natural way to program. There is sort of a unwritten rule about what ends up as a properly and what ends up as a method though. Its a fine line, and i'm sure a lot of people cross it (maybe even me sometimes). In general if the method accually does something then it gets a method. Which isn't very clear, but if the intention is to resize() the window then you make a method which takes the height and width. Its like operator overloading, a.add(b), a=add(a,b), or a=a+c. Which makes more sense, well in this case the last one does but it may not be clear all the ugly stuff going on behind the behind the scene especially if you didn't relize that a and c were vectors. Same with win.width=50; If the window isn't visible all I wan't to happen is have the width set, if its visible I want the width set and the window repainted.
Or is it you? Show me a piece of code that runs faster with a C compiler than the same piece of code with a C++ compiler from the same manufacture. Maybe you don't understand that if you write code that doesn't use the "slow" features of C++ its the same speed as C. Even then when you use virtual methods, compare them to the performace you get with structures of function pointers in C. Then there are things that acually make C++ faster than C, like for example templates and exceptions. Look up template meta programming on google if you don't believe me. I know of at least 1 compiler that accually generates faster code for the C++ virtual methods can get generated by the C function pointers. I think at this point most of the C compilers out there are acually just C++ compilers with a slightly diffrent parser running on the frontend.
I don't think C++ is now, or ever was (or with the way these "extensions" keep showing up) - or ever will be suitable for Systems Programming.
This is complete and utter BS, I have written a number of drivers using C++ in enviroments that didn't officially support C++. I have also written a microkernel that runs on a number of embedded ARMs in C++. C++ is a wonderful systems programming language, I no longer have to manage function tables, deal with a lot of error handing etc. System calls are a natural place to create a "transaction" that can be aborted by an exception, as are SLIH's the list goes on. I'm not the only one, a number of other people have C++ based kernels and drivers. Writting an OO kernel also encourages you to have interfaces between the diffrent subsystems, this is something linux strongly needs and doesn't have.
cout
cout is in my opinion stupid, and I don't use it, so I don't care if its slow (plus its not internationalized, and hard to convert, unlike the printf family). Plus most people don't understand that it tends to creates temp objects all over the place, and that is what is slow not cout.(this reminds me of Java, which isn't always slow, but it encourages practices that are)
Because the C++ programmer infrequently can understand what his runtime is doing- and is not encouraged to know the interface by which C++ does it's magic (because nobody knows- they're still trying to figure out how to make some C++ magic work in a way that isn't slow)- a C++ systems programmer needs a C++ runtime. Nobody has one in systems-space, so the C++ programmer (which isn't a programmer of C++) needs to write it.
This is utter BS too, it isn't any harder than C, in fact its almost the same as C except for virtual methods, RTTI, and exceptions. The rest is basically all compile time. RTTI is off by default on most compilers because it can slow things down, exceptions and virtual methods usually only take a little while to understand how they work with a given compiler. If its not documented then a few minuits in the RTI and stepping through the call or excption with an assembly debugger should make it perfectly clear. In fact as part of using C++ in a kernel mode enviroment I have implemented a number of C++ startup and basic support libraries, the biggest one was probably 200 lines of code (because you can't include the full C++ or for that matter C runtime for usermode, with C that code is usually already in the kernel so you don't need to generate it again). Mostly it was simply changes like overridding global new and making it call the kernel allocator, setting up the module/driver/kernel load routine to call the constructors/destructors for global objects, and other really simple things like that.
Borland C++ can do it without any code. Click add new project, drop a label on the form type "Hello world" into the caption property, click run.
Of course there are about 4 lines of code generated when you create the project and a line to create a new Tform but other than that....
Syntactic sugar for getters and setters can be useful for providing a more natural interface (as long as people don't abuse them), but they don't really have any place in a language like C++, where almost everything is set in stone at compile time.
I don't see how binary compatability has anything to do with it. You can't change a member function to virtual or add a overloaded default parameter either without breaking binary compatabilty. Personally, I've used two diffrent C++ implementations with properites and you would simply be amazed at how useful they really are. Besides its not like C++ to force people to write code that is explicit. Look at the refrence syntax that allows you to pass a variable that may or may not be modified. Ex: in C Myfun(a) could never modify a, with C++ it can. Now I personally _NEVER_ use non const refrences, but it is there.
What C++ needs is some form of binary interface though. Part of the reason so many people are still using C or (extern "C") is because its still the only standard way to write a libary that other languags can access. Hell often times you can't compile your C++ program with one compiler, and another part with another C++ compiler and expect to be able to link them together. This has really got to stop. There are a lot of techical issues why this would be hard (while maintaing the ability for vendors to do a lot of vendor specific optimizations), but it can be done. Especially if another keyword were to be added to specify external interfaces, or the compiler were expected to dump some kind of meta file about the interfaces.
This is just a silly statement and refects a very shallow knowledge or programming. I've seen what happens when "no public variables" type people try to write real applications. 30% of the application code is just simply getter and setter methods, which really makes things ugly.
The whole OOP paridigm could be called "syntatic sugar" after all I can write code like myfun(var) rather than var.myfun(). The idea with properties is that its often times a _LOT_ clearer to simply say window.width=50; than window.setwidth(50). Especially when instead of 50 its another function call, or a complex expression. Its all sort of a matter of taste, also having the ability to design a class and then go back and change the behavior on the fly when someone changes a variable completely removes the need for shitloads of getter and setter methods.
Like I said you don't get it. Passing function pointers around, and messing with tables of function pointers is not object oriented programming. Its procedural programming with a bunch of function tables. Object oriented languages support this kind of stuff without a bunch of manual code. Its like my comparison to macro assemblers, you can write all kinds of high level macros to simulate for loops, if then else conditionals etc. At the end of the day though your still programming in assembly not some high level procedural language. This means that the syntax will be clunky, and when the maintenance programmer shows up they have to learn a bunch of system specific macros. Running GTK in a language with OOP support doesn't make it mysteriously OOP either.
That is not what I said. What I said was the people like you claim it is. Its not, anymore then it is possible to write high level code in a macro assembler.
In practice, does this happen very often? More pointedly, what evidence do you have that GTKmm is poorly maintained? Murray Cumming will be very interested to hear why you think that, especially as he puts out new releases with the Gnome release schedule, every six months.
Every time I go to use it, I find bugs. Which is every year or so, as such I conclude its poorly maintained. Or maybe poorly excercised is a better description. Maybe its just me, but the title of this thread is "Why I won't use GTK"
It sounds like your criticism is mainly that you don't like C for GUI programming and are therefore damning all of GTK+, even though many programs written in other languages use GTK+ happily.
Thats right, I think using C for GUI development is not the most intellegent idea. Sure it has better language bindings, and if your writting GUI code in perl, then go for it, GTK+ fits just with the midset of the kind of person that would consider writing a full GUI application in Perl. Personally I am going to use something that does more to assist my development than hinder it. I'm constantly amazed at the stuff you have to do manually in some of these GUI toolkits. As I sort of stated in another post GTK+ and Glade remind me of doing GUI programming in the early '90s with Borland's OWL and ResourceWorkshop. Today I expect an enviroment more like Borland C++ builder. The techical diffrences (why one is better than the other) are hard to point out, its more a collection of small things that come together to form a complete whole. Some of it is just synatic sugar designed to make things more intutive. For example being able to say MyForm.Width=500; and have the GUI redraw the form to match the given width (if the form is visible, otherwise to save the property) without having to call a function to redraw the form, or call a method to set a property. Another thing that is really nice is having icons/images/default properties stored in resource forks instead of hardcoded into the code somewhere that a resource editor has to parse out. The list goes on things that can be done in C++ for example code like `MyNewform SpecialForm(self);` to get a new form using default properites and have it automatically paint. In the short term it may not seem like much but when you have a GUI toolkit that allows you to write 1 line of code instead of 5 you only have to maintain a 50k program instead of a 250k one.
Yah good point, only since windows was originally running on DOS many of the good file name extensions were taken. For example '.MOV' was the RLE encoded movie format used by autocad, 3ds and others for the autoflix. '.SND' was the Tandy deskmate sound file. .pict was to long (8.3 format) and a number of the pxx formats were used by paint programs. '.PIC' has the following hits http://www.google.com/search?hl=en&lr=&q=DOS+.pic+ +format. PCX was particularly popular.
Back then though all the mac people used to point to the file name extension in DOS/Windows as a bad practice and a reason why the mac was better (the filetype was hidden in the resource fork and tied to an application).
This sort of belies the fact that you haven't done any windows programming. Much of the "look and feel" is determined by windows. AKA the window manager. If you write your application properly (ie don't invent to many custom components). Then things just tend to work when you go to new versions of the OS. Oviously there are special cases, but the majority of the look and feel of the OS is determed by the OS not the applications. Now if your application is written using GTK then when you pop up a file open dialog your getting the GTK version not the windows common dialog (which almost always changes between windows revisions) and as such the things the users expect (like being able to view image thumnails vs detailed view) don't behave the same way, if they even exist at all. This is why things like the scroll wheel on the mouse just work in windows (and always have for windows applications, applications ported from linux tend to have the same problems in windows that they had in linux with the wheel). Its because the mouse driver is simply sending WM_SCROLL messages to the top level application window. Because its just the right way to scroll a window, when M$ came out with the scroll wheel it just worked in applications that had never seen a scrolling mouse in thier whole existance.
I assume when he says builder he is talking about the borland products. In that regard glade is more the the resource editor that came with borland C++ back in 1990, than anything that they currently ship. Techically its hard to pinpoint what exactly the diffrence is though. Its more a statement of integration and toolkit/framework/component design, combined with clean syntax. In this regard even borland extended C++ to add the property keyword (and Visual Studio now supports it as well). So its hard to describe, its more like the polish that comes from a bunch of tecnically minor things coming together to form something that just works.
Basically its archaic. GUI development is one of the few areas where object oriented design makes a big difference to the programmability of the system. This has been known for the better part of 15 years. All those little buttons/menus/combo boxes/etc with the hundreds of properties to control behavior. The need to override behavior, the need to hook events. The list goes on. Sure you can make it work in a non object oriented environment, but I could be writing everything in assembly too. I don't choose to write everything in assembly, and I'm not going to use a GUI tool kit that isn't object oriented. You can argue that GTK is object oriented C but that completely misses the point since object oriented languages assist in a particular design methodology. Oh, and i'm aware of the C++ wrappers for GTK+ which are just that wrappers, plus they are ugly and poorly maintained. I'm not going to spend all my time debugging the wrapper when I could be getting useful work done.
I don't think his point was that they are recieved in orbit (but they could be given a directional antenna), but rather that they do go into orbit and could thereby be classified as international if someone was looking to stretch the definition of an international call.