1) $ blkid
show the device file system (/dev/sda1) & UUID & TYPE.
2)
$ sudo mkdir /mnt/NewVolume $ sudo cp /etc/fstab /etc/fstab.backup $ sudo gedit /etc/fstab 在最後加上 # <file system> <mount point> <type> <options> <dump> <pass> e.g.
# 2T DataVolue was on /dev/sda1 during installation UUID=e2878ada-c996-41d9-a91f-5ae803525355 /mnt/NewVolume ext4 defaults 0 2 按照 /etc/fstab 的設定自動重新掛載一次 (不用重開機) $ sudo mount -a
(if "unable to resolve host")
$ sudo -i
$ mount -a
Installation error:
Exit Code: 34
-------------------------------------- Summary --------------------------------------
- 1 fatal error(s), 0 error(s), 0 warning(s)
FATAL: Payload '{3F023875-4A52-4605-9DB6-A88D4A813E8D} Camera Profiles Installer 6.0.98.0' information not found in Media_db.
-
Solution:
Delete the .db files in “C:\Program Files (x86)\Common Files\Adobe\caps”
| Kernel Functions, K(u) |  |  | ||
|---|---|---|---|---|
| Uniform |  |  |  |  |
| Triangular |  |  |  |  |
| Epanechnikov |  |  |  |  |
| Quartic (biweight) |  |  |  |  |
| Triweight |  |  |  |  |
| Tricube |  |  |  |  |
| Gaussian |  |  |  |  |
| Cosine |  |  |  |  |
// find score difference Sort the vector by the first element increasingly
std::vector<std::pair<int, ColorCategory> > labelColorPairs;
std::sort(labelColorPairs.begin(), labelColorPairs.end(),boost::bind(&std::pair<int,ColorCategory>::first, _1) <boost::bind(&std::pair<int,ColorCategory>::first, _2));
Other bind functions (overload operators)
std::remove_if( first, last, !bind( &X::visible, _1 ) ); // remove invisible objectsand compare the result of bind against a value:std::find_if( first, last, bind( &X::name, _1 ) == "Peter" );std::find_if( first, last, bind( &X::name, _1 ) == "Peter" || bind( &X::name, _1 ) == "Paul" );You can find them in details:
1 |
If a class defines virtual methods outside that class, then g++ generates the vtable only in the object file that contains the outside-of-class definition of the virtual method that was declared first:
The vtable will be in test1.o, but not in test2.o
This is an optimisation g++ implements to avoid having to compile in-class-defined virtual methods that would get pulled in by the vtable.
The link error you describe suggests that the definition of a virtual method (str::f in the example above) is missing in your project.
|
C:\Users\your_user_name\AppData\Roaming\.emacs.d\color-theme-6.6.0 (change or remove the version number as you like)color-theme-6.6.0.zipcolor-theme.el and the folder themes into the folder you created in step 1.emacs (you may have to strip out any previous color theme settings yourself):class Base
{
// some virtual methods
};
class Derived : public Base
{
~Derived()
{
// Do some important cleanup
}
}Base *b = new Derived();
// use b
delete b; // Here's the problem!b is a Base* pointing to a Derived object, delete bhas undefined behaviour. In most implementations, the call to the destructor will be resolved like any non-virtual code, meaning that the destructor of the base class will be called but not the one of the derived class, resulting in resources leak.#include <iostream>
using namespace std;
class base
{
public:
base(){cout<<"Base Constructor Called\n";}
~base(){cout<<"Base Destructor called\n";}
};
class derived1:public base
{
public:
derived1(){cout<<"Derived constructor called\n";}
~derived1(){cout<<"Derived destructor called\n";}
};
int main()
{
base* b;
b=new derived1;
delete b;
}Base Constructor Called
Derived constructor called
Base Destructor called#include <iostream>
using namespace std;
class base
{
public:
base(){cout<<"Base Constructor Called\n";}
virtual ~base(){cout<<"Base Destructor called\n";}
};
class derived1:public base
{
public:
derived1(){cout<<"Derived constructor called\n";}
~derived1(){cout<<"Derived destructor called\n";}
};
int main()
{
base* b;
b=new derived1;
delete b;
}Base Constructor Called
Derived constructor called
Derived destructor called
Base Destructor called$ rename s/"SEARCH"/"REPLACE"/g **). The /g means global, so if you had a "SEARCH SEARCH.jpg", it would be renamed "REPLACE REPLACE.jpg". If you didn't have /g, it would have only done substitution once, and thus now named "REPLACE SEARCH.jpg". If you want case insensitive, add /i (that would be, /gi or /ig at the end).$ rename s/'^'/'MyPrefix'/ * That would add MyPrefix to the beginning of every filename. You can also do ending: $ rename s/'$'/'MySuffix'/ *-n option will just show what would be renamed, then exit. This is useful, because you can make sure you have your command right before messing all your filenames up. :)
The cache is there to reduce the number of times the CPU would stall waiting for a memory request to be fulfilled (avoiding the memory latency), and as a second effect, possibly to reduce the overall amount of data that needs to be transfered (preserving memory bandwidth).
Techniques for avoiding suffering from memory fetch latency is typically the first thing to consider, and sometimes helps a long way. The limited memory bandwidth is also a limiting factor, particularly for multicores and multithreaded applications where many threads wants to use the memory bus. A different set of techniques help addressing the latter issue.
Improving spatial locality means that you ensure that each cache line is used in full once it has been mapped to a cache. When we have looked at various standard benchmarks, we have seen that a surprising large fraction of those fail to use 100% of the fetched cache lines before the cache lines are evicted.
Improving cache line utilization helps in three respects:
Common techniques are:
We should also note that there are other ways to hide memory latency than using caches.
Modern CPU:s often have one or more hardware prefetchers. They train on the misses in a cache and try to spot regularities. For instance, after a few misses to subsequent cache lines, the hw prefetcher will start fetching cache lines into the cache, anticipating the application's needs. If you have a regular access pattern, the hardware prefetcher is usually doing a very good job. And if your program doesn't display regular access patterns, you may improve things by adding prefetch instructions yourself.
Regrouping instructions in such a way that those that always miss in the cache occur close to each other, the CPU can sometimes overlap these fetches so that the application only sustain one latency hit (Memory level parallelism).
To reduce the overall memory bus pressure, you have to start addressing what is called temporal locality. This means that you have to reuse data while it still hasn't been evicted from the cache.
Merging loops that touch the same data (loop fusion), and employing rewriting techniques known as tilingor blocking all strive to avoid those extra memory fetches.
While there are some rules of thumb for this rewrite exercise, you typically have to carefully consider loop carried data dependencies, to ensure that you don't affect the semantics of the program.
These things are what really pays off in the multicore world, where you typically wont see much of throughput improvements after adding the second thread.
| |||
|
22
|
I recommend reading the 9-part article What every programmer should know about memory by Ulrich Drepper if you're interested in how memory and software interact. It's also available as a 104-page PDF.
|
