I will make one concession to this, in that it can depend on the editor you are using...
If your editor does brace matching, then it *may* not matter about how you indent/format blocks...
If you ever have to look at code as just a plain text document, then K&R blocks can be a *severe* problem...
K&R style blocks make it much harder to see where braces match... this is especially true if you ever use default program blocks (ie. an if statement with a single statement in the 'then' clause, without the use of any braces)
Yes, you can mitigate the problems greatly by always explicitly defining your blocks (ie. always using braces, even where they are not strictly required by the language), and being absolutely strict about how you indent code (esp. with regards to spaces vs. tabs)... however the second point can be quite hard to enforce, when you may need to use a variety of editors in different circumstances, and you have a reasonable size team working on the project...
As one of the most important aspects to understanding how code works is to be able to see where the program blocks are, and exactly what they are doing - not to mention the number of bugs caused by errors in the definition of program blocks - K&R style formatting can be the cause of many headaches, and result in a lot of wasted time / effort.
I'm not ignoring them as such - I'm just not making explicit reference to them...
These are all function level comments - virtually all of which have some place in javadoc-style comments...
Some things you have mentioned are not as useful as they might be... for example, comments about when a function is useful - whilst it can be helpful to explain such things in some cases, chances are you will only ever describe a subset of a function's actual usefulness... if that is the case, then you are as likely to find people not using your function when maybe they could / should, just because you never mentioned that it might be useful!!
Probably a highly controversial opinion;-), and definitely over simplified (you shouldn't have to read the entire source code of Windows to know what one of the API calls does / is meant to do (although if some recent posts are anything to go by, it would probably be wise...)
But for me, over documentation is *far* worse than under documentation... code is a natural form of doucmentation - why? because it is a set of instructions that are followed blindly to the letter... it describes *exactly* what the computer is doing (although when calling some third party library / API, you are trusting the function to do *exactly* what the author claims it is supposed to)...
What can be better than that? Certainly not half a page of drivel, of what someone vaguely thinks the code is doing...
Of course, there are caveats - for starters, sensible, descriptive (although hopefully not to finger-blisteringly long) names for functions and variables are necessary, as is a clear, consistent layout of the code (and that means none of the old K&R style opening a program block on the line of an if / while / etc statement - block starts / ends should *always* be on clear lines at the same indentation level!!)
Javadoc-style comments are handy and useful though - handy because they put space in between functions for easier navigation of a file, and for automatic generation of your API documentation... useful, as it ties the 'specification' (ie. what the code was meant to do) with the code itself - so when it doesn't do what it is supposed to, you don't have to go hunting for the specs...
Other than that, if you need much more in the way of comments, then you can be pretty sure that the structure of the code is wrong... (unless of course speed is critical, and that is the best optimised code)
That it is not worth is not something that I am 'deciding' - rather I am pointing out the practicalities of the situation... (ie. don't *expect* it to happen, as it isn't likely to be worth it for the vendors).
Yes, it does make sense to be able to take advantage of available bandwidth - but how much is really available?
You see, the benchmark that they use specifically focuses on DirectX applications (ie. 3D rendering, although possibly 2D stuff as well)... for the typical uses of DirectX, you can understand why transfer of images back across the bus is not given priority... even if the AGP bandwidth is not being fully utilised in rendering (which it might well be for complex scenes), you can understand why they might only allow reading data off the card a limited amount of bandwidth... and bear in mind, that DirectX applications are typically double (or even triple) buffered - so you can be rendering the next scene whilst downloading the old one... (which is likely to slow things down anyway, due to contention!!!).
Now, despite it's direct mention in the article - how does this relate to business uses? How many business use DirectX built interfaces, let alone have a requirement to capture them in real time?
I'll accept that the multi-pass thing you mention is interesting... however, to do it in 'real time', you would have to render at a multiple of your target frame rate - not only would that require an incredibly powerful chip (for anything that looks 'broadcast quality'), there would be a multiple of the amount of data being sent back across the AGP bus - which makes it even more impractical...
If you aren't doing it in realtime (which is entirely feasible - you would be doing this to get good price / performance... even at say a quarter of real time, it could still cost you a hell of a lot more to get better performance), then it is less relevant how quickly you transfer back across the AGP bus (again, as long as price/performance goals are reached)
I am not saying that 200MB - or a quarter of your bandwidth - is good or bad use... I'm just pointing out the practicalities... for a complex scene - which is likely for broadcast scenarios - you are likely to be sending a *lot* of data over the AGP bus... so much so that you simply wouldn't have the bandwidth left for realtime transfers of images back across the AGP bus... if you aren't doing this in real time, then there is less of an issue about how good a use it makes of bandwidth!!!
In response to your comment about the device attached to a DVI connector - quite simply, it wouldn't be rendering, and could be an entirely seperate machine - which means in theory it could have as much bandwidth that it wants (at least that of an AGP connection!!!)... My point is that it can support taking images from the rendering card, in 'perfect' quality, in real time, without eating up valuable AGP bandwidth that may well be required just to perform the rendering in the first place... if real time is not an issue, then almost certainly the speed of transferring back from the card isn't!!!!!
I am *not* switching my argument in regards to capturing general business scenarios - we were originally talking about 3D rendering for production purposes - and presumably in realtime - capturing of the display within a 'general' business scenario is an entirely different application, and therefore needs to be evaluated separately. Does Word (or any other office product) require 100's of MBs of AGP bandwidth - of course not, which means that it could in theory be made available for real time screen capture... this is not the case for real time 3D rendering...
You seem to be ignorant of the cost of software development... just assuming that it is a driver change, it is not negligible cost... implementation, ensuring that it works in the 'right' cases (ie. ensuring that AGP bandwidth is available for 3D rendering, etc. when such an application is being used), testing - including rigorous memory checking, etc. as it is a system component that could cause many problems to system stability usability... and then on top of that, regression testing to ensure that it still works properly in every future driver release... still think that that is negligible cost for the vendors? Think it is negligible in comparison to the extra revenue that such a feature would generate?
And finally, what about intranet? Sure, companies do have enough intranet bandwidth - although I'm slightly less convinced about the number that would be prepared to devote such bandwidth to that use... but then the article didn't mention intranets, did it?
...that I have ever read. Either that, or I am missing something here...
The idea that graphics subsytems have 'bandwidth to burn' is kind of ironic, given that every graphics chip is ultimately held back in performance by the amount of bandwidth available to it - especially when using high quality options like anti-aliasing.
The main focus of the article is actually a very niche segment... the idea of transeferring back rendered images over the AGP bus for TV / film / etc. is a joke...
Rendering at high quality takes a huge amount of bandwidth (ie. textures and geometry)... as someone else pointed out, transferring back high-res images would take up over 200MB - that's a quarter of your AGP bandwidth! And without taking into account contention and timing issues in uploading/downloading that would mean that you simple couldn't realise the full potential of the bandwidth without a lot of other (expensive?) hardware...
The simple fact is that for production uses, you would be *far* better off taking a stream of data from the DVI connector, and storing that for later use...
Screen capture for business use is a reasonable point - however when does that require 3d rendering to be taking place? There should be no contention and no reason why the AGP bus couldn't be utilised fully - although would the graphics companies make enough out of this to justify the effort?
As for internet streaming - how many people have access to bandwidth fast enough for high quality, full screen video streaming? Enough said...
Would I use an open source implementation of.Net? Well, if I want to host on Linux, then it is my only choice, so yes...
But why would I want to use an open source version (particularly in it's current state of development) on Windows? I can download all the SDK etc from Microsoft for free - it's only the IDE that I would have to pay for, and there are free alternatives to that... For as long as I use Windows, and I can download a free cli-based SDK from MS, an open source version would have to offer compelling reasons (in terms of less bugs, fixing bug/security issues, performance) otherwise there is no point.
Given the example, the only reasons I would not go on to download the software (when everything has been made clear up front), is if I hear of any problems with the software, or find something else that does the job, or my need no longer exists...
Of course, if things haven't been made clear up front, then that might be a factor...
Although, if you really want to know the biggest reason why I wouldn't take an evaluation of a piece of software, then it would be when they want a credit card number up front, and you have to actively go and cancel payment before they take it (ala GoToMyPC)
As far as I am concerned, a company has *no* business knowing my payment details until I am ready to pay for it... why should a 'free' trial be at my own risk?
Anybody sensible knows that the browser could be removed from the OS if MS chose / was forced. It is modular (COM objects), as is most of the OS...
But, is it really important that it gets removed? It's hard luck for Netscape that Microsoft chose to develop IE, and it's hard luck for them that they chose to integrate it into the OS - but was there any other business choice? There are many cool things that you can do with the OS and associated apps if you have a HTML rendering component available at an OS level... that's what MS did - having a wrapper around it to provide navigation and bookmarking facilities (in other words Internet Explorer), is a very minor thing... There was no value in MS producing *just* a stand alone browser (and charging for it), and having components in the OS that you don't put the wrapper round is pointless...
Take it from the other angle, and whilst it isn't good for Netscape, there are many opportunities created for developers by having a reusable HTML component installed as part of the OS... whilst you can debate the monopolistic practises of making the browser part of the OS, what happens to all those people that rely on the fact that the components are shipped with the OS?
It would be nice to see the underlying components easily replacable (in theory, as COM objects they already are if someone ever wanted to...)... but ultimately, including the functionality with the OS is not wholly uncompetitive - how many disk defragmenters are out there that you can purchase, when one is included free with the OS?
Slashdot Mirror
I will make one concession to this, in that it can depend on the editor you are using...
If your editor does brace matching, then it *may* not matter about how you indent/format blocks...
If you ever have to look at code as just a plain text document, then K&R blocks can be a *severe* problem...
K&R style blocks make it much harder to see where braces match... this is especially true if you ever use default program blocks (ie. an if statement with a single statement in the 'then' clause, without the use of any braces)
Yes, you can mitigate the problems greatly by always explicitly defining your blocks (ie. always using braces, even where they are not strictly required by the language), and being absolutely strict about how you indent code (esp. with regards to spaces vs. tabs)... however the second point can be quite hard to enforce, when you may need to use a variety of editors in different circumstances, and you have a reasonable size team working on the project...
As one of the most important aspects to understanding how code works is to be able to see where the program blocks are, and exactly what they are doing - not to mention the number of bugs caused by errors in the definition of program blocks - K&R style formatting can be the cause of many headaches, and result in a lot of wasted time / effort.
I'm not ignoring them as such - I'm just not making explicit reference to them...
These are all function level comments - virtually all of which have some place in javadoc-style comments...
Some things you have mentioned are not as useful as they might be... for example, comments about when a function is useful - whilst it can be helpful to explain such things in some cases, chances are you will only ever describe a subset of a function's actual usefulness... if that is the case, then you are as likely to find people not using your function when maybe they could / should, just because you never mentioned that it might be useful!!
... is the code itself.
;-), and definitely over simplified (you shouldn't have to read the entire source code of Windows to know what one of the API calls does / is meant to do (although if some recent posts are anything to go by, it would probably be wise...)
Probably a highly controversial opinion
But for me, over documentation is *far* worse than under documentation... code is a natural form of doucmentation - why? because it is a set of instructions that are followed blindly to the letter... it describes *exactly* what the computer is doing (although when calling some third party library / API, you are trusting the function to do *exactly* what the author claims it is supposed to)...
What can be better than that? Certainly not half a page of drivel, of what someone vaguely thinks the code is doing...
Of course, there are caveats - for starters, sensible, descriptive (although hopefully not to finger-blisteringly long) names for functions and variables are necessary, as is a clear, consistent layout of the code (and that means none of the old K&R style opening a program block on the line of an if / while / etc statement - block starts / ends should *always* be on clear lines at the same indentation level!!)
Javadoc-style comments are handy and useful though - handy because they put space in between functions for easier navigation of a file, and for automatic generation of your API documentation... useful, as it ties the 'specification' (ie. what the code was meant to do) with the code itself - so when it doesn't do what it is supposed to, you don't have to go hunting for the specs...
Other than that, if you need much more in the way of comments, then you can be pretty sure that the structure of the code is wrong... (unless of course speed is critical, and that is the best optimised code)
That it is not worth is not something that I am 'deciding' - rather I am pointing out the practicalities of the situation... (ie. don't *expect* it to happen, as it isn't likely to be worth it for the vendors). Yes, it does make sense to be able to take advantage of available bandwidth - but how much is really available? You see, the benchmark that they use specifically focuses on DirectX applications (ie. 3D rendering, although possibly 2D stuff as well)... for the typical uses of DirectX, you can understand why transfer of images back across the bus is not given priority... even if the AGP bandwidth is not being fully utilised in rendering (which it might well be for complex scenes), you can understand why they might only allow reading data off the card a limited amount of bandwidth... and bear in mind, that DirectX applications are typically double (or even triple) buffered - so you can be rendering the next scene whilst downloading the old one... (which is likely to slow things down anyway, due to contention!!!). Now, despite it's direct mention in the article - how does this relate to business uses? How many business use DirectX built interfaces, let alone have a requirement to capture them in real time?
I'll accept that the multi-pass thing you mention is interesting... however, to do it in 'real time', you would have to render at a multiple of your target frame rate - not only would that require an incredibly powerful chip (for anything that looks 'broadcast quality'), there would be a multiple of the amount of data being sent back across the AGP bus - which makes it even more impractical...
If you aren't doing it in realtime (which is entirely feasible - you would be doing this to get good price / performance... even at say a quarter of real time, it could still cost you a hell of a lot more to get better performance), then it is less relevant how quickly you transfer back across the AGP bus (again, as long as price/performance goals are reached)
I am not saying that 200MB - or a quarter of your bandwidth - is good or bad use... I'm just pointing out the practicalities... for a complex scene - which is likely for broadcast scenarios - you are likely to be sending a *lot* of data over the AGP bus... so much so that you simply wouldn't have the bandwidth left for realtime transfers of images back across the AGP bus... if you aren't doing this in real time, then there is less of an issue about how good a use it makes of bandwidth!!!
In response to your comment about the device attached to a DVI connector - quite simply, it wouldn't be rendering, and could be an entirely seperate machine - which means in theory it could have as much bandwidth that it wants (at least that of an AGP connection!!!)... My point is that it can support taking images from the rendering card, in 'perfect' quality, in real time, without eating up valuable AGP bandwidth that may well be required just to perform the rendering in the first place... if real time is not an issue, then almost certainly the speed of transferring back from the card isn't!!!!!
I am *not* switching my argument in regards to capturing general business scenarios - we were originally talking about 3D rendering for production purposes - and presumably in realtime - capturing of the display within a 'general' business scenario is an entirely different application, and therefore needs to be evaluated separately. Does Word (or any other office product) require 100's of MBs of AGP bandwidth - of course not, which means that it could in theory be made available for real time screen capture... this is not the case for real time 3D rendering...
You seem to be ignorant of the cost of software development... just assuming that it is a driver change, it is not negligible cost... implementation, ensuring that it works in the 'right' cases (ie. ensuring that AGP bandwidth is available for 3D rendering, etc. when such an application is being used), testing - including rigorous memory checking, etc. as it is a system component that could cause many problems to system stability usability... and then on top of that, regression testing to ensure that it still works properly in every future driver release... still think that that is negligible cost for the vendors? Think it is negligible in comparison to the extra revenue that such a feature would generate?
And finally, what about intranet? Sure, companies do have enough intranet bandwidth - although I'm slightly less convinced about the number that would be prepared to devote such bandwidth to that use... but then the article didn't mention intranets, did it?
...that I have ever read. Either that, or I am missing something here... The idea that graphics subsytems have 'bandwidth to burn' is kind of ironic, given that every graphics chip is ultimately held back in performance by the amount of bandwidth available to it - especially when using high quality options like anti-aliasing. The main focus of the article is actually a very niche segment... the idea of transeferring back rendered images over the AGP bus for TV / film / etc. is a joke... Rendering at high quality takes a huge amount of bandwidth (ie. textures and geometry)... as someone else pointed out, transferring back high-res images would take up over 200MB - that's a quarter of your AGP bandwidth! And without taking into account contention and timing issues in uploading/downloading that would mean that you simple couldn't realise the full potential of the bandwidth without a lot of other (expensive?) hardware... The simple fact is that for production uses, you would be *far* better off taking a stream of data from the DVI connector, and storing that for later use... Screen capture for business use is a reasonable point - however when does that require 3d rendering to be taking place? There should be no contention and no reason why the AGP bus couldn't be utilised fully - although would the graphics companies make enough out of this to justify the effort? As for internet streaming - how many people have access to bandwidth fast enough for high quality, full screen video streaming? Enough said...
Would I use an open source implementation of .Net? Well, if I want to host on Linux, then it is my only choice, so yes...
But why would I want to use an open source version (particularly in it's current state of development) on Windows? I can download all the SDK etc from Microsoft for free - it's only the IDE that I would have to pay for, and there are free alternatives to that... For as long as I use Windows, and I can download a free cli-based SDK from MS, an open source version would have to offer compelling reasons (in terms of less bugs, fixing bug/security issues, performance) otherwise there is no point.
Given the example, the only reasons I would not go on to download the software (when everything has been made clear up front), is if I hear of any problems with the software, or find something else that does the job, or my need no longer exists... Of course, if things haven't been made clear up front, then that might be a factor... Although, if you really want to know the biggest reason why I wouldn't take an evaluation of a piece of software, then it would be when they want a credit card number up front, and you have to actively go and cancel payment before they take it (ala GoToMyPC) As far as I am concerned, a company has *no* business knowing my payment details until I am ready to pay for it... why should a 'free' trial be at my own risk?
Anybody sensible knows that the browser could be removed from the OS if MS chose / was forced. It is modular (COM objects), as is most of the OS... But, is it really important that it gets removed? It's hard luck for Netscape that Microsoft chose to develop IE, and it's hard luck for them that they chose to integrate it into the OS - but was there any other business choice? There are many cool things that you can do with the OS and associated apps if you have a HTML rendering component available at an OS level... that's what MS did - having a wrapper around it to provide navigation and bookmarking facilities (in other words Internet Explorer), is a very minor thing... There was no value in MS producing *just* a stand alone browser (and charging for it), and having components in the OS that you don't put the wrapper round is pointless... Take it from the other angle, and whilst it isn't good for Netscape, there are many opportunities created for developers by having a reusable HTML component installed as part of the OS... whilst you can debate the monopolistic practises of making the browser part of the OS, what happens to all those people that rely on the fact that the components are shipped with the OS? It would be nice to see the underlying components easily replacable (in theory, as COM objects they already are if someone ever wanted to...)... but ultimately, including the functionality with the OS is not wholly uncompetitive - how many disk defragmenters are out there that you can purchase, when one is included free with the OS?