I read in papers that Google has launched an offline shop for Chromebooks.
I went to check out the stop and the Chromebook.
The "Shop" is a two desk place with a dozen of demo notebooks in the PC World nearby Apple, Sony and other departments.
The Chromebook demoing there is Samsung Series 5 3G.
Below there are a few not quite good quality pictures I've done during an hour playing with this device at the shop.
Closed lid.
Left - power, a weird video connector, USB and audio.
Right - one more USB.
Front - SD.
The power socket is quite fragile.
Look at the keyboard.
Above Shift there is an interesting button called "Search" opening a new tab and pointing the cursor to the URL bar. In fact, CTRL-T. I liked this button.
There are internet related buttons in the top row. The button between full screen and the brightness is the switch amongst Chrome windows when there are multiple of them opened.
There are no Ins, Del, Page Up and Page Down.
After 8 seconds of boot time you see a login window for your Google Account (I used a demo one), and then the main screen comes out.
In Chromebook there is only one application - the Chrome browser. It is not possible to exit from it. You can only open new tabs and windows.
The Chrome itself differs from its desktop version. There are extra menus. For example, network settings.
WiFi
Russian keyboard layout is configurable through the settings.
Printing works via a direct connection to a USB printer (HCL is provided), or a "proper" Google way printing via Cloud Print.
It is possible to keep files locally. For instance, you can attach them to e-mails.
Only a few types of files allow to do anything with them. For example, photos and vides can be uploaded to WebPicasa.
All downloads and screenshots also go to the local storage.
Skype was not available, so I tried GTalk (this is mine shaved head in the window).
GTalk settings.
After a few minutes of jiggling around GTalk crashed.
Of course, I checked out the right website.
And another one.
And another one to figure out the overall performance.
Linux booted in 33 seconds. On my Mac Air Core Due it boots in 8 seconds. But bogomips were the same (~20) for some reason.
Now my biased conclusion.
400 quid is nuts. The notebook itself isn't light, tiny and slick, which could be an excuse for such high price, but there are a dozen of other netbooks around doing the same stuff, plus the rest.
Even at the shop, where WiFi was really fast, working fully online becomes annoying very soon due to network lags. The official "Offline Gmail" is available but it is a joke, and barely usable seriously.
For 50 quid I could buy it right there, just because I use Google's products and is willing to play with this "Google Console", but 400 is "no, thank you".
This compiles in C and C++ without any problems:
void* p = (struct this_does_not_exist *) -1;
Remove "struct", compile as C++ and get an error:
cast.cpp
cast.cpp(1) : error C2065: 'this_does_not_exist' : undeclared identifier
cast.cpp(1) : error C2059: syntax error : ')'
Adding a forward declaration:
class this_does_not_exist;
void* p = (this_does_not_exist *) -1;
And it again compiles cleanly.
All examples conform the Standard but to be honest the first one is really odd.
GCC gives a warning at least.
I don't remember where and when I dug this picture but since then I keep it. It nicely visualizes software development process.
Every time I come across famous Shakespeare's trade off "to refactor or not refactor" I come back to this picture. You can keep going to put more and more cheap crutches preventing your house from irreversible falling down. It can help for sometime but at some point there will be a point of no return. Or you can get all the people out of the house for a while and rebuilt it of bricks.
Consider the code:
#include <string.h>
#include <stdio.h>
int main(int argc, char* argv[]) {
char b[32];
strcpy(b, "123456789012345");
strcpy(b + 1, b);
printf("[%s]\n", b);
return 0;
}
There is a problem here because the parameters of strcpy() overlap.
This is an unpredictable behaviour because strcpy() doesn't guarantee the order of moving bytes (from left to right or vice versa) but the result depends on it.
Check on different compilers and platforms.
Visual Studio 2010 64-bit
[1123446788012245]
The result is corrupted every four bytes. Obviously, it has been copied 32 bit words.
Linux 64-bit
[1123456788012345]
The result is now different. Compiler and libc:
ldd --version
ldd (GNU libc) 2.5
gcc --version
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-50)
"man strcpy" says:
The strings may not overlap...
Why not "must not"?
Solaris (SPARC)
[1123446788012245]
Compiler and libc:
cc -V
cc: Sun C 5.8 2005/10/13
version /usr/lib/libC*
version of "/usr/lib/libC.so.3": SC2.0.1 12/20/94 Sun C++ 3.0.1 patch 100962-09
version of "/usr/lib/libC.so.5": Sun SUNWlibC SunOS 5.10 Patch 119963-06 2006/04/21
version of "/usr/lib/libCrun.so.1": Sun SUNWlibC SunOS 5.10 Patch 119963-06 2006/04/21
version of "/usr/lib/libCstd.so.1": Sun SUNWlibC SunOS 5.10 Patch 119963-06 2006/04/21
AIX
[1111111111012245]
This result is clearly wrong. The man pages are pretty clear on it:
String movement is performed on a character-by-character basis and starts at the left. Overlapping moves toward the left work as expected, but overlapping moves to the right may give unexpected results.
Compiler and libc:
lslpp -L | grep Compiler
vacpp.cmp.core 8.0.0.20 C F IBM XL C/C++ Compiler
lslpp -L | grep libc
bos.rte.libc 5.3.9.1 C F libc Library
HP-UX
[1123456789012345]
Compiler:
what `which cc`
HP C/aC++ for Integrity Servers B3910B A.06.22 [Nov 14 2008]
This result is correct but man pages warn in a funny way:
Character movement is performed differently in different implementations, so moves involving overlapping source and destination strings may yield surprises.
Conclusion: strcpy() is bad, due to many reasons.
Given a bipartite graph: "n" vertices on the left, "m" on the right and edges. The question is: how many edges in this graph are crossed?
In this example n=5, m=4, ten edges: 1-1, 1-2, 2-1, 2-2, 3-3, 4-1, 4-3, 5-1, 5-2, 5-4, a number of crossings: 10.
Crossings are always considered in pairs. For example, if three edges are crossed in one physical point, formally there are still three crossings, not one.
O(n*m) solution exist.
Sometimes you have to deal with raw arrays and pointers to them in C++, and also determine a number of elements in the array at compile time.
For example, it can be done this way:
#define arraysize(array) (sizeof(array) / sizeof(array[0]))
But there is a little problem over there. If accidently a pointer is passed to the this macro instead of an array, the code still compiles but the value will be far from being conceived.
There is a way to make this macro safer. For example, this is how Chrome authors do it:
template <typename T, size_t N>
char (&ArraySizeHelper(T (&array)[N]))[N];
#define arraysize(array) (sizeof(ArraySizeHelper(array)))
Looks cryptic, but we can break it apart:
Frankly, it is not easy to get it. But the macro is great.
By the way, we can play with sizeof() of the function return value type:
#include <iostream>
#include <string>
std::string f() {
return std::string();
}
int main() {
std::cout << sizeof( (&f)() ) << std::endl;
std::cout << sizeof( std::string ) << std::endl;
return 0;
}
My VS2010 prints out "28" twice.
Interestingly, in C it is also possible:
#include <stdio.h>
struct t {
char x[1024];
};
struct t f() {
struct t a;
return a;
}
int main() {
printf("%d\n", sizeof(struct t));
printf("%d\n", sizeof( (*f)() ));
return 0;
}
It prints out "1024" twice.
Posts
All Comments
