See, I've lived in a country where marketing of drugs is heavily restricted (Norway) and funnily enough I never felt oppressed. In fact I felt happy and content in the knowledge that I'd never go without essential medical treatment or drugs I might need because I lived in a country with a real health system.
I now live in the UK, which is slightly more liberal about it, but still have very real restrictions (I see plenty of ads for non-prescription drugs, but thats mostly it), and it doesn't really offer me any benefits. Mostly, the drug ads are bandying about useless slogans that tells me NOTHING about the efficacy of their drugs, and I end up relying on information from professionals anyway (chemists)
It has nothing to do with controlling the population - proper INFORMATION is readily and legally available. But the drug companies are limited in how much propaganda and misinformation they can spread to trick people into thinking they need something they don't.
The most ridiculous example from the UK is how the drug companies keep on trying to convince people that THEIR paracetamol (or insert any other generic painkiller here) product, which contains exactly the same quantities of paracetamol per dose and exactly the same doses of other chemicals, somehow is magically superior to the competition and will help you so much faster.
Does it help me? No it doesn't.
Would similar style advertising about prescription drugs help me? No it wouldn't, because my doctor shouldn't be prescribing something based on silly claims on TV, but based on which drugs I actually need.
The only thing it would be achieving would be making parts of the public pressure their doctor into choosing something that might not be ideal for them, based either on price (mostly irrelevant to the public here in the UK - we pay a fixed, low rate for most prescription drugs) or product claims that are devoid of proper information.
Why don't you take the advice of taking a look at the financial data for these companies? For Pfizer, for example, R&D seems to be about 20% of their total expenditure. Marketing isn't directly broken out, but if you just lump EVERYTHING that could be related (cost of sales, informational and administrative activities etc.) together, R&D is at least a third of the marketing cost. A far cry from ten times more on marketing.
Now, incidentally I agree with the use of eminent domain to force these companies to limit the use of patents to jack up prices. But I also agree that it may hurt innovation. The two don't need to be in conflict: As long as the government truly offers a fair price (that is, one that clearly gives the drug company sufficient profits to justify the R&D) then that's fine. The alternative is for the government to more heavily fund R&D - that would give the same benefits.
It all boils down to the fact that the public WILL bear the cost of R&D for new drugs one way or another, but the public should not be put in a situation where their life depends on whether or not they can afford a particular drug.
In Europe, that is usually taken care of by regulating the prices OR having the government pick up the tab. The drug companies still get their money, but individuals that might otherwise have been unable to bear the cost of potentially life saving drugs are guaranteed to be able to get them, while the rest of us pay slightly more for drugs through the tax bill (and before anyone starts to moan about taxes, I live in the UK, earn well above average, and still I don't pay any more tax that I would had I lived in many US states - I've done the calculations - and I don't have to bother with things like health insurance). I think that's fair, and a far better use of my tax money than ridiculous military expenditure for example.
The type of iterator should only have a bearing on the result in really bizarre cases, as it is trivial for the compiler to detect that the return value should not be used, and the C++ standard is quite specific about how prefix ++ should behave for the standard iterator categories.
The prefix version is expected to behave like this: "T tmp = *r; ++r; return tmp;" where T is the value type and r is the iterator. If you look at that it should be obvious why the optimization normally succeeds. Under 12.8.15 of the C++ standard, the implementation is allowed to optimize away the copy construction and construct the object directly into the object it's returned to. If the returned object is never used, no call to the copy constructor needs to be generated at all, even if the copy constructor has side effects. GCC at least does take advantage of that, and will optimize away calls to the copy constructor if the value isn't used.
You could certainly mess up this optimization by writing an iterator class that explicitly acts differently for prefix and postfix ++ apart from constructing and returning the value type, but then it would also be wrong to blindly switch between the two to optimize the program, and your iterator would be behaving in ways likely to be highly unexpected by users.
So while there are certainly cases where postfix ++ may end up more expensive than prefix ++, it's quite likely to reflect a bad design, and personally I'd consider it a bug if I ever come across an iterator class that badly behaved.
What does.NET have to do with this? This is exactly the same for practically any compilers, and most modern compilers can generate textual assembly output so you can trivially look at the differences.
Yeah, and then there's the issue that most assembly programmers are crap at what they do, and end up doing a worse job than the compiler because they make assumptions about pipelining etc. that are simply wrong. I know there are assembly programmers out there that DO know how to do things right, but most programmers have no business even thinking about trying to "optimize" the compiler output.
I remember (though not with much fondness) the days of optimizing the M68000 assembly output from one of the Amiga C compilers 12 years or so ago, when I could trivially halve the size of a program just by reading through it and rewriting the code almost as fast as I could type (seriously, I wonder what the f*** they thought they were doing producing compilers that shitty). But modern compilers are getting good enough that it's seldom worthwhile to spend time trying to beat them unless you have spent a LOT of effort improving algorithm choices and profiling first.
Did you bother to TEST your assumptions above? I did. GCC generates EXACTLY the same output for postfix and prefix ++ with "-O2".
And gcc is far from state of the art when it comes to optimizing C++ code...
I agree that it makes sense to use "++itr", but not because I think it'll make any performance difference.
Your general principle is sound - the compiler WILL have problems optimizing code if it depends on something that isn't available to it at compile time, for obvious reasons. However when you're using templates or the code is otherwise visible modern C++ compilers do a quite good job at optimizations.
He IS using objects. Just because you don't know how to read C++ doesn't mean it isn't just as readable to C++ programmers as your example is to Java programmers.
Besides your example is far less flexible - it requires the iterator to know when the end of the sequence is reached. The C++ approach is to use two iterators to define a range.
Note also that due to the genericity used in STL, the iterators can perfectly well be anything from plain pointers to a complex object doing losts of calculation - you can trivially use templates to algorithms working on any iterators regardless of what they represent as long as the types you iterate over support the operations you carry out on them.
When I first moved to the UK from Norway five years ago, the first thing that annoyed the hell out of me was having to sign when I used my cards instead of just entering a PIN. Now signatures are rapidly being phased out here as well. I'd happily get rid of having to insert my card in the reader, as long as the PIN is still required.
You're talking out of your ass. With URI's you still need a method of finding the LOCATION of the objects you're looking for. That still means synchronizing multiple servers and finding a way of directing requests to the servers that happens to have the object.
DNS is one way of achieving that. You can achieve the same with any directory/naming service provided you have clients that know how to use one of them.
But ultimately you still need a naming service.
Whether you make that service take into account just a part of the name (as with DNS with URL's coupled with an HTTP server) or the whole name, the end result is the same. Nothing is stopping you from doing this today by registering a domain and giving each page on your system a unique hostname and repoint your DNS to point to any object.
Nothing is also stopping you from using URI's to uniquely identify objects you happen to have lieing around, but that doesn't help you if you can't find them.
The thing is that when people mention terraforming a lot of people automatically assume the only goal that would be sufficient to be useful is to make it possible for humans to live entirely without any form of support.
But even a minor increase in atmospheric pressure would have a massive impact on the feasability and safety of large domes, for instance, because it would even out the pressure difference between the outside and inside of a habitable dome.
Just getting to a temperature and atmosphere where humans won't die instantly without a suit, or can work/survive outside in warm clothes and an oxygen mask will have a dramatic impact on how easy it will be to have a sustained presence, and the safety of a colony that would otherwise have to have massive safeguards against damages to habitats.
Keep in mind that there are many areas on earth that are extremely inhospitable. While it would be great if Mars could once be as hospitable as the more pleasant areas of the earth, that doesn't mean that less won't still make it possible (or even interesting) to live there.
Yes you could, and you can bet that you'd end up getting your life so seriously screwed up by the judgements and damages claims and lawyers bills that you'd never try something so stupid again.
Now, try it against someone without deep pockets and you might just possibly have a chance to intimidate them into submission.
A prerequisite for getting a trademark registration is that you claim that you have created a mark and are actively using it it, and that the name is recognized in the market as referring to your product.
So if he isn't currently using the mark, he has no rights to it. If he is currently using the mark, it's still obvious that the name have been in use for far too long for the free product for him to have any rights to it unless it's in a significantly different market (and no, releasing a commercial version would certainly not be sufficient)
MAME's authors should assume hostility right from the outset because there is simply no legitimate reasons for this person to register the mark without having talked to them and arranged an agreement with them first.
It might be that he's "innocent", but if so he's also clueless enough about trademarks to be just as dangerous as if he's doing it on purpose and should be treated as such.
Duh. This must be the most obvious idea around. The reason it's not taken very seriously is that electrolysis requires vast amounts of electricity. You might as well have suggested that people get a kit to set up in their garage. Sure, it would work, but it wouldn't be cost effective, and neither is your suggestion likely to be.
The BBC article is perhaps the worst piece of journalism I've ever seen come out of the BBC.
The directive was NOT rejected by the EU Parliament, but by the Conference of Presidents - essentially the group leaders of all the various parliamentary parties. It's still a good step, but it's misleading to claim this was an action by the Parliament as a whole.
This does NOT mean that the bill "is thrown out". It means that the EU Parliament is supporting it's own legal affairs committee's call for the EU Commission to restart the process and have directed the President of the EU Parliament to officially request a restart.
The bill must not "go back to the EU" for reconsideration - the EU Commission must decide whether it wants to accept the restart vote by parliament, ignore it, or overrule it. The latter two would mean the Council would go ahead as before.
And if you'd bother to RTFA you'd see that the current approach focuses on using the Sindbis virus for delivery. Sindbis itself is not a full cure - it attacks cancer cells but is by no means guaranteed to be sufficient to destroy a tumour. That is why researchers are now looking at using it for delivering other "payloads" that are more lethal to the cancer cells. Many of these would toxic to normal substancs in the body, but using Sindbis allows focused delivery, potentially massively reducing the damage to the body.
Take a look at search.yahoo.com and try to tell me it's not a search engine... Yahoo! have had web search for years, and since last year it has been hosted by a Yahoo! developed search engine.
But personally I prefer to use the Yahoo! MySearch beta. I just hope they end up integrating it with the online bookmarks.
Never lose a message if you've sent the confirmation that it has been received.
That is only a small part of providing proper delivery guarantees.
I doubt very much your mail server has built in support for letting client applications handle transactions for instance (that is, only deliver a specific message if all messages in the transaction can be delivered).
It is very simple to add a layer on top of e-mail that ensures no message is delivered twice; you keep a database in your delivery spool of message-ids and don't deliver anything you already have. This isn't something the server I worked on does (it wasn't a design requirement) but it could easily be added. It would also be trivially easy for client software to filter out redundant messages. This seems like a non-problem to me.
Yes, it is simple. But you need to do it. When you add together all the things you need to do to emulate the full capabilities of a well written message queueing solution, it starts to quickly add up in terms of engineering and design time. It also means you'll end up with a system that there is no standard training available for, nor no third party tools, no ready made transaction monitors or routing software etc.
You seem to be particularly fond of mail servers, but I could layer the exact same functionality on top of an FTP server, via SCP, UUCP or over raw TCP connections. Perhaps I should claims they are all perfect substitutes for MQSeries and other message queueing solutions?
The only thing separating those (and many more - a web server with a CGI for instance) is the amount of additional code you'd have to write on top of it to get the message queueing functionality a proper message queueing system provides.
If you need the capabilities of provided by a message queueing system it doesn't take many hours of team members time spent before your simple solution has ended up costing your company more than buying a ready made well supported solution would cost you.
Use the right tool for the job.
Sometimes that is a mail server because you simply don't need all the features of a full message queueing solution - some engineers who worked for me at my last workplace put together a really good solution based on Qmail for instance. I loved the solution. It was simple, it did the job for a fraction of the price of MQSeries.
But it did the job because we couldn't care less about duplicate messages (all operations were idempotent) and because we judged the reliability of QMail to be good enough for THAT situation, and because cost was a major factor. So the layers my team wrote on top of it was tiny and simple.
But many people DO need the capabilities of a full message queueing solution, and in that case using a mail server as the foundation DOES mean a substantial amount of extra engineering that is unlikely to pay off in terms of money saved unless you're planning a really huge installation.
Except that most mail servers aren't designed to give the kind of delivery guarantees that message queueing software like MQSeries does. Most are also not designed for the kind of performance you can get out of many message queuing solutions that take advantage of the fact that the number of recipients tend to be low (compared to e-mail) and keeping persistent connections to some or all queue endpoints may be acceptable; and neither are they designed to provide support for transactions etc.
It's not that this can't be done over SMTP, but that SMTP isn't practical for it - you'd need lots of extra data in the headers, and applications supporting it.
Sure, you can write the support for all of it on top of SMTP, or FTP or SCP or HTTP or any protocol you can think of that can move data from one point to another, but the whole point of message queueing applications is that the heavy lifting has been done for you.
If you don't care about the transactions, or it doesn't matter if your messages can be delivered twice by mistake, or any of the other features of a proper message queuing system, then sure, go ahead and use a mail server - a previous place I worked we used Qmail with good results. It's a trade off, but the difference is huge.
The physics dictate that the design will be, and test show that the physics match reality. And yes, they have turned off the cooling to demonstrate this.
The graphite is covered in silicon carbide, so it won't burn. In fact the Chinese pebble bed design IS relying on a passive system for control - the reaction can't sustain itself without the coolant present, and will quickly slow down and stop.
Slashdot Mirror
I now live in the UK, which is slightly more liberal about it, but still have very real restrictions (I see plenty of ads for non-prescription drugs, but thats mostly it), and it doesn't really offer me any benefits. Mostly, the drug ads are bandying about useless slogans that tells me NOTHING about the efficacy of their drugs, and I end up relying on information from professionals anyway (chemists)
It has nothing to do with controlling the population - proper INFORMATION is readily and legally available. But the drug companies are limited in how much propaganda and misinformation they can spread to trick people into thinking they need something they don't.
The most ridiculous example from the UK is how the drug companies keep on trying to convince people that THEIR paracetamol (or insert any other generic painkiller here) product, which contains exactly the same quantities of paracetamol per dose and exactly the same doses of other chemicals, somehow is magically superior to the competition and will help you so much faster.
Does it help me? No it doesn't.
Would similar style advertising about prescription drugs help me? No it wouldn't, because my doctor shouldn't be prescribing something based on silly claims on TV, but based on which drugs I actually need.
The only thing it would be achieving would be making parts of the public pressure their doctor into choosing something that might not be ideal for them, based either on price (mostly irrelevant to the public here in the UK - we pay a fixed, low rate for most prescription drugs) or product claims that are devoid of proper information.
Now, incidentally I agree with the use of eminent domain to force these companies to limit the use of patents to jack up prices. But I also agree that it may hurt innovation. The two don't need to be in conflict: As long as the government truly offers a fair price (that is, one that clearly gives the drug company sufficient profits to justify the R&D) then that's fine. The alternative is for the government to more heavily fund R&D - that would give the same benefits.
It all boils down to the fact that the public WILL bear the cost of R&D for new drugs one way or another, but the public should not be put in a situation where their life depends on whether or not they can afford a particular drug.
In Europe, that is usually taken care of by regulating the prices OR having the government pick up the tab. The drug companies still get their money, but individuals that might otherwise have been unable to bear the cost of potentially life saving drugs are guaranteed to be able to get them, while the rest of us pay slightly more for drugs through the tax bill (and before anyone starts to moan about taxes, I live in the UK, earn well above average, and still I don't pay any more tax that I would had I lived in many US states - I've done the calculations - and I don't have to bother with things like health insurance). I think that's fair, and a far better use of my tax money than ridiculous military expenditure for example.
The prefix version is expected to behave like this: "T tmp = *r; ++r; return tmp;" where T is the value type and r is the iterator. If you look at that it should be obvious why the optimization normally succeeds. Under 12.8.15 of the C++ standard, the implementation is allowed to optimize away the copy construction and construct the object directly into the object it's returned to. If the returned object is never used, no call to the copy constructor needs to be generated at all, even if the copy constructor has side effects. GCC at least does take advantage of that, and will optimize away calls to the copy constructor if the value isn't used.
You could certainly mess up this optimization by writing an iterator class that explicitly acts differently for prefix and postfix ++ apart from constructing and returning the value type, but then it would also be wrong to blindly switch between the two to optimize the program, and your iterator would be behaving in ways likely to be highly unexpected by users.
So while there are certainly cases where postfix ++ may end up more expensive than prefix ++, it's quite likely to reflect a bad design, and personally I'd consider it a bug if I ever come across an iterator class that badly behaved.
What does .NET have to do with this? This is exactly the same for practically any compilers, and most modern compilers can generate textual assembly output so you can trivially look at the differences.
I remember (though not with much fondness) the days of optimizing the M68000 assembly output from one of the Amiga C compilers 12 years or so ago, when I could trivially halve the size of a program just by reading through it and rewriting the code almost as fast as I could type (seriously, I wonder what the f*** they thought they were doing producing compilers that shitty). But modern compilers are getting good enough that it's seldom worthwhile to spend time trying to beat them unless you have spent a LOT of effort improving algorithm choices and profiling first.
And gcc is far from state of the art when it comes to optimizing C++ code...
I agree that it makes sense to use "++itr", but not because I think it'll make any performance difference.
Your general principle is sound - the compiler WILL have problems optimizing code if it depends on something that isn't available to it at compile time, for obvious reasons. However when you're using templates or the code is otherwise visible modern C++ compilers do a quite good job at optimizations.
Besides your example is far less flexible - it requires the iterator to know when the end of the sequence is reached. The C++ approach is to use two iterators to define a range.
Note also that due to the genericity used in STL, the iterators can perfectly well be anything from plain pointers to a complex object doing losts of calculation - you can trivially use templates to algorithms working on any iterators regardless of what they represent as long as the types you iterate over support the operations you carry out on them.
When I first moved to the UK from Norway five years ago, the first thing that annoyed the hell out of me was having to sign when I used my cards instead of just entering a PIN. Now signatures are rapidly being phased out here as well. I'd happily get rid of having to insert my card in the reader, as long as the PIN is still required.
DNS is one way of achieving that. You can achieve the same with any directory/naming service provided you have clients that know how to use one of them.
But ultimately you still need a naming service.
Whether you make that service take into account just a part of the name (as with DNS with URL's coupled with an HTTP server) or the whole name, the end result is the same. Nothing is stopping you from doing this today by registering a domain and giving each page on your system a unique hostname and repoint your DNS to point to any object.
Nothing is also stopping you from using URI's to uniquely identify objects you happen to have lieing around, but that doesn't help you if you can't find them.
Yeah, because you should always give up whenever you meet some resistance, because you're destined to fail anyway.
</sarcasm>
But even a minor increase in atmospheric pressure would have a massive impact on the feasability and safety of large domes, for instance, because it would even out the pressure difference between the outside and inside of a habitable dome.
Just getting to a temperature and atmosphere where humans won't die instantly without a suit, or can work/survive outside in warm clothes and an oxygen mask will have a dramatic impact on how easy it will be to have a sustained presence, and the safety of a colony that would otherwise have to have massive safeguards against damages to habitats.
Keep in mind that there are many areas on earth that are extremely inhospitable. While it would be great if Mars could once be as hospitable as the more pleasant areas of the earth, that doesn't mean that less won't still make it possible (or even interesting) to live there.
Humans are quite resilient.
Now, try it against someone without deep pockets and you might just possibly have a chance to intimidate them into submission.
So if he isn't currently using the mark, he has no rights to it. If he is currently using the mark, it's still obvious that the name have been in use for far too long for the free product for him to have any rights to it unless it's in a significantly different market (and no, releasing a commercial version would certainly not be sufficient)
MAME's authors should assume hostility right from the outset because there is simply no legitimate reasons for this person to register the mark without having talked to them and arranged an agreement with them first.
It might be that he's "innocent", but if so he's also clueless enough about trademarks to be just as dangerous as if he's doing it on purpose and should be treated as such.
Duh. This must be the most obvious idea around. The reason it's not taken very seriously is that electrolysis requires vast amounts of electricity. You might as well have suggested that people get a kit to set up in their garage. Sure, it would work, but it wouldn't be cost effective, and neither is your suggestion likely to be.
The directive was NOT rejected by the EU Parliament, but by the Conference of Presidents - essentially the group leaders of all the various parliamentary parties. It's still a good step, but it's misleading to claim this was an action by the Parliament as a whole.
This does NOT mean that the bill "is thrown out". It means that the EU Parliament is supporting it's own legal affairs committee's call for the EU Commission to restart the process and have directed the President of the EU Parliament to officially request a restart.
The bill must not "go back to the EU" for reconsideration - the EU Commission must decide whether it wants to accept the restart vote by parliament, ignore it, or overrule it. The latter two would mean the Council would go ahead as before.
Too late. Tony Blair already made us the 51st state a long time ago.
The first sign of them going down was when they where stupid enough to sue IBM.
And if you'd bother to RTFA you'd see that the current approach focuses on using the Sindbis virus for delivery. Sindbis itself is not a full cure - it attacks cancer cells but is by no means guaranteed to be sufficient to destroy a tumour. That is why researchers are now looking at using it for delivering other "payloads" that are more lethal to the cancer cells. Many of these would toxic to normal substancs in the body, but using Sindbis allows focused delivery, potentially massively reducing the damage to the body.
Prior art is only relevant for patents.
But personally I prefer to use the Yahoo! MySearch beta. I just hope they end up integrating it with the online bookmarks.
That is only a small part of providing proper delivery guarantees.
I doubt very much your mail server has built in support for letting client applications handle transactions for instance (that is, only deliver a specific message if all messages in the transaction can be delivered).
It is very simple to add a layer on top of e-mail that ensures no message is delivered twice; you keep a database in your delivery spool of message-ids and don't deliver anything you already have. This isn't something the server I worked on does (it wasn't a design requirement) but it could easily be added. It would also be trivially easy for client software to filter out redundant messages. This seems like a non-problem to me.
Yes, it is simple. But you need to do it. When you add together all the things you need to do to emulate the full capabilities of a well written message queueing solution, it starts to quickly add up in terms of engineering and design time. It also means you'll end up with a system that there is no standard training available for, nor no third party tools, no ready made transaction monitors or routing software etc.
You seem to be particularly fond of mail servers, but I could layer the exact same functionality on top of an FTP server, via SCP, UUCP or over raw TCP connections. Perhaps I should claims they are all perfect substitutes for MQSeries and other message queueing solutions?
The only thing separating those (and many more - a web server with a CGI for instance) is the amount of additional code you'd have to write on top of it to get the message queueing functionality a proper message queueing system provides.
If you need the capabilities of provided by a message queueing system it doesn't take many hours of team members time spent before your simple solution has ended up costing your company more than buying a ready made well supported solution would cost you.
Use the right tool for the job.
Sometimes that is a mail server because you simply don't need all the features of a full message queueing solution - some engineers who worked for me at my last workplace put together a really good solution based on Qmail for instance. I loved the solution. It was simple, it did the job for a fraction of the price of MQSeries.
But it did the job because we couldn't care less about duplicate messages (all operations were idempotent) and because we judged the reliability of QMail to be good enough for THAT situation, and because cost was a major factor. So the layers my team wrote on top of it was tiny and simple.
But many people DO need the capabilities of a full message queueing solution, and in that case using a mail server as the foundation DOES mean a substantial amount of extra engineering that is unlikely to pay off in terms of money saved unless you're planning a really huge installation.
It's not that this can't be done over SMTP, but that SMTP isn't practical for it - you'd need lots of extra data in the headers, and applications supporting it.
Sure, you can write the support for all of it on top of SMTP, or FTP or SCP or HTTP or any protocol you can think of that can move data from one point to another, but the whole point of message queueing applications is that the heavy lifting has been done for you.
If you don't care about the transactions, or it doesn't matter if your messages can be delivered twice by mistake, or any of the other features of a proper message queuing system, then sure, go ahead and use a mail server - a previous place I worked we used Qmail with good results. It's a trade off, but the difference is huge.
The physics dictate that the design will be, and test show that the physics match reality. And yes, they have turned off the cooling to demonstrate this.
The graphite is covered in silicon carbide, so it won't burn. In fact the Chinese pebble bed design IS relying on a passive system for control - the reaction can't sustain itself without the coolant present, and will quickly slow down and stop.
78% of retail sales. The article also claims that the majority of office suites in Japan are sold pre-installed on new computers.