Parameterized Classes & Static Members: Tricky Q&A

Section Q&A

Rapid-fire interview questions for Parameterized Classes & Static Members. Answer out loud, then check yourself.

Q1. A class declares static int created inside class box #(type T). You instantiate box#(int) three times and box#(byte) once. What are the two created values?

Answer: box#(int)::created is 3 and box#(byte)::created is 1, because static storage is per specialization.

Trap: Assuming static is global for every T in the parameterized class.

Q2. Why do teams add typedef aliases like typedef packet#(byte,16) byte_packet_t?

Answer: Aliases make intended specializations explicit, reduce repeated #(type,value) boilerplate, and prevent accidental parameter mismatches across files.

Trap: Thinking typedef changes runtime behavior; it only names an existing specialization.

Q3. How are SV parameterized classes closer to C++ templates than Java generics?

Answer: SV and C++ both create distinct specialized types with specialization-specific statics, while Java generics are type-erased and class statics are shared regardless of generic argument.

Trap: Projecting Java's generic static behavior onto SystemVerilog classes.

Q4. A regression is flaky because txn::next_id is unexpectedly high in some tests. What is the first design-level fix?

Answer: Define and enforce a deterministic static reset policy, such as calling txn#(my_t)::reset_ids() in setup before traffic generation.

Trap: Treating it as randomization noise without auditing static lifetime and reset points.