# huihut/interview packs 19 C and C++ topics into six directories under a licence that forbids company use

> huihut/interview is a Chinese language knowledge summary for C and C++ campus recruiting candidates and beginners, covering keywords, the STL, data structures, algorithms, operating systems, networking, and the link and load libraries, with interview write-ups and referral information alongside. It is well organised and honest about its sources, and its CC BY-NC-SA 4.0 licence puts company training material off limits.

**huihut/interview** — 📚 C/C++ 技术面试基础知识总结，包括语言、程序库、数据结构、算法、系统、网络、链接装载库等知识及面试经验、招聘、内推等信息。This repository is a summary of the basic knowledge of recruiting job seekers and beginners in the direction of C/C++ technology, including language, program library, data structure, algorithm, system, network, link loading library, interview experience, recruitment, recommendation, etc.

- Repository: https://github.com/huihut/interview
- Website: https://interview.huihut.com
- Stars: 38,236 · Forks: 8,066
- Language: C++
- License: NOASSERTION
- Published: 2026-09-17 · Updated: 2026-09-17 · Language: en
- Canonical page: https://hysenlabs.com/projects/huihut-interview

## Six top level directories sit under one 19 section README

The repository is a document, not a program, and the layout says so immediately. Six directories hold the bulk of the material: Algorithm/, DataStructure/, DesignPattern/, Problems/, STL/, and docs/. Two more support the presentation, images/ for the screenshots the README embeds and scripts/ for whatever generates or maintains them. The navigation itself lives in README.md, whose table of contents runs to nineteen entries, starting with C/C++, Effective, and STL, moving through data structures, algorithms, Problems, operating systems, computer networks, network programming, databases, and design patterns, then the link and load libraries, a books section, a section on C and C++ development directions, a list of practice websites, interview questions and experience, recruitment timing and positions, internal referrals, contributors, and the licence. An English version of the README sits alongside as README_en.md.

## The licence is non-commercial, and GitHub does not recognise it

The single most consequential line for reuse is the licence. The repository states that it follows CC BY-NC-SA 4.0, the attribution, non-commercial, share-alike variant, and spells out the obligation: credit the source, and do not use it for commercial purposes. That rules out a specific and common use, which is folding this material into a paid course or a company induction pack, unless you arrange something separately. There is a second wrinkle worth checking before you rely on it. GitHub's own metadata reports the licence as NOASSERTION, meaning the licence detector could not classify the file, so the automated badge on the repository page tells you nothing reliable and the text in the README is what governs. The author is also candid about provenance, stating that the notes come from original writing, reading notes, books, and blog posts, that anything not original is marked with its source, and asking for an issue if attribution is missing.

## Docsify serves the site, and the GitHub sidebar needs a browser extension

There are two reading routes and they have different costs. The first is the published Docsify site at interview.huihut.com, which renders the same Markdown with a working sidebar. The second is reading on GitHub itself, which has no sidebar of its own, so the repository points to a browser extension called jawil/GayHub that injects a table of contents navigation into GitHub pages. If you want a copy that survives a dead link, the notes give a specific procedure: open the Docsify page in Chrome, collapse the left sidebar, right-click, choose print, set the destination printer to save as PDF, and save. The reason for collapsing the sidebar first is that it would otherwise be repeated on every page of the output. For a revision workflow this matters more than it looks, because a single PDF is convenient to read and awkward to search against the live Markdown.

## Keyword entries are built as numbered rules and comparison tables

The style is consistent across the language topics, and recognising it tells you how to read an entry. Rules are numbered rather than narrated. The const entry lists four uses, covering a variable that cannot change, a pointer split into a pointer to const versus a const pointer, a reference to const used for parameter types so the value is neither copied nor modified, and a member function that cannot modify members. It then makes a point that trips up most readers: there is no const reference, because a reference is only an alias and not an object. The static entry follows the same four-way structure for variables, functions, member variables, and member functions, including the restriction that a static member function cannot reach non-static members. Comparisons are handled as tables, such as the one contrasting #define with a const constant across type checking, memory allocation, storage segment, and whether #undef can cancel it.

## The inline entry admits that the programmer does not make the call

The inline section is the most useful one for a reader who has been guessing. It starts with the mechanics the compiler performs: copying the function body to the call site, allocating space for local variables, mapping parameters and the return value into the caller's local scope, and rewriting multiple return points as branches at the end of the block using GOTO. Then it lists what you do not control. Inlining is only a suggestion, and the decision belongs to the compiler, so a programmer cannot force it. It also notes that a change to an inline function requires recompilation, unlike a normal function that can simply be relinked when a library updates, and that a function defined inside a class declaration is implicitly inline except for virtual functions. The virtual case is separated out: a virtual function can be marked inline, but it cannot be inlined while it is showing polymorphism, because inlining resolves at compile time and the call target does not exist until runtime.

