Meh. Most Delphi nuts don't know anything about the history of their language, much like Visual Basic people are often appalled to learn about GOTO and line numbers.
I mean hell, there are a lot of C++ programmers out there which think that running out of RAM isn't a good enough reason to throw an exception, hence (nothrow) new.
The logic behind this: If there isn't enough ram to perform an allocation, what makes you think there is enough to allocate for an exception? If the exception can fit in ram, great, you can handle the condition gracefully. If it can't, you would never get an opportunity to handle it gracefully. If you try to handle it both ways (throw if you can, return NULL if you can't) you just made your code twice as complicated for no reason.
Uh, sorry. It's been common practice for about 20 years to allocate a small block of emergency RAM on the start of a program, then to release it on catching bad_alloc to give some space to work with, or alternately to pre-allocate the space for a bad_alloc exception. Remember back in the day when DOS programs would warn you to kill TSRs because you were running low on memory? C has never had any mechanism to determine the amount of remaining memory, and neither did DOS; how do you think that was accomplished? (Answer: they pre-allocated a block of 32k or so, released it when things got tight, and displayed a near-panic message.)
The real logic behind nothrow new is threefold.
First is that C/C++ are hardcore portable languages, and it is frequently the case that efficient implementation either requires missing hardware support such as interrupts - which exceptions are not required to be implemented through - or when the existing operating system wants exceptions to be thrown through it, typical of single-process multithreading embedded OSes like PalmOS and the suspected operating systems underlying the Nintendo DS and Sony PSP. In those cases, the exception system shouldn't be built in at all, and that C/C++ allow this to be removed is what allow developers for devices like that to have access to modern high level languages.
Second is that C/C++ is intended to support industrial and military caliber development and use, which introduces huge reliability, uptime and realtime considerations. Exceptions are a safe general mechanism for machine error handling, but when you're controlling a nuke, a medical imager, a construction crane or a satellite, you have very specific new error and exception handling needs, and no generic mechanism will ever suit you. Furthermore the way in which C/C++ exceptions are implemented makes realtime programming sickeningly difficult; it's possible, but damned hard, and it's often easier to replace the nightmare situation code than to hand-comb everything else, especially considering that failing in an existing exception situation is frequently less costly than failing in normal situations. By comparison, commercial development for closed platforms often sees large returns from hooking device error handling hardware up to language error handling mechanisms in that their clients have dramatically simplified problem behavior and can therefore develop that much cheaper. In both the cases of high-reliability and ease-of-sealed-deployment, removing the exception code entirely is frequently a big financial win - and more than occasionally a prerequisite - for using the language in that situation.
Third, the most common, and the viewpoint to which I was referring, is that running out of RAM is simply not an exceptional situation, and that therefore it should not be handled through exception mechanisms. Most of these programmers are commercial programmers from the days when a machine with four meg of RAM was considered well-equipped, and are therefore used to applications actually running out of RAM. It's easy to handle, and there's just no need to throw yourself into application panic. You wouldn't call UNIX panic over running out of RAM, would you?
In general, one isn't worried about recovering gracefully from exceptions. This is why I think your home language isn't C++ - and this isn't a jab at you using the language fr
It never ceases to amaze me how deeply people believe that one cannot have an OO model, including destructors, without language support. You do realize that C++ was originally rolled in C, don't you?
a) the fact that the picture has been published without the publisher being sued into oblivion shows clearly that the woman in the picture was perfectly content to pose for, and profit from, it's publication
Or she's unaware that a picture was taken at all, or she's unaware the sorority prank made it to the net, or (get this) she's got a sense of humor.
b) most male geeks don't get laid because
Wrong already. The ones that get laid just don't speak up because the stereotype is almost as funny as the people which believe it and try to make rational arguments with it. (There is a surprisingly strong correlation between the second crowd and people which never realize that it might just be that the girl had a sense of humor.)
c)... , d)... , e)
Oh, shut up. You're the same person that thinks that movies lead to violence, aren't you? Racist jokes don't lead to racism. Anyone which turns racist because of a joke or a book or a movie was already pretty much there, and any little thing could have tipped them over; it's not the joke or the book or the movie's fault. Talk to the idiot's parents, not the person trying to tell them jokes.
Java uses exceptions to handle most problem conditions, including things as trivial as conversion errors and preventing the use of unallocated object instances (a particularly easy example comes in the form of trying to use a BinaryWriter without creating it first, thanks to checked exceptions.)
C++ uses exceptions quite differently. In C++, error conditions are not a reason to throw an exception. Exceptions are last-resorts. If someone detatches the drive while you're using it, then you throw an exception. I mean hell, there are a lot of C++ programmers out there which think that running out of RAM isn't a good enough reason to throw an exception, hence (nothrow) new.
While anything allocated on the stack will be destroyed when an exception is thrown
C++ exception handling was specifically designed to make this not true. Consider reading Sutter's dialogue on the difficulty of properly implementing constructors and destructors for safe behavior in exceptions, since the particulars of stack unwinding during exceptions and allocation/deallocation failures during construction are so complex. Nonetheless, it can be done if one knows the rules; grab the Sutter Trio, the Meyers Trio or the C++ Faq book if you want to find out how.
There is a trivial example about halfway down this MSDN page.
you never get an opportunity to clean up after the error condition
Yes, you do, by design.
To make matters worse, you never get an opportunity to rollback the state of the operation when you throw the exception.
You get control back safely, and if you implemented the Command pattern, you can make that rollback quite easily.
Not to mention the complications that arise when SEH is thrown into the mix
What problems do you suggest structured exception handling adds to an exception mechanism which, no offense, you're apparently not particularly familiar with in the first place? Particulars would be nice; it might be that I can provide you with the resources you need to use these admittedly difficult tools correctly.
Obviously you can write code to work around that.
No, you really can't. See, this is the difference between C++ and Java exceptions: Java exceptions get thrown a lot. You should never, ever see a C++ application throw an exception; if they do, they're 1) buggy, 2) written by programmers from languages with different opinions about exceptions, or 3) really buggy. Exceptions in C++ are for handling serious machine failures, not software errors. Software errors can be handled by less intrusive means with far less overhead and far less complicated rules about resource unwinding.
To be plain, if you're attempting to use C++ exceptions to catch code failures, you don't understand the purpose of exceptions in C++. Just because they use the same keywords doesn't mean they're particularly related.
Then, there is the overhead of actually throwing an exception... making a pure virtual function call is cheap in comparison.
Frankly, the cost of a last-ditch "holy crap the machine just went apeshit" mechanism isn't important. You should never see an exception. Exceptions in C++ are for corporate-level fault tolerance, and nothing else.
Those implementations that do support OO-style programming usually aren't called Pascal
Or Borland Pascal, Turbo Pascal, Berkeley Pascal, GNU Pascal, IRIE Pascal, FreePascal, etc.
By the way, Delphi, Oberon and Modula are Pascal in the same way that C++, C# and ObjectiveC are C, that C is BCPL and in fact that Pascal is C. That is to say, they aren't. (Delphi is Object Pascal, not Pascal. Object Pascal is further from Wirth/ANSI Pascal than C++ is from K&R/ANSI C.)
But I was shocked to see that CALLBACKS were put down by C++ purists
I don't know any C++ "purists" which say that callbacks are bad. What you may be confused by, which I suspect is the case since you're so happy to excahnge case, is that CALLBACK - a windows calling convention frequently used by people when totally unnessecary - was being panned. It is frequent for novice programmers to think that to make a callback one must declare with the calling convention CALLBACK, which makes their code non-portable.
Callbacks are simple, easy to portably implement, and very very common in C++. They're the primary event handling mechanism in both single threaded and re-entrant C++. The idiomatic implementation is
The freeing of resources, all resources not just memory, is automatic in C++ once you learn to use RAII.
Look it up. It is one of major improvements of standard C++ over C/C++.
What are you talking about? Resource acquisition is allocation is a technique, not a language facet. I use it in a dozen languages. It's just an idiom, and it works perfectly well in C.
It is believed that Trident 7 will do the same thing previous Tridents have done: keep broken backwards compatability in quirks mode, and get as close as the engine is able to get to compliant in strict mode.
By the way, only width is treated as min-width. Height is treated correctly.
Of course not as compact as C but nothing else is that small.
Assembler, portable assembler, Forth, ml, IO, Small, TIPI, SR, MPD, TCL, TIMI, Shakespeare, uL, Brainfuck, K, NICE, and pretty much every domain-specific language I've ever seen come to mind as significantly smaller languages, and they're all usable except Brainfuck.
Now that is a big language even without STL.
The hell are you talking about? C++ is a tiny language. It only added sixteen keywords to C. Both C and C++ are miniscule because of the design decision to put almost everything into the libraries. The reason this was done was to make the C runtime easy to port, and it has succeeded fantastically for the sole reason that the standards committee has been unwilling to add almost anything to the core language.
If you want a real sense of the size of C and C++, you have to look at unhosted compilers without libraries. When you realize that that means you won't get new or malloc, you'll get a real sense of just how small those languages actually are.
If, on the other hand, you count the standard libraries for C++, then you have to count them for C, and the libraries for C make C larger than almost any language out there (it has real competition in C++, Java, Ada, Fortran, and COBOL; nothing else.)
Besides, the STL isn't very big in comparison to the rest of the C++ Standard Library, or even in fact to the C Standard Library. Just because it's the part you see and use most often doesn't mean it's particularly big. (And just because your implementation is big doesn't mean the spec is big. Have a look at an old STLPort instead of Plaugher's or RogueWave's STLs, both of which are extremely large.)
Yeah, yeah. We've heard that since Borland moved away from Pascal as its only product back in 1983. If you'd actually look, Borland's market share is growing, their pockets are getting deeper, and they're reaching more platforms. That's a hell of a balancing act for a dying company, that growing, getting rich and powerful bit. Wonder how they're managing it.
As far as Java dying, I don't know, and I don't care. It was stillborn with momentum.
What makes JBuilder so terrible is its non-native GUI. The thing just looks bad with its GUI that's almost Win32, but not quite. Ctrl+Tab doesn't switch between code panes as you would expect in any Windows app; instead it uselessly switches between panes such as Project and Structure.
This is Windows recommended UI behavior for MDI apps. Read the interface standard.
But by far the absolute worse was its ignorance of Windows' ClearType setting for font smoothing.
That's funny: it works here.
Lots of people switch their editor fonts; many people use the font FixedSys, because it has good pixel choices. The reason it has good pixel choices is that it's a bitmap font, and is therefore unhintable in cleartype. This is the basis of most people thinking mIRC has broken cleartype support, too: it ships with FixedSys as the default window font.
Do note that there is no API call in any version of Windows from Win16 on which would not be hinted by ClearType; if Borland broke ClearType, then they remade every single bit of font drawing code from the ground up. The chances they did that are miniscule. Perhaps you just need to spend more time looking for the problem, before announcing to SlashDot how broken something is?
There are other GUI differences but I'm a horribly nit-picky person when it comes to UI
And, unfortunately, your nits picked are in contrast with the Win32 interface standard, as your demands for an MDI app to follow SDI behavior above show.
You need to learn that there's a difference between being a stickler for detail and whining that things don't work the way that you expect for them to. One is born of familiarity with existing standards; the other is clueless self-aggrandizing pablum. It's not Borland's fault that you don't know more than the very basics of Win32 UI behaviors; every single one of their pane and task switching hotkeys, including f10 and f11, are standards that have been with us longer than a default Windows TCP/IP stack. Hell, Win/QVT supported these. Maybe you should watch that movie that comes with a fresh XP install.
But it's not bad if you get used to it, so it's probably just that I'm unfamiliar with Eclipse.
Or Win32 UI standards. Or JBuilder. You actually suggest that Eclipse is more configurable than JBuilder. Have you even looked?
Let's see. If you were given the assignment to "parse a web page for data", what would you do? Hell, let's make that "parse anything for data". The first thing you'd do is that you'd find out some tell-tale signs of where information starts and ends. This could be different on different sets of data, or it could be consistent; on a web page, it'll almost certainly be inconsistent between these pages.
Um, sorry, those are what XHTML, OWL and RDF are for. RSS does not arise to combat this.
So what RSS (and Atom, another similar but more extensive format with the same goal that falls under the same buzzword) is is simply an easy format to deliver serial data in.
RSS is just a content aggregation feed. It's just an automatically provided synopsis, arguably something news sites have been doing since day one with the front page headlines and first paragraphs, and something newspapers have been doing for two hundred years with the first column and "continued on page A7." You make it out to be this thing about the extremely general topic of serial delivery, but it isn't; it's just a new content notifier, no different than Usenet, FidoNET, email, archie, wais, prospero or bluewave.
RSS is in fact extremely badly suited to serial delivery; there is no description of any sequence other than time, so you can't tell which things are followed by which other things - the very basis of seriality - when there's more than one thing being pushed out of the feed. Moreover, there's a huge amount of descriptive material such as title and superficial textual content which have nothing to do with seriality. It's just a content aggregator, nothing more.
All RSS is is a standard such mechanism so that uniform readers for content aggregation may arise. It's, as other slashdotters keep pointing out, just a badly reinvented fido/usenet.
Do remember that FidoNET, from July of 84, is a year and change older than Usenet, which properly starts during UUN's Great Renaming in 1986, and that some geezers still think it's better designed.
(Before anyone flips out that UUN was from 1979, please remember that the debate is over network architecture, and that UUN used UUX/UUCP; NNTP, which is the architecture to which parent refers, is first proposed in February of 1986, and doesn't see wide-spread use until late 87/early 88.)
A much better idea would be to deprecate email as it is currently used, and actually capture intra-office communication in some issue-tracking system, wiki, or other appropriate system.
It'd be much cooler if you were named Clarke, so I could say "welcome to 2001" all sarcastic-like; now all I have to work with is Gateway, and nobody would get it anyway. But, sure, capturing e-mail is nothing new, and good lord, we've been tracking our communications as threads on a private NNTP server for almost 20 years now. Also, there's been automatic majordomo browsing since Gopher, and back in the days of BlueWave...
I tend to agree with Flexible. Yes, RSS can be productively used as a way to keep people abreast of changes, but that doesn't mean it's a good idea. We have both a bugzilla deployment with email notification and a mediawiki deployment with RSS notification; because they're both gathered by Thunderbird, you'd think they'd be transparent to me, and that RSS would be at least as good as email. This turns out not to be the case: it's very frequent for us to need to discuss issues that come out of project controol and/or bug control, so even what's going around in RSS eventually gets pushed around email anyway, and then it's a giant pain in the ass to find anything. (Google mail would partially ameliorate that due to its search mechanism, but there's no reason for the problem to exist in the first place.)
It's my opinion that you're addressing the wrong question. What's important isn't whether RSS is good enough to use; there are tons of things that are good enough to use. The question should be whether RSS offers any compelling benefits over the existing mechanisms, and to that I suggest that the answer is a resounding "no."
Where I work we started doing this with JIRA and Confluence, both of which offer RSS feeds so that you can stay up-to-date on the changes within those systems. The combination is powerful, and I recommend it without hesitation.
What about it is better than the existing email notification mechanisms, and what justifies moving to something other than the existing well understood mechanisms, causing problems in sorting, especially when RSS is a pull-only mechanism?
Be sure to look into Jot, which has a lot of code dedicated to supporting this sort of stuff, including the relatively odd notion of sending email to a page. Email is just as flexible as RSS; it's just not new, shiny, and buzzwordic. What benefit do you suggest RSS provides?
If you were to read the Mozilla project's documentation on the issue before announcing your judgements, you'd learn that the naming prefix is actually a measure of caution. It has been common practice in the Mozilla projects since around 0.6 days to expose partially implemented standards under incorrect names, so that designers can test drive the implementations and look for problems. The same has been done with dozens of other CSS properties, and the same is currently true of quite a few CSS3 properties.
The general pattern is that when the Mozilla foundation is convinced that the implementation is both complete and correct, it will be altered to respond to its correct name.
This is hardly embrace and extend. More accurately this is "keep the not-finished stuff out of the hands of people which blindly use anything they can find, instead of reading the documentation, deciding something half-done is broken, and go off trumpeting how broken Mozilla is." Which is, I suspect, exactly what you'd be doing right now, since you're so willing to judge things you haven't even bothered to look up.
They are going to support CSS3; I don't know where this "if they were going to" crap comes from, since a significant chunk of CSS3 already is supported. Here's a hint: Mozilla does many many things that CSS3 does not. That's not embrace and extend at all; that phrase refers to ruining existing standards by bloating them out, pretending that things which aren't part of them are, and confusing the end-user as to the nature of the standard. Netscape used to participate in things like this, but hasn't in a long, long time.
4, 2, 4, 1, 2, 1, 2, 2, 1. I don't see a dilution. Note that the two 4-year periods were difficult for N, as the NES penetrated the then-dead video game market, then later when Sega stole N's thunder by going 16-bit with nearly a year's lead.
A year and a half is the normal lifecycle for a console. Sony is the aberration, not Nintendo as of late.
and with a related consumer product (the Gameboy) whose design has managed to totally dominate its market continuously against technically superior competition.
Superior is a matter of perspective. Many people find that the single critical characteristic of a portable is battery life, and in that characteristic Nintendo has never been challenged.
Consider that that's almost the only characteristic on which they've maintained a lead, and that they've been wholly dominant the entire time. Coincidence or correlation? You can probably guess what I believe.
Slashdot Mirror
Meh. Most Delphi nuts don't know anything about the history of their language, much like Visual Basic people are often appalled to learn about GOTO and line numbers.
;)
But yeah, I was just nitpicking.
I mean hell, there are a lot of C++ programmers out there which think that running out of RAM isn't a good enough reason to throw an exception, hence (nothrow) new.
The logic behind this: If there isn't enough ram to perform an allocation, what makes you think there is enough to allocate for an exception? If the exception can fit in ram, great, you can handle the condition gracefully. If it can't, you would never get an opportunity to handle it gracefully. If you try to handle it both ways (throw if you can, return NULL if you can't) you just made your code twice as complicated for no reason.
Uh, sorry. It's been common practice for about 20 years to allocate a small block of emergency RAM on the start of a program, then to release it on catching bad_alloc to give some space to work with, or alternately to pre-allocate the space for a bad_alloc exception. Remember back in the day when DOS programs would warn you to kill TSRs because you were running low on memory? C has never had any mechanism to determine the amount of remaining memory, and neither did DOS; how do you think that was accomplished? (Answer: they pre-allocated a block of 32k or so, released it when things got tight, and displayed a near-panic message.)
The real logic behind nothrow new is threefold.
First is that C/C++ are hardcore portable languages, and it is frequently the case that efficient implementation either requires missing hardware support such as interrupts - which exceptions are not required to be implemented through - or when the existing operating system wants exceptions to be thrown through it, typical of single-process multithreading embedded OSes like PalmOS and the suspected operating systems underlying the Nintendo DS and Sony PSP. In those cases, the exception system shouldn't be built in at all, and that C/C++ allow this to be removed is what allow developers for devices like that to have access to modern high level languages.
Second is that C/C++ is intended to support industrial and military caliber development and use, which introduces huge reliability, uptime and realtime considerations. Exceptions are a safe general mechanism for machine error handling, but when you're controlling a nuke, a medical imager, a construction crane or a satellite, you have very specific new error and exception handling needs, and no generic mechanism will ever suit you. Furthermore the way in which C/C++ exceptions are implemented makes realtime programming sickeningly difficult; it's possible, but damned hard, and it's often easier to replace the nightmare situation code than to hand-comb everything else, especially considering that failing in an existing exception situation is frequently less costly than failing in normal situations. By comparison, commercial development for closed platforms often sees large returns from hooking device error handling hardware up to language error handling mechanisms in that their clients have dramatically simplified problem behavior and can therefore develop that much cheaper. In both the cases of high-reliability and ease-of-sealed-deployment, removing the exception code entirely is frequently a big financial win - and more than occasionally a prerequisite - for using the language in that situation.
Third, the most common, and the viewpoint to which I was referring, is that running out of RAM is simply not an exceptional situation, and that therefore it should not be handled through exception mechanisms. Most of these programmers are commercial programmers from the days when a machine with four meg of RAM was considered well-equipped, and are therefore used to applications actually running out of RAM. It's easy to handle, and there's just no need to throw yourself into application panic. You wouldn't call UNIX panic over running out of RAM, would you?
In general, one isn't worried about recovering gracefully from exceptions. This is why I think your home language isn't C++ - and this isn't a jab at you using the language fr
It never ceases to amaze me how deeply people believe that one cannot have an OO model, including destructors, without language support. You do realize that C++ was originally rolled in C, don't you?
a) the fact that the picture has been published without the publisher being sued into oblivion shows clearly that the woman in the picture was perfectly content to pose for, and profit from, it's publication
... , d) ... , e)
Or she's unaware that a picture was taken at all, or she's unaware the sorority prank made it to the net, or (get this) she's got a sense of humor.
b) most male geeks don't get laid because
Wrong already. The ones that get laid just don't speak up because the stereotype is almost as funny as the people which believe it and try to make rational arguments with it. (There is a surprisingly strong correlation between the second crowd and people which never realize that it might just be that the girl had a sense of humor.)
c)
Oh, shut up. You're the same person that thinks that movies lead to violence, aren't you? Racist jokes don't lead to racism. Anyone which turns racist because of a joke or a book or a movie was already pretty much there, and any little thing could have tipped them over; it's not the joke or the book or the movie's fault. Talk to the idiot's parents, not the person trying to tell them jokes.
Your logging example is easily implemented in typical OO languages as the visitor pattern.
On another note, I think these types of critisms are really from people who are afraid of learning new languages or skills.
Curious, considering the criticism you levelled in response.
Those are called "functors."
I presume that Java is your home language?
... making a pure virtual function call is cheap in comparison.
C++ and Java see exceptions quite differently.
Java uses exceptions to handle most problem conditions, including things as trivial as conversion errors and preventing the use of unallocated object instances (a particularly easy example comes in the form of trying to use a BinaryWriter without creating it first, thanks to checked exceptions.)
C++ uses exceptions quite differently. In C++, error conditions are not a reason to throw an exception. Exceptions are last-resorts. If someone detatches the drive while you're using it, then you throw an exception. I mean hell, there are a lot of C++ programmers out there which think that running out of RAM isn't a good enough reason to throw an exception, hence (nothrow) new.
While anything allocated on the stack will be destroyed when an exception is thrown
C++ exception handling was specifically designed to make this not true. Consider reading Sutter's dialogue on the difficulty of properly implementing constructors and destructors for safe behavior in exceptions, since the particulars of stack unwinding during exceptions and allocation/deallocation failures during construction are so complex. Nonetheless, it can be done if one knows the rules; grab the Sutter Trio, the Meyers Trio or the C++ Faq book if you want to find out how.
There is a trivial example about halfway down this MSDN page.
you never get an opportunity to clean up after the error condition
Yes, you do, by design.
To make matters worse, you never get an opportunity to rollback the state of the operation when you throw the exception.
You get control back safely, and if you implemented the Command pattern, you can make that rollback quite easily.
Not to mention the complications that arise when SEH is thrown into the mix
What problems do you suggest structured exception handling adds to an exception mechanism which, no offense, you're apparently not particularly familiar with in the first place? Particulars would be nice; it might be that I can provide you with the resources you need to use these admittedly difficult tools correctly.
Obviously you can write code to work around that.
No, you really can't. See, this is the difference between C++ and Java exceptions: Java exceptions get thrown a lot. You should never, ever see a C++ application throw an exception; if they do, they're 1) buggy, 2) written by programmers from languages with different opinions about exceptions, or 3) really buggy. Exceptions in C++ are for handling serious machine failures, not software errors. Software errors can be handled by less intrusive means with far less overhead and far less complicated rules about resource unwinding.
To be plain, if you're attempting to use C++ exceptions to catch code failures, you don't understand the purpose of exceptions in C++. Just because they use the same keywords doesn't mean they're particularly related.
Then, there is the overhead of actually throwing an exception
Frankly, the cost of a last-ditch "holy crap the machine just went apeshit" mechanism isn't important. You should never see an exception. Exceptions in C++ are for corporate-level fault tolerance, and nothing else.
Those implementations that do support OO-style programming usually aren't called Pascal
Or Borland Pascal, Turbo Pascal, Berkeley Pascal, GNU Pascal, IRIE Pascal, FreePascal, etc.
By the way, Delphi, Oberon and Modula are Pascal in the same way that C++, C# and ObjectiveC are C, that C is BCPL and in fact that Pascal is C. That is to say, they aren't. (Delphi is Object Pascal, not Pascal. Object Pascal is further from Wirth/ANSI Pascal than C++ is from K&R/ANSI C.)
But I was shocked to see that CALLBACKS were put down by C++ purists
I don't know any C++ "purists" which say that callbacks are bad. What you may be confused by, which I suspect is the case since you're so happy to excahnge case, is that CALLBACK - a windows calling convention frequently used by people when totally unnessecary - was being panned. It is frequent for novice programmers to think that to make a callback one must declare with the calling convention CALLBACK, which makes their code non-portable.
Callbacks are simple, easy to portably implement, and very very common in C++. They're the primary event handling mechanism in both single threaded and re-entrant C++. The idiomatic implementation is
typedef int (*FPFloatReturnsInt)(float);
void RegisterCallback(FPFloatReturnsInt cbFunc) {}
int ExFunc(float Foo) { return (int)(Foo); }
int main() { RegisterCallback(&ExFoo); }
The freeing of resources, all resources not just memory, is automatic in C++ once you learn to use RAII.
Look it up. It is one of major improvements of standard C++ over C/C++.
What are you talking about? Resource acquisition is allocation is a technique, not a language facet. I use it in a dozen languages. It's just an idiom, and it works perfectly well in C.
It is believed that Trident 7 will do the same thing previous Tridents have done: keep broken backwards compatability in quirks mode, and get as close as the engine is able to get to compliant in strict mode.
By the way, only width is treated as min-width. Height is treated correctly.
Of course not as compact as C but nothing else is that small.
Assembler, portable assembler, Forth, ml, IO, Small, TIPI, SR, MPD, TCL, TIMI, Shakespeare, uL, Brainfuck, K, NICE, and pretty much every domain-specific language I've ever seen come to mind as significantly smaller languages, and they're all usable except Brainfuck.
Now that is a big language even without STL.
The hell are you talking about? C++ is a tiny language. It only added sixteen keywords to C. Both C and C++ are miniscule because of the design decision to put almost everything into the libraries. The reason this was done was to make the C runtime easy to port, and it has succeeded fantastically for the sole reason that the standards committee has been unwilling to add almost anything to the core language.
If you want a real sense of the size of C and C++, you have to look at unhosted compilers without libraries. When you realize that that means you won't get new or malloc, you'll get a real sense of just how small those languages actually are.
If, on the other hand, you count the standard libraries for C++, then you have to count them for C, and the libraries for C make C larger than almost any language out there (it has real competition in C++, Java, Ada, Fortran, and COBOL; nothing else.)
Besides, the STL isn't very big in comparison to the rest of the C++ Standard Library, or even in fact to the C Standard Library. Just because it's the part you see and use most often doesn't mean it's particularly big. (And just because your implementation is big doesn't mean the spec is big. Have a look at an old STLPort instead of Plaugher's or RogueWave's STLs, both of which are extremely large.)
Yeah, yeah. We've heard that since Borland moved away from Pascal as its only product back in 1983. If you'd actually look, Borland's market share is growing, their pockets are getting deeper, and they're reaching more platforms. That's a hell of a balancing act for a dying company, that growing, getting rich and powerful bit. Wonder how they're managing it.
As far as Java dying, I don't know, and I don't care. It was stillborn with momentum.
All an IDE is, effectively, is a UI
Wow, you really don't get much out of your IDEs, do you?
What makes JBuilder so terrible is its non-native GUI. The thing just looks bad with its GUI that's almost Win32, but not quite. Ctrl+Tab doesn't switch between code panes as you would expect in any Windows app; instead it uselessly switches between panes such as Project and Structure.
This is Windows recommended UI behavior for MDI apps. Read the interface standard.
But by far the absolute worse was its ignorance of Windows' ClearType setting for font smoothing.
That's funny: it works here.
Lots of people switch their editor fonts; many people use the font FixedSys, because it has good pixel choices. The reason it has good pixel choices is that it's a bitmap font, and is therefore unhintable in cleartype. This is the basis of most people thinking mIRC has broken cleartype support, too: it ships with FixedSys as the default window font.
Do note that there is no API call in any version of Windows from Win16 on which would not be hinted by ClearType; if Borland broke ClearType, then they remade every single bit of font drawing code from the ground up. The chances they did that are miniscule. Perhaps you just need to spend more time looking for the problem, before announcing to SlashDot how broken something is?
There are other GUI differences but I'm a horribly nit-picky person when it comes to UI
And, unfortunately, your nits picked are in contrast with the Win32 interface standard, as your demands for an MDI app to follow SDI behavior above show.
You need to learn that there's a difference between being a stickler for detail and whining that things don't work the way that you expect for them to. One is born of familiarity with existing standards; the other is clueless self-aggrandizing pablum. It's not Borland's fault that you don't know more than the very basics of Win32 UI behaviors; every single one of their pane and task switching hotkeys, including f10 and f11, are standards that have been with us longer than a default Windows TCP/IP stack. Hell, Win/QVT supported these. Maybe you should watch that movie that comes with a fresh XP install.
But it's not bad if you get used to it, so it's probably just that I'm unfamiliar with Eclipse.
Or Win32 UI standards. Or JBuilder. You actually suggest that Eclipse is more configurable than JBuilder. Have you even looked?
You mean Kylix, their free, open-source linux-targetting Delphi from 2001?
That started at least two years ago.
Let's see. If you were given the assignment to "parse a web page for data", what would you do? Hell, let's make that "parse anything for data". The first thing you'd do is that you'd find out some tell-tale signs of where information starts and ends. This could be different on different sets of data, or it could be consistent; on a web page, it'll almost certainly be inconsistent between these pages.
Um, sorry, those are what XHTML, OWL and RDF are for. RSS does not arise to combat this.
So what RSS (and Atom, another similar but more extensive format with the same goal that falls under the same buzzword) is is simply an easy format to deliver serial data in.
RSS is just a content aggregation feed. It's just an automatically provided synopsis, arguably something news sites have been doing since day one with the front page headlines and first paragraphs, and something newspapers have been doing for two hundred years with the first column and "continued on page A7." You make it out to be this thing about the extremely general topic of serial delivery, but it isn't; it's just a new content notifier, no different than Usenet, FidoNET, email, archie, wais, prospero or bluewave.
RSS is in fact extremely badly suited to serial delivery; there is no description of any sequence other than time, so you can't tell which things are followed by which other things - the very basis of seriality - when there's more than one thing being pushed out of the feed. Moreover, there's a huge amount of descriptive material such as title and superficial textual content which have nothing to do with seriality. It's just a content aggregator, nothing more.
All RSS is is a standard such mechanism so that uniform readers for content aggregation may arise. It's, as other slashdotters keep pointing out, just a badly reinvented fido/usenet.
Do remember that FidoNET, from July of 84, is a year and change older than Usenet, which properly starts during UUN's Great Renaming in 1986, and that some geezers still think it's better designed.
(Before anyone flips out that UUN was from 1979, please remember that the debate is over network architecture, and that UUN used UUX/UUCP; NNTP, which is the architecture to which parent refers, is first proposed in February of 1986, and doesn't see wide-spread use until late 87/early 88.)
A much better idea would be to deprecate email as it is currently used, and actually capture intra-office communication in some issue-tracking system, wiki, or other appropriate system.
...
It'd be much cooler if you were named Clarke, so I could say "welcome to 2001" all sarcastic-like; now all I have to work with is Gateway, and nobody would get it anyway. But, sure, capturing e-mail is nothing new, and good lord, we've been tracking our communications as threads on a private NNTP server for almost 20 years now. Also, there's been automatic majordomo browsing since Gopher, and back in the days of BlueWave
I tend to agree with Flexible. Yes, RSS can be productively used as a way to keep people abreast of changes, but that doesn't mean it's a good idea. We have both a bugzilla deployment with email notification and a mediawiki deployment with RSS notification; because they're both gathered by Thunderbird, you'd think they'd be transparent to me, and that RSS would be at least as good as email. This turns out not to be the case: it's very frequent for us to need to discuss issues that come out of project controol and/or bug control, so even what's going around in RSS eventually gets pushed around email anyway, and then it's a giant pain in the ass to find anything. (Google mail would partially ameliorate that due to its search mechanism, but there's no reason for the problem to exist in the first place.)
It's my opinion that you're addressing the wrong question. What's important isn't whether RSS is good enough to use; there are tons of things that are good enough to use. The question should be whether RSS offers any compelling benefits over the existing mechanisms, and to that I suggest that the answer is a resounding "no."
Where I work we started doing this with JIRA and Confluence, both of which offer RSS feeds so that you can stay up-to-date on the changes within those systems. The combination is powerful, and I recommend it without hesitation.
What about it is better than the existing email notification mechanisms, and what justifies moving to something other than the existing well understood mechanisms, causing problems in sorting, especially when RSS is a pull-only mechanism?
Be sure to look into Jot, which has a lot of code dedicated to supporting this sort of stuff, including the relatively odd notion of sending email to a page. Email is just as flexible as RSS; it's just not new, shiny, and buzzwordic. What benefit do you suggest RSS provides?
If you were to read the Mozilla project's documentation on the issue before announcing your judgements, you'd learn that the naming prefix is actually a measure of caution. It has been common practice in the Mozilla projects since around 0.6 days to expose partially implemented standards under incorrect names, so that designers can test drive the implementations and look for problems. The same has been done with dozens of other CSS properties, and the same is currently true of quite a few CSS3 properties.
The general pattern is that when the Mozilla foundation is convinced that the implementation is both complete and correct, it will be altered to respond to its correct name.
This is hardly embrace and extend. More accurately this is "keep the not-finished stuff out of the hands of people which blindly use anything they can find, instead of reading the documentation, deciding something half-done is broken, and go off trumpeting how broken Mozilla is." Which is, I suspect, exactly what you'd be doing right now, since you're so willing to judge things you haven't even bothered to look up.
They are going to support CSS3; I don't know where this "if they were going to" crap comes from, since a significant chunk of CSS3 already is supported. Here's a hint: Mozilla does many many things that CSS3 does not. That's not embrace and extend at all; that phrase refers to ruining existing standards by bloating them out, pretending that things which aren't part of them are, and confusing the end-user as to the nature of the standard. Netscape used to participate in things like this, but hasn't in a long, long time.
Mod parent down until he learns to RTFM.
Since when is this a riddle? I've been buying jarred popping corn that said this on the label as a point of advertisement for almost 15 years.
It's bad when the scientists are catching up to the marketers.
4, 2, 4, 1, 2, 1, 2, 2, 1. I don't see a dilution. Note that the two 4-year periods were difficult for N, as the NES penetrated the then-dead video game market, then later when Sega stole N's thunder by going 16-bit with nearly a year's lead.
A year and a half is the normal lifecycle for a console. Sony is the aberration, not Nintendo as of late.
and with a related consumer product (the Gameboy) whose design has managed to totally dominate its market continuously against technically superior competition.
Superior is a matter of perspective. Many people find that the single critical characteristic of a portable is battery life, and in that characteristic Nintendo has never been challenged.
Consider that that's almost the only characteristic on which they've maintained a lead, and that they've been wholly dominant the entire time. Coincidence or correlation? You can probably guess what I believe.
Even though it's console was a distant 3rd in the last race
Second, actually. Nintendo took the lead around when the gamecube went to a hundred dollars.