understand DB tables in a relatively large system

What do we mean “relatively large”?
– team size 5 – 15 including system support and developers
– tables 50 – 300

tbudget for a basic understanding of all the autosys jobs?
tbudget for a basic understanding of all the tables? 20h

I see 3 unambiguous groups of tables
– R: reference tables, mostly read-only, populated from upstream
– P: product-specific, “local” tables, since we have several independent streams of products
– C: core tables shared among many products

c++ forward class declaration vs "implementation"

a FCD is the minimum declaration of a class before its use. Here are some FCD in std::iosfwd library —

template class char_traits;
class char_traits;

In C++, i see 3 levels of class declarations
1) FCD
2) class definition using method prototypes, and field compositions ie a full listing of fields. Full listing required for memory allocation.
3) class fully defined with method bodies
4?) see another post for an alternative – pure abstract classes

Usually we put #2 in *.h; client programs “#include” our class definitions by macro expansion. We seldom need to put #3 in header files, though most boost header files are #3, with important consequences for linking and compiling.

effC++ item 34 has a detailed treatment of #1 vs #2. FCD, being the minimum declaration, is also known as the “interface”, whereas #2 is known as an “implementation” and “class definition”.

Puzzled by the word “implementation”? Think of a Car as an abstract concept. Different car makers “implement” it by using concrete components. A specific implementation of car is essentially a listing of non-static fields.

Put another way, implementation means composition.

Compiler need the size of each field (possibly user-defined-types) in order to size up your Car instance. new expression and operator new calls sizeof(Car). In java, primitive fields have known sizes; all reference fields occupy 4 bytes (32-bit machine). I believe c++ compiler actually calculates and determines the address of each new’ed object — the address is not determined at runtime.

As you write a client program, you could sometimes choose to include the API classes by FCD rather than #2. I feel If you don’t open up an API object to access its members, and you only mention the class name in method signatures, then FCD suffices.

The motivation behind Item #34 is compile-time dependency and coupling. I feel it’s c++ specific. By the way, decoupling is one of my favorites, and is a practical priority compared to a lot of other design principles.

shadowing a package var (perl

it’s confusing to use a lexicial $v in a sub1(), and in the same sub1() use another $v.

What kind of var is the other $v? I think it has to be a package var (both $v active simultaneously in 2 worlds), NOT another lexical. I think if it’s another lexical, then u can’t access it in sub1(). It’s shadowed and can’t be unshadowed.

If (in a legacy system) it’s a package var, then u can say $main::v. I don’t see any other way. I believe use vars qw($v) won’t work.

private constructor in c++

This class has a private no-arg ctor and a static createInstance(). Tested in IDE.


#include
using namespace std;

class PrivateCtor
{
public:
virtual ~PrivateCtor() {}
static PrivateCtor& createInstance(){
PrivateCtor* ptr = new PrivateCtor();
return *ptr;
}
PrivateCtor(const PrivateCtor& other) { cout<<"copier\n";} // called from main. can't be private
private:
PrivateCtor() { cout<<"noarg\n";}
PrivateCtor& operator=(const PrivateCtor& other) { return *this; }
};
int main(){
PrivateCtor s = PrivateCtor::createInstance(); // calls noarg then copier
}