## The this pointer entry records that its address cannot be taken

The this pointer section is a good example of a summary that records a rule precisely enough to be useful. It describes this as a special pointer implicit in every non-static member function, pointing at the object the call was made on, with the object address assigned before the call and passed as a hidden argument. Two details are the ones worth copying. The pointer is implicitly declared as ClassName *const this, so it cannot be assigned to, and inside a const member function its type becomes const ClassName* const, meaning the object it points at cannot be modified either. It is also described as an rvalue rather than an ordinary variable, which is why you cannot take its address, and &this is invalid. The entry then lists the three situations where you would still write it out, chained calls, avoiding an assignment to the same object, and implementing structures such as a list.

## assert is documented as a macro, and NDEBUG only works before the include

Small but consequential details are treated with the same care as the large ones. assert is identified as a macro rather than a function, defined in the C header assert.h and the C++ header cassert, whose effect is to terminate execution when its condition fails. The ordering constraint is the part that bites. Disabling it requires defining NDEBUG, and that define has to sit at the top of the source before the header is included:

```cpp
#define NDEBUG          // 加上这行，则 assert 不可用
#include <assert.h>

assert( p != NULL );    // assert 不可用
```

Put the define after the include and the assertion is still active, which is why a release build can keep asserting. The volatile entry is similarly concrete, describing the keyword as a type qualifier that stops the compiler from caching a value in a register because the operating system, hardware, or another thread may change it, and noting that const can combine with it for read-only status registers and that pointers can be volatile too. The sizeof entry draws the distinction that trips people up, whole array size for an array versus the pointer's own size for a pointer.

## Alignment splits into a compiler extension and the C++11 standard

The alignment material is organised as a direct opposition between two mechanisms, and the differences are the useful part. The compiler extension is #pragma pack(n), which limits the maximum alignment of members declared afterwards to n bytes for a struct, class, or union. The standard path is C++11: alignas(k) requests at least k-byte alignment, rounding up to the natural alignment, and alignof(T) retrieves a type's natural alignment requirement as a compile time constant. A table contrasts them on four axes. Standardisation, since pack is a compiler extension and alignas is in the standard. Direction, since pack can only reduce alignment while alignas can only increase it. Portability, since pack depends on the compiler and alignas works across platforms. And scope, since pack affects an entire structure while alignas can target a single member. The table also has a performance column that is cut off in the source, which is the one gap a reader has to fill elsewhere.

## Conclusion

This repository suits a student or a self-taught C or C++ developer who wants one browsable Chinese reference that links language rules to systems topics instead of scattering across blog posts, and the per-topic entries are short enough to revise from. It does not suit a company that wants to fold the material into internal training, because the non-commercial clause rules that out, and it does not suit a reader who needs a maintained reference with tagged versions, since there are no releases and no version history to pin. Before using it, read the attribution rules, since much of the content is adapted from books and blog posts with the source marked, and confirm your compiler and standard match the entry you are reading before treating a claim as settled.

## FAQ

### What is the huihut/interview repository for?

It is a summary of foundational C and C++ knowledge aimed at campus recruiting candidates and beginners. It covers the language, standard library, data structures, algorithms, operating systems, computer networks, network programming, databases, design patterns, and the link and load libraries, and adds interview write-ups, hiring schedules, and internal referral information.

### Can I use huihut/interview material in my company training program?

Not without a separate arrangement. The repository states that it follows CC BY-NC-SA 4.0, which requires attribution, share-alike distribution, and forbids commercial use, and it repeats that the content must not be used for commercial purposes.

### How do I read huihut/interview with a sidebar table of contents?

Use the published Docsify site at interview.huihut.com, which has a sidebar already, or add the jawil/GayHub browser extension to get table of contents navigation inside GitHub. To keep a local copy, the notes describe collapsing the sidebar, right-clicking, printing, and choosing save as PDF as the destination in Chrome.

### Does huihut/interview have releases or version tags to pin?

No. The repository has no GitHub releases, so there is nothing to install or pin a version to. Content is read from the master branch or the Docsify site, and the last push to master was on 17 September 2026.

### What does huihut/interview say about inline functions?

It states that inlining is only a suggestion to the compiler and that the decision belongs to the compiler, so a programmer cannot control it. It also notes that an inline function cannot be upgraded along with a library, because a change requires recompilation rather than a relink.

## Sources

- [huihut/interview on GitHub](https://github.com/huihut/interview)
- [Issues](https://github.com/huihut/interview/issues)
- [Project website](https://interview.huihut.com)
- [README](https://github.com/huihut/interview/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/huihut-interview