The sample code will copy a and b twice, once to put them in the lambda closure
Only without optimization flags enabled. Otherwise the lambda will be inlined in most cases.
BZZT! Wrong! Think: what happens if a and b are local variables and the function creating the thread returns before the lambda runs? They must be copied to somewhere that is not destroyed by the caller returning. That copy is not in the correct location because they are created before the thread stack, so another copy is unavoidable. The only way to fix it is to make do_something take const references. Though it is true that if do_something was inline it would probably fix it.
Show me the code
Yes it is ugly and I never claimed otherwise. The problem is that C++ compiles into the equivalent of this and it is hidden behind the scenes. Here is is pretty obvious that I must not pass a pointer to a or b, not so clear in C++: #include <pthread.h> #include <stdio.h> #include <malloc.h> #include <unistd.h>
void do_something(int a, int b) {
printf("do_something %d %d\n", a, b); }
void thread_do_something (int a, int b) {
lambda_args* v = (lambda_args*)malloc(sizeof(lambda_args));
v -> a = a;
v -> b = b;
pthread_t thread;
pthread_create (&thread, 0, lambda_run, v); }
assumptions about the order of static variable destructors
Yes this is a huge problem. Almost all of our code has static objects defined something like this:
static Foo& theStaticFoo = new Foo(2);
This is so the destructor is not run when the program exits, since it will usually crash because Foo relies on some other object that has already been destroyed.
An annoyance of this is that a non-optimizing compiler will do an extra level of indirection, and call malloc at startup.
It would be nice if C++ added some kind of syntax to make a static object that does not call the destructor without making construction or use less efficient. Possibly somehow sticking the much-overused "const" keyword in there somewhere?
I don't know why you want to modify strings in-place. Seems like you are complaining that it is not C-like. It would be much better if values were returned, for instance your "mystring.replace("from","to")" would not change mystring, but instead return a new string with the replacement done.
One of the biggest mistakes in std::string is that operator[] returns a non-const reference. This is so all those people raised on Visual Basic could capitalize by doing a[0]=toupper(a[0]). It also means that efficient copying of strings by using reference counts is impossible.
Making it a template just because a bunch of loonines thought that you could not do Unicode unless you made all the characters the same size was another mistake. Not only is the code unreadable and impossible to optimize, those idiots ended up with UTF-16 which is variable sized anyway. Duh.
The sample code will copy a and b twice, once to put them in the lambda closure, and then to pass them as arguments to do_something. Some may consider this wasteful (the easiest fix is to modify do_something to take the values as const references).
This is the general problem with C++, in that the shortest code is often the slowest. Adding const references to the declaration of do_something would remove the useless extra copy. The slowness is visible in C, where you would probably allocate a structure containing the copy of a and b, and have pthread_create call a function that copies them to the arguments to do_something and calls it, then deletes the temporary structure. This is equivalent to what the C++ compiles into but all the inefficiency is visible. This is the primary complaint about C++ verses C.
PS: I use C++ all the time and prefer it over C. But you do require a good knowledge of what it turns into, often stated in a pseudo-C, to figure out how and why things work and why slight variations (try using [&] instead of [=] in your lambda!) break in horrific ways.
The acceleration is now accessible by the client program as it draws into it's own frame buffer. On modern systems the client program can use the GPU as a resource to compute it's own results.
Wayland mostly is providing a way of telling a central service how to combine the client's frame buffer with all the other clients into the image put on the screen.
Again I am thoroughly confused. You suggest obvious and quite logical and good ideas such as "volume caps" and then act like they are evil without any explanation, just an apparent deep belief on your part that they are somehow obviously "bad".
And exactly why is "metered access" bad? You talked a lot about it but nowhere explained why it is bad, you just seemed to have made an assumption that everybody will think it is bad.
It is pretty obvious from other sales of bandwidth that the actual solution will be a fixed price for up to a threshold which exceeds what most people use, and metering after that. I think that would be an excellent way to charge for internet access.
It would also put some pressure on bloated web sites and ads if people realized they may actually be paying more to download it all.
Assuming you want Windows (and not Apple or Linux or BSD or any of a bunch of other suggestions people will make)
From previous statements it sounds like buying the much more expensive "business model" will get this. You may have to do a bulk purchase of dozens of them.
Another suggestion was to buy a system at a Microsoft store. They do have an interest in making Windows not suck.
To be fair, I don't think the trial Office does anything unless you actually open it (or open a.doc file). It's not like it pops up when you edit any text with a window saying "click here to edit your text in Office!".
Because they want a reliable way to return to the previous page. If you use the new tab a lot there will be a huge number of history items you would have to back up over to go back to the original page.
I prefer opening the new tab in back, however. I probably want to keep reading the page I clicked.
I seem to remember earlier Android browser having two items on the pop-up, one for a foreground tab and another for a background tab. Either my memory is faulty or this was removed a few years ago.
That's a nice excuse for/usr/bin but it is not true./usr was intended to be user-owned directories, and all the commands a user was expected to type would reside in/bin (and.). Early AT&T Unix systems had multiple disks and made "/usr" be the "big" one, since they mistakenly thought that documents and things users worked on would be far larger than the system. Then what happened is the system disk filled up as more and more commands were added, and they needed space to put more commands, and since $PATH meant the "/bin" was not hard-coded in most places so it was easy to search other directories, and the lack of symbolic links or union mounts at the time meant the only way to put something on the/usr disk was to make it a directory under/usr, they added/usr/bin and started populating that. Eventually this also happened with libraries and/usr/lib was added.
Some people then started the excuse that/bin was for "system binaries" as opposed to "user binaries" but the distinction was pretty random. Not only that,/bin eventually filled up with "system binaries" and they had to add/usr/sbin!
Eventually so much stuff was put in/usr that people stopped putting home directories there. A different directory allowed them to be on a different disk than the system which was now about 90% under/usr/bin and/usr/lib. Almost everybody used $HOME rather than any hard-coded values so this was possible to change. First/users was the new directory but this was changed to/home more recently).
Slashdot Mirror
Only without optimization flags enabled. Otherwise the lambda will be inlined in most cases.
BZZT! Wrong! Think: what happens if a and b are local variables and the function creating the thread returns before the lambda runs? They must be copied to somewhere that is not destroyed by the caller returning. That copy is not in the correct location because they are created before the thread stack, so another copy is unavoidable. The only way to fix it is to make do_something take const references. Though it is true that if do_something was inline it would probably fix it.
Show me the code
Yes it is ugly and I never claimed otherwise. The problem is that C++ compiles into the equivalent of this and it is hidden behind the scenes. Here is is pretty obvious that I must not pass a pointer to a or b, not so clear in C++:
#include <pthread.h>
#include <stdio.h>
#include <malloc.h>
#include <unistd.h>
void do_something(int a, int b) {
printf("do_something %d %d\n", a, b);
}
typedef struct {
int a, b;
} lambda_args;
void* lambda_run (void *p) {
lambda_args* v = (lambda_args*)p;
do_something(v->a, v->b);
free (v);
return 0;
}
void thread_do_something (int a, int b)
{
lambda_args* v = (lambda_args*)malloc(sizeof(lambda_args));
v -> a = a;
v -> b = b;
pthread_t thread;
pthread_create (&thread, 0, lambda_run, v);
}
int main()
{
thread_do_something(1, 2);
thread_do_something(3, 4);
sleep (1);
return 0;
}
1. Check whether a string s ends with a suffix t.
What about :
!s.empty() && s.back()=='t'
Or, before C++11 :
!s.empty() && (*s.rbegin())=='t'
I think the gp was assuming t was another string, not a byte.
assumptions about the order of static variable destructors
Yes this is a huge problem. Almost all of our code has static objects defined something like this:
static Foo& theStaticFoo = new Foo(2);
This is so the destructor is not run when the program exits, since it will usually crash because Foo relies on some other object that has already been destroyed.
An annoyance of this is that a non-optimizing compiler will do an extra level of indirection, and call malloc at startup.
It would be nice if C++ added some kind of syntax to make a static object that does not call the destructor without making construction or use less efficient. Possibly somehow sticking the much-overused "const" keyword in there somewhere?
I don't know why you want to modify strings in-place. Seems like you are complaining that it is not C-like. It would be much better if values were returned, for instance your "mystring.replace("from","to")" would not change mystring, but instead return a new string with the replacement done.
One of the biggest mistakes in std::string is that operator[] returns a non-const reference. This is so all those people raised on Visual Basic could capitalize by doing a[0]=toupper(a[0]). It also means that efficient copying of strings by using reference counts is impossible.
Making it a template just because a bunch of loonines thought that you could not do Unicode unless you made all the characters the same size was another mistake. Not only is the code unreadable and impossible to optimize, those idiots ended up with UTF-16 which is variable sized anyway. Duh.
"int i; printf( "%d", i );"
Most compilers are capable of producing a warning that you are using an uninitialized variable in this case.
The sample code will copy a and b twice, once to put them in the lambda closure, and then to pass them as arguments to do_something. Some may consider this wasteful (the easiest fix is to modify do_something to take the values as const references).
This is the general problem with C++, in that the shortest code is often the slowest. Adding const references to the declaration of do_something would remove the useless extra copy. The slowness is visible in C, where you would probably allocate a structure containing the copy of a and b, and have pthread_create call a function that copies them to the arguments to do_something and calls it, then deletes the temporary structure. This is equivalent to what the C++ compiles into but all the inefficiency is visible. This is the primary complaint about C++ verses C.
PS: I use C++ all the time and prefer it over C. But you do require a good knowledge of what it turns into, often stated in a pseudo-C, to figure out how and why things work and why slight variations (try using [&] instead of [=] in your lambda!) break in horrific ways.
The acceleration is now accessible by the client program as it draws into it's own frame buffer. On modern systems the client program can use the GPU as a resource to compute it's own results.
Wayland mostly is providing a way of telling a central service how to combine the client's frame buffer with all the other clients into the image put on the screen.
I believe it is perfectly legal to make legislation that alters what powers a government department has.
There are other reasons this is horse shit but that is not one of them.
Again I am thoroughly confused. You suggest obvious and quite logical and good ideas such as "volume caps" and then act like they are evil without any explanation, just an apparent deep belief on your part that they are somehow obviously "bad".
And exactly why is "metered access" bad? You talked a lot about it but nowhere explained why it is bad, you just seemed to have made an assumption that everybody will think it is bad.
It is pretty obvious from other sales of bandwidth that the actual solution will be a fixed price for up to a threshold which exceeds what most people use, and metering after that. I think that would be an excellent way to charge for internet access.
It would also put some pressure on bloated web sites and ads if people realized they may actually be paying more to download it all.
Town name?
What about the conduit monopoly?
Oh, let's fix that by allowing more than one conduit, maybe by making a much bigger conduit to carry them.
Uh oh, what about the "bigger conduit" monopoly?
Can you read? The original post says "or the time window for them to do so expires". There is a drop dead date.
You don't have to hide the extensions in order to make the GUI not change them. Just prevent the user from editing that part of the filename.
You are describing some sort of standard for magic cookies. This could easily be merged with the existing use of magic cookies.
There is however somewhat of a standard now: the first 4 bytes are a 4-letter code for the file type. Lots of image formats, in particular, use this.
Unix-like has stupid warts too, try creating a file named "-r" in a directory full of important sub-folders then delete it.
% rm -- -r
Assuming you want Windows (and not Apple or Linux or BSD or any of a bunch of other suggestions people will make)
From previous statements it sounds like buying the much more expensive "business model" will get this. You may have to do a bulk purchase of dozens of them.
Another suggestion was to buy a system at a Microsoft store. They do have an interest in making Windows not suck.
To be fair, I don't think the trial Office does anything unless you actually open it (or open a .doc file). It's not like it pops up when you edit any text with a window saying "click here to edit your text in Office!".
Nobody does that any more.
In addition the ability of a consumer to install from that disc is about equal to their ability to install Linux. It is not going to happen.
Because they want a reliable way to return to the previous page. If you use the new tab a lot there will be a huge number of history items you would have to back up over to go back to the original page.
I prefer opening the new tab in back, however. I probably want to keep reading the page I clicked.
I seem to remember earlier Android browser having two items on the pop-up, one for a foreground tab and another for a background tab. Either my memory is faulty or this was removed a few years ago.
Yes it is extremely common, because using two of them on each side of the tongue can look like a tongue piercing.
There is no ZERO floor in a house.
I take it you have never been to Europe?
That's a nice excuse for /usr/bin but it is not true. /usr was intended to be user-owned directories, and all the commands a user was expected to type would reside in /bin (and .). Early AT&T Unix systems had multiple disks and made "/usr" be the "big" one, since they mistakenly thought that documents and things users worked on would be far larger than the system. Then what happened is the system disk filled up as more and more commands were added, and they needed space to put more commands, and since $PATH meant the "/bin" was not hard-coded in most places so it was easy to search other directories, and the lack of symbolic links or union mounts at the time meant the only way to put something on the /usr disk was to make it a directory under /usr, they added /usr/bin and started populating that. Eventually this also happened with libraries and /usr/lib was added.
Some people then started the excuse that /bin was for "system binaries" as opposed to "user binaries" but the distinction was pretty random. Not only that, /bin eventually filled up with "system binaries" and they had to add /usr/sbin!
Eventually so much stuff was put in /usr that people stopped putting home directories there. A different directory allowed them to be on a different disk than the system which was now about 90% under /usr/bin and /usr/lib. Almost everybody used $HOME rather than any hard-coded values so this was possible to change. First /users was the new directory but this was changed to /home more recently).
He's referring to the Coors "Silver Bullet" ads.
There was an Onion article about the disastrous derailment of one of those bullet trains that caused mass casualties of young hip partying people.
I think that is exactly the sort of thing they are talking about when it says previous studies had "weak adjustment for confounders".