I recently got a piece of code from our French contractor that implemented some of the yet-unreleased requirements...guess what? it was written in French, with French comments, French functions and variables!
When I complained to the contractor's manager, the response was a 'duh'. At least they sent us an explanation in English of how the code worked.
The only realistic approach to space travel in our solar system is to build a good nuclear-driven space ship in orbit, big enough so as that people can live many years in it, with rotating sections to simulate gravity. This spaceship will never land onto planets, but it would contain pods that could land and take off.
It could take a few trillion dollars, but if all the major countries co-operate, it is feasible. All the money spent in weapons could be spent for space exploration.
The game "Return To Castle Wolfenstein" was a very entertaining single player FPS. The graphics were very good, the plot was suburb, and the whole game atmosphere made you want to finish it.
There is a group of video game players (that I belong to) that do not enjoy multiplayer FPSs. There is no thrill, for me, in killing other players. The thrill is to explore the environment, adapt to the situation and overcome the obstacles. Perhaps this group has become too small, because there are no FPSs for us any more.
My hope is that the new Wolfenstein game will be one such game (the other is Duke Nukem Forever, but I don't see that be released in this century).
If you see the logs of game devs, most work is thrown out. It takes them 3 or 4 iterations to finally achieve the desired result.
And it's not that so many iterations are required to achieve a result. The iterations are the result of the "relaxed" game dev culture which allows the game designers, artists, modelers, programmers etc to 'experiment', i.e. to spend their time playing with stuff just because they can.
"Ehm... that's a nice theory, but I second GP's experience in finding otherwise in practice. I don't know the specific reasons -- maybe there were memory fragmentation issues and it wasn't really STL's "fault" -- but I was doing some large-for-my-laptop (with 3GB ram) data processing, and initially used vectors for everything. I eventually had to give up and rewrite it all with arrays just like GP, because I kept having difficult-to-debug and impossible-to-fix memory issues as a result.
Really, why would someone bother "bullshitting" about something like this? He was pointing out a peculiarity of the overheads one particular program he worked with, I don't think he was doing it with some sort of anti-STL agenda or anything..."
No one in the above posts said anything remotely realistic about vectors. They even said that "std::vector does bounds checking". For God's shake, this is so untrue! the STL documentation says it with big bold letters that the operator [] does not do any bounds checking!!!!
"There might be systems on which this is true, but not on the c++ libraries on my mac. When I was trying to figure out what was going wrong with my vector-based program, I got to look at a lot of vectors from within gdb, and they have a neat bucket system going on that I'm sure is very fancy and clever, but let me tell you, it is not just an array, and good luck figuring out from the data alone what is stored in it unless you already know an awful lot about the underlying implementation..."
Bucket system? are you sure you used an std::vector? because buckets may be used in std::deque or std::tr1::unordered_set/map.
If your C++ environment has an std::vector implemented with buckets, then blame your specific C++ environment that violates the standard.
"No bullshit... at least in my case. std::vector does a lot of array bounds checking"
Std::vector::operator [] does not do bounds checking.
"and various other things that involve 'if' statements. You don't want them inside large loops. So I write my own vector classes - I make assumptions."
What other ifs? be more specific.
"Now, I used to have some kickarse vector (and matrix) templates but have had to ditch them with the release of the Harpertown processor because templates don't vectorise. This was ok for the Clovertown but the 256 bit wide register in the Harpertown (as opposed to the 128bit for Clovertown) made my template tricks redundant."
Why? if you use C arrays with the Harpertown, you can use std::vectors. They are interchangeable. Having access to the first element of the array, you can take a pointer to it and use it as a C array.
"First, vectors know their size; in particular, they know it in constant time. This means that they essentially must include a size field and update it whenever size changes."
If you use plain C arrays and you grow them manually, you will have to keep the size around yourself. So, you are only duplicating std::vector's work.
"Also, I can have a pointer to a vector, and that vector can grow arbitrarily without invalidating the pointer. That means that there pretty much has to be an indirect pointer to the vector's storage."
You would do this even if you did use a plain C array which you would reallocate in order to enlarge it.
"It also means that the vector's storage must more or less be coming from a heap, which definitely slows things down. ("more or less" because one can imagine certain optimizations that might be possible if you somehow knew an upper bound on the vector's lifetime size)"
If you use expandable arrays, then the storage is coming from the heap anyway. If you don't use expandable arrays, and you only need a fixed size array, then you wouldn't use STL in the first place.
"All of this stuff costs you in time and space"
But you can not avoid them if you want your arrays to grow in time. In any case, you simply dupe std::vector's work.
"Suppose I have a function I'm going to call a million times and it needs a temporary array of ints, of a size I can bound (maybe even small enough to be cache-beneficial). I can allocate that array in the parent function and pass in a pointer each time. Overhead to create and destroy the array in the inner function each time: zero. If you do this with a vector, the implementation has to zero the length, which costs time. Or you can delete and recreate it by letting it go out of scope, but that also costs time"
Obviously, you don't know STL good enough. With an std::vector, you set its size to the upper bound, and then use it as a standard C array, passing it to the child function. You don't need to zero its length each time you pass it to the child function.
"It could conceivably be that gcc's implementation of STL is a little slow. Doesn't matter why, though, because that's my target, and that's where my program has to run."
Well, if it is, don't blame the STL generally, blame GCC or the specific environment you work with.
"]It's been a while since I went through this exercise, so I don't have the exact scenario. But the code is GPL'ed and available here. If you can replace any of the arrays with an as-simple, as-fast use of vectors, I'd be happy to have it."
I am not going to do your work. You just simply have to replace your arrays with vectors. It's very simple.
(Somewhat ironically, some of the worst performance bottlenecks in this app had to do with the overhead of some of the STL containers, which I ended up having to replace with C-style arrays, etc. to get best performance.)
I smell bullshit. There is no overhead from using STL containers.
If you used an std::list or an std::map for random access, then you certainly had a bottleneck, because those containers are not for random access.
If you used an std::vector, you couldn't have a bottleneck, for the simple reason that the std::vector is an array.
All throughout the article, the back doors for malware are buffer overflows.
Isn't it time to write our software in something that does not allow buffer overflows? something better than C/C++, that is. The cost of securing apps written in these languages is tremendous...
I understand the difference (the wave is simply a fluctuation of the medium), but are we really sure that gravity is only a curvature? the speed of gravity is not infinite, (IANAP, but from what I have read from various articles) it is the speed of light, so could it be that gravity is a sort of a particle, undetected so far, with properties similar to a photon? i.e. no rest mass, with only kinetic energy.
A client/server application is not one application, it's two applications: one is the client, another is the server. The client can talk with any server that can respond appropriately.
If you extend the concept of an application to clients/servers, then all applications on all computers all over Earth are not free, because there is always some piece of code that is not free. For example, when you browse fsf.com from gnu/linux with Firefox, your data may pass through a Cisco router running proprietary Cisco software.
He did not say he does not browse the web. He said he does not use his own computer to do that. He probably uses another computer, either for security reasons or because he only wants free software to run on his machines.
Slashdot Mirror
The idea that burglars will be helped by Google's StreetView is absurd, to say the least.
The person from the interview says that they already had three incidents recently.
Burglars need a lot more information than a picture can offer them.
File sharing is legal.
Obtaining material without authorization is illegal.
Please let's not confuse these two.
Even dolphins read Slashdot!!!
A series allows the development of characters and story in much greater detail than movies allow. And Star Trek is special because of the details.
Star Trek became an important aspect of today's (sub) culture due to the series (TOS, TNG, DS9 etc). The movies aren't so important.
I recently got a piece of code from our French contractor that implemented some of the yet-unreleased requirements...guess what? it was written in French, with French comments, French functions and variables!
When I complained to the contractor's manager, the response was a 'duh'. At least they sent us an explanation in English of how the code worked.
The only realistic approach to space travel in our solar system is to build a good nuclear-driven space ship in orbit, big enough so as that people can live many years in it, with rotating sections to simulate gravity. This spaceship will never land onto planets, but it would contain pods that could land and take off.
It could take a few trillion dollars, but if all the major countries co-operate, it is feasible. All the money spent in weapons could be spent for space exploration.
But it's for the Apogee Duke Nukem games, the first of which is released on September, according to 3dRealms.
The game "Return To Castle Wolfenstein" was a very entertaining single player FPS. The graphics were very good, the plot was suburb, and the whole game atmosphere made you want to finish it.
There is a group of video game players (that I belong to) that do not enjoy multiplayer FPSs. There is no thrill, for me, in killing other players. The thrill is to explore the environment, adapt to the situation and overcome the obstacles. Perhaps this group has become too small, because there are no FPSs for us any more.
My hope is that the new Wolfenstein game will be one such game (the other is Duke Nukem Forever, but I don't see that be released in this century).
If you see the logs of game devs, most work is thrown out. It takes them 3 or 4 iterations to finally achieve the desired result.
And it's not that so many iterations are required to achieve a result. The iterations are the result of the "relaxed" game dev culture which allows the game designers, artists, modelers, programmers etc to 'experiment', i.e. to spend their time playing with stuff just because they can.
The stream of bullshit never ends.
"Ehm... that's a nice theory, but I second GP's experience in finding otherwise in practice. I don't know the specific reasons -- maybe there were memory fragmentation issues and it wasn't really STL's "fault" -- but I was doing some large-for-my-laptop (with 3GB ram) data processing, and initially used vectors for everything. I eventually had to give up and rewrite it all with arrays just like GP, because I kept having difficult-to-debug and impossible-to-fix memory issues as a result.
Really, why would someone bother "bullshitting" about something like this? He was pointing out a peculiarity of the overheads one particular program he worked with, I don't think he was doing it with some sort of anti-STL agenda or anything..."
No one in the above posts said anything remotely realistic about vectors. They even said that "std::vector does bounds checking". For God's shake, this is so untrue! the STL documentation says it with big bold letters that the operator [] does not do any bounds checking!!!!
"There might be systems on which this is true, but not on the c++ libraries on my mac. When I was trying to figure out what was going wrong with my vector-based program, I got to look at a lot of vectors from within gdb, and they have a neat bucket system going on that I'm sure is very fancy and clever, but let me tell you, it is not just an array, and good luck figuring out from the data alone what is stored in it unless you already know an awful lot about the underlying implementation..."
Bucket system? are you sure you used an std::vector? because buckets may be used in std::deque or std::tr1::unordered_set/map.
If your C++ environment has an std::vector implemented with buckets, then blame your specific C++ environment that violates the standard.
Even more bullshit.
"No bullshit ... at least in my case. std::vector does a lot of array bounds checking"
Std::vector::operator [] does not do bounds checking.
"and various other things that involve 'if' statements. You don't want them inside large loops. So I write my own vector classes - I make assumptions."
What other ifs? be more specific.
"Now, I used to have some kickarse vector (and matrix) templates but have had to ditch them with the release of the Harpertown processor because templates don't vectorise. This was ok for the Clovertown but the 256 bit wide register in the Harpertown (as opposed to the 128bit for Clovertown) made my template tricks redundant."
Why? if you use C arrays with the Harpertown, you can use std::vectors. They are interchangeable. Having access to the first element of the array, you can take a pointer to it and use it as a C array.
More bullshit.
"First, vectors know their size; in particular, they know it in constant time. This means that they essentially must include a size field and update it whenever size changes."
If you use plain C arrays and you grow them manually, you will have to keep the size around yourself. So, you are only duplicating std::vector's work.
"Also, I can have a pointer to a vector, and that vector can grow arbitrarily without invalidating the pointer. That means that there pretty much has to be an indirect pointer to the vector's storage."
You would do this even if you did use a plain C array which you would reallocate in order to enlarge it.
"It also means that the vector's storage must more or less be coming from a heap, which definitely slows things down. ("more or less" because one can imagine certain optimizations that might be possible if you somehow knew an upper bound on the vector's lifetime size)"
If you use expandable arrays, then the storage is coming from the heap anyway. If you don't use expandable arrays, and you only need a fixed size array, then you wouldn't use STL in the first place.
"All of this stuff costs you in time and space"
But you can not avoid them if you want your arrays to grow in time. In any case, you simply dupe std::vector's work.
"Suppose I have a function I'm going to call a million times and it needs a temporary array of ints, of a size I can bound (maybe even small enough to be cache-beneficial). I can allocate that array in the parent function and pass in a pointer each time. Overhead to create and destroy the array in the inner function each time: zero. If you do this with a vector, the implementation has to zero the length, which costs time. Or you can delete and recreate it by letting it go out of scope, but that also costs time"
Obviously, you don't know STL good enough. With an std::vector, you set its size to the upper bound, and then use it as a standard C array, passing it to the child function. You don't need to zero its length each time you pass it to the child function.
"It could conceivably be that gcc's implementation of STL is a little slow. Doesn't matter why, though, because that's my target, and that's where my program has to run."
Well, if it is, don't blame the STL generally, blame GCC or the specific environment you work with.
"]It's been a while since I went through this exercise, so I don't have the exact scenario. But the code is GPL'ed and available here. If you can replace any of the arrays with an as-simple, as-fast use of vectors, I'd be happy to have it."
I am not going to do your work. You just simply have to replace your arrays with vectors. It's very simple.
I smell bullshit. There is no overhead from using STL containers.
If you used an std::list or an std::map for random access, then you certainly had a bottleneck, because those containers are not for random access.
If you used an std::vector, you couldn't have a bottleneck, for the simple reason that the std::vector is an array.
Since the validation happens only once, does that mean that I can take the game and run it on any computer I want? how does that help combat piracy?
All throughout the article, the back doors for malware are buffer overflows.
Isn't it time to write our software in something that does not allow buffer overflows? something better than C/C++, that is. The cost of securing apps written in these languages is tremendous...
I understand the difference (the wave is simply a fluctuation of the medium), but are we really sure that gravity is only a curvature? the speed of gravity is not infinite, (IANAP, but from what I have read from various articles) it is the speed of light, so could it be that gravity is a sort of a particle, undetected so far, with properties similar to a photon? i.e. no rest mass, with only kinetic energy.
A client/server application is not one application, it's two applications: one is the client, another is the server. The client can talk with any server that can respond appropriately.
If you extend the concept of an application to clients/servers, then all applications on all computers all over Earth are not free, because there is always some piece of code that is not free. For example, when you browse fsf.com from gnu/linux with Firefox, your data may pass through a Cisco router running proprietary Cisco software.
He did not say he does not browse the web. He said he does not use his own computer to do that. He probably uses another computer, either for security reasons or because he only wants free software to run on his machines.
I couldn't agree more! the original was FUN. This new BSG takes itself too seriously!
Star Trek made you think without any religious aspect (at least in TOS and TNG).
The religious stuff is there simply because religion is on the rise.
It was a nightmare of Starbuck (the original one). He had ate too much.
Dump all the excessive population of this planet to the new one?
Maybe send the Chinese there? :-)
I hope the planets we find don't have gold or oil though...
Mac user more productive than Windows user? Care to back that up with some evidence?
What day is today? Microsoft bashing day? I've worked with Windows and Macs and let me tell you this, I find Windows the better environment.
Ballmer shouldn't have said that though, but I understand Microsoft is scared that its becoming irrelevant more and more as time passes by.
Wasn't the arrival of Jesus predicted?
They will propose the chip as the solution.