C++ Redefine

Languages: [EN] English | [KO] 한국어

Images: [Hide]

C++ Redefine: A New C++ Programming Model

C++ Redefine: 새로운 C++ 프로그래밍 모델

C++ Redefine: c++ -20 (cpp negative 20) v0.0.1

Introduction 서론
- This document proposes a programming model designed to structurally resolve chronic C++ issues-such as memory bugs, ambiguous ownership, abstraction overhead, and spaghetti code-without transitioning to a new language. By integrating context-based ownership, namespace-based access control, and function pointer-based execution, this model facilitates entropy reduction and addresses the very challenges Rust seeks to solve at the language level, but through a structural architectural approach. 본 문서는 C++의 고질적 문제(메모리 버그, 소유권 불명확, 추상화 비용, 스파게티 코드)를 언어 교체 없이 구조적으로 해소하는 프로그래밍 모델을 제안한다. 컨텍스트 기반 소유권, 네임스페이스 기반 접근 제어, 함수 포인터 기반 실행 모델을 통합함으로써 코드의 엔트로피 감소 및 Rust가 언어 차원에서 해결하려 한 문제들을 구조 차원에서 해소한다.
- Since most native C++ features have been structurally excluded, it can be applied identically in a C environment with partial modifications (such as namespaces), and it is designed for ultra-high traffic servers and hardware control-level environments. C++ 고유 기능 대부분을 구조적으로 배제하였으므로 일부 수정시(네임스페이스 등) C 환경에서도 동일하게 적용 가능하며, 초고도 트래픽 서버와 하드웨어 제어 레벨 환경을 상정한다.
- This document is not a conceptual proposal, but a verified implementation spec from an actively running project Smeltrix 본 문서는 개념 제안이 아니라 실제 운영 중인 프로젝트 Smeltrix 에서 검증 된 구현 스펙이다.
- If even one of the structures of Redefine is violated, Redefine will not be established. Redefine 의 구조를 단 한개라도 위반하는 순간, Redefine은 성립하지 않는다.
Before / After 적용 전 / 후
- Before this model was established, modifying a single function often required tracking 5~6 related files due to hidden dependencies between classes. The actual fix took minutes, but finding where to fix took a long time. 본 모델 정립 이전에는 하나의 함수를 수정하면 클래스 간 숨겨진 의존성으로 인해 5~6개의 연관 파일을 추적해야 했다. 실제 수정은 몇 분이지만 어디를 수정해야 하는지 찾는 데 긴 시간이 소요되었다.
- After applying C++ Redefine, the file boundary is the access boundary. Modifications are structurally contained within the owning module. There is no need to trace hidden dependencies. C++ Redefine 적용 후에는 파일 경계가 곧 접근 경계이므로 수정 범위가 소유 모듈 내에서 구조적으로 완결된다. 숨겨진 의존성을 추적할 필요가 없다.
- This model is horizontally scalable, with complexity growing linearly as modules increase. This has been validated through standalone maintenance of 40,000 LOC. 이 모델은 수평적 확장이 가능하며, 모듈이 늘어나도 복잡도가 선형으로 증가한다. 40,000 LOC 의 단독 유지로 이를 검증하였다.
- This is not merely a claim - it is the direct experience that forced a complete redesign of the project that later became Smeltrix. 이는 단순 주장이 아니라 Smeltrix 의 전면 재설계를 했던 직접적인 경험이다.
- Smeltrix:
  - 0.0.5: As the codebase grew, the limitations of the traditional structure were anticipated, and a full redesign was decided upon. 0.0.5: 작성 코드의 증가로 인하여 기존 전통적 구조의 한계를 예측, 전면 재설계를 결심하였다.
  - 0.0.6: Through iterative code revision, the C++ Redefine model was established. 0.0.6: 지속적인 코드 수정을 통해 C++ Redefine 모델을 정립하였다.
  - The existing code was based on conventional class and parameter patterns, and was rewritten in its entirety. 기존 코드는 일반적인 class, 인자 방식이였고 전부 다시 작성하였다.
  - This process did not happen all at once. It was carried out incrementally - restructuring, replacing classes, eliminating parameters, converting variables to contexts, and introducing function pointer tables - while simultaneously adding new features and maintaining temporary compatibility with the existing code. As a result, the actual codebase at the time of 0.0.6 exceeded 40K LOC, including deleted code. 이 과정은 단번에 이루어지지 않았으며, 구조 변경, 클래스 교체, 인자 제거, 변수 ->컨텍스트화, 함수 포인터 테이블 도입 등 점진적으로 이뤄졌으며, 동시에 기능 추가 및 기존 코드 임시 호환성 작업을 같이 진행하였기 때문에 0.0.6 당시 실제 코드량은 삭제 코드 포함 40K LOC 를 넘어갔다.
  - Following the establishment of the model, maintenance costs decreased and development velocity increased dramatically. This is not merely a claim - it is a figure verified by development records. 모델 정립 이후 관리 비용 저하 및 개발 속도의 비약적 증가가 이루어졌다. 이는 단순한 주장이 아니라 개발 기록으로 검증된 수치다.
Naming Convention (How, What, Kind) 네이밍 규칙 (How, What, Kind)
- How:
  define, set, get, live, cache, max, min, active, is, buf
- What: A descriptive noun identifying the purpose. EX: CPU, GPU, TDP 목적을 명시하는 서술어 EX: CPU, GPU, TDP
- Kind:
  Unit or type such as W, MHz, IDX, C
- Examples:
  define_max_power_W, get_live_temp_C, set_active_IDX
- This convention ensures consistent readability and intent across the entire codebase. The role of any variable is immediately apparent from its name alone, without additional comments. 이 규칙은 코드 전체에서 일관된 가독성과 의도 파악을 보장하며, 별도의 주석 없이도 변수의 역할이 이름에서 즉시 파악된다.
Context Model 컨텍스트 모델 (Context Model)
- All state must be declared exclusively within the context of its corresponding cpp file. 모든 상태(state)는 반드시 해당 cpp의 컨텍스트 내에서만 선언되어야 한다.
- Initialization within the context is recommended using C++20 or later. If not possible, direct initialization in main.cpp is permitted. In either case, uninitialized state is not allowed. c++20 이상을 사용하여 컨텍스트 내 초기화 를 추천하며, 불가능시 main.cpp 에서 직접 초기화 한다, 어느 경우든 미초기화 상태는 허용되지 않는다.
- Variable definitions inside code blocks are prohibited(State -> Context, Temporaries -> Stack). Declarations are only permitted within the context. 코드 내부에서의 변수 정의는 금지(State -> Context, Temporaries -> Stack)되며, 선언은 오직 컨텍스트 안에서만 허용된다.
- Context lifetime is guaranteed until program termination. If cleanup is required, the owning module handles it. 컨텍스트 수명은 프로그램 종료 시까지 보장된다. 정리가 필요한 경우 해당 모듈이 스스로 처리한다.
- Multithreading and code reuse topic will be addressed in a separate post. 멀티스레딩과 코드 재사용은 차후 별도의 글에서 다룬다.
- Keep the no-heap principle for cold data, but select asserts as needed. 콜드 데이터는 힙 없음 원칙은 유지하되 assert는 필요에 따라 선택한다.
- Hot data context must include the following three static assertions: 핫 데이터 컨텍스트는 다음 세 가지 반드시 포함해야 한다:
  - static_assert(sizeof(Context) <= 64, "Heresy detected: Size overflow"); size must be a multiple of 64, change the value 64 to match your requirement size 는 64의 배수여야 하며 코드의 64는 필요한 수치로 변경 하여 사용 한다.
  - static_assert(std::is_trivially_copyable_v<Context>); proves no heap usage 힙 없음 증명
  - static_assert(std::is_standard_layout_v<Context>); predictable memory layout 메모리 레이아웃 예측 가능
Namespace Ownership Model 네임스페이스 소유권 모델 (Namespace Ownership)
- All code must be separated by namespace. A single file may only use one namespace. 모든 코드는 네임스페이스 단위로 분리되며, 하나의 파일은 하나의 네임스페이스만 사용한다.
- Ownership of a context belongs exclusively to main.cpp of the same namespace. Sub-namespaces can naturally access the parent context without argument passing. 컨텍스트의 소유권은 동일 네임스페이스의 main.cpp에만 귀속된다. 하위 네임스페이스는 상위 컨텍스트에 자연스럽게 접근 가능하다.
- The file boundary is the access boundary 파일 경계가 곧 접근 경계 public/private access control from class is replaced by static func() within the namespace of each file. class의 public/private 접근 제어는 파일 내 네임스페이스의 static func()으로 대체된다.
- When referencing the full namespace path, specify an absolute path (::Ex). 네임스페이스 전체 경로 참조 시 절대경로(::Ex)를 명시한다.
- borrowing 빌림 If information from another module is needed, implement borrowing via dereferenced pointer. Ownership remains in the original module, and pointer validity is guaranteed by context lifetime. 다른 모듈의 정보가 필요한 경우, 포인터 역참조(dereferenced pointer) 형태로 빌림(borrow)을 구현한다. 소유권은 원래 모듈에 유지되며, 포인터의 유효성은 컨텍스트 수명이 보장한다.
- Pipeline 파이프라인 Variables intended for borrowing must be registered in the pipeline context and then dereferenced for use. While direct connection between internal services can be used without this step, it is not recommended. External exposure must go through this process, and referencing the context itself is prohibited. 파이프라인 컨텍스트에 빌림 목적의 변수를 등록 후 역참조 하여 사용하여야 한다. 내부 서비스끼리 연결은 이 과정 없이 직접 사용해도 되지만 추천하지 않는다. 외부 노출은 반드시 이 과정을 거처야 하며 컨텍스트 자체를 참조하는 것은 금지 된다.
- TransFunk Smeltrix already has a dedicated layer called TransFunk, which is separated into pipelines and flowlines. The pipeline is a collection of components required for processing, integrated control, and data pointers, and the flowline is a kind of HAL that is a direct connection channel. It is named Transistor+Function = TransFunk by comparing it to a transistor. Smeltrix 에는 이미 TransFunk 라는 전용 계층이 존재하며 파이프라인, 플로우라인으로 분리되어 있다, 파이프라인은 처리과정 과 통합 제어, 데이터 포인터에 필요한 구성모음, 플로우라인은 일종의 HAL로 직통연결 통로이다 이를 트렌지스터에 비유하여 Transistor+Function = TransFunk 로 명명하였다.
- Both the UI and externally exposed APIs are connected through the pipeline. UI와 외부에 노출된 API 모두 파이프라인을 통해 연결한다.
- File split criterion 파일 분할 기준 Responsibility, not LOC. When a namespace exceeds a single role, split into a sub-namespace, File size is a result, not a constraint. LOC 가 아니라 책임이 기준. 네임스페이스가 하나의 역할을 넘으면 서브네임스페이스로 분리. 파일 크기는 결과물이지 제약이 아니기 때문이다.
Execution Model 실행 모델 (Execution Model)
- Separation of execution and implementation parts 실행부/구현부 분리 The implementation and execution parts are separated through function pointers. (The implementation part is encapsulated according to the execution model structure) 실행부와 구현부는 함수 포인터를 통해 분리한다, (실행 모델 구조 를 따르면 구현부는 캡슐화 상태)
- The implementation part is separated into the ::Impl namespace, and the execution part is called through FPTable. 구현부는 Ex::Impl 네임스페이스로 분리하며, 실행부는 FPTable을 통해 호출된다
- Zero-Cost Abstraction 무 비용 추상화 The FPTable is fixed after initialization and cached in the CPU Branch Target Buffer, resulting in no practical abstraction cost. FPTable은 초기화 후 고정되며, CPU Branch Target Buffer에 캐싱되므로 실질적 추상화 비용이 없다.
- no-argument and no-return 무인자, 무반환 no-argument and no-return are the guiding principles.
  Argument passing and return values are permitted only for external libraries. 무인자(no-argument), 무반환(no-return)을 지향한다.
  외부 라이브러리에 한하여 인자 전달 및 반환값을 허용한다.
- Lambdas: allowed but argument passing is not permitted. 사용 가능하나 인자 전달은 불가하다.
- Self-completeness 자기 완전성 Each module owns its own code by default, even for common logic. 각 모듈은 공통 코드라도 기본적으로 자체 소유를 원칙으로 한다.
- project-wide common code 프로젝트 전역 공통 코드 If necessary, place it in shared/define.h at the project root, though this is not recommended. 필요한 경우 프로젝트 루트의 shared/define.h를 사용하나, 권장하지 않는다.
- Allowed scopes in global define.h 전역 define.h의 허용 범위 debug flags, version constants, platform branches, common type aliases. State definitions are not allowed. 디버그 플래그, 버전 상수, 플랫폼 분기, 공통 타입 별칭. state 정의는 허용하지 않는다.
- Function pointer indirect calls structurally block static reverse engineering tools from tracing the call graph, providing security benefits without the need for separate obfuscation. 함수 포인터 간접 호출은 정적 역분석 도구의 call graph 추적을 구조적으로 차단하여, 별도 난독화 없이 보안 이점을 제공한다.
- Function pointer calls can be converted to direct calls via flags during debug builds, making static analysis and debugger tracing easier. 디버그 빌드 시 플래그를 통해 함수 포인터 호출을 직접 호출로 전환할 수 있어, 정적 분석 및 디버거 추적이 용이하다.
Error Handling 오류 처리 (Error Handling)
- Do not use exceptions in your own code. Error states are also held by the context. 자체 코드에서는 예외(exception)를 사용하지 않는다. 오류 상태 또한 컨텍스트가 보유한다.
- exception is permitted only for external libraries that may throw (e.g. JSON parsing, file I/O). 예외를 발생시킬 수 있는 외부 라이브러리(예: JSON 파싱, 파일 I/O)에 한하여 예외처리를 허용한다.

Directory Structure 디렉토리 구조 (Directory Structure)

Do not separate h/cpp. Organize by module instead. h/cpp 를 분리하지 않고 모듈 단위로 구성한다.
Always use project-relative paths with <> for includes (EX: <core/ex/main.h>). Use of "" is prohibited. include 경로는 항상 프로젝트 경로 포함 기준 (EX: <core/ex/main.h>) <>를 사용하며 ""는 금지한다.
Include placement must follow the execution dependency order. include 배치는 반드시 실행 의존 순서를 따른다.
Directory names must be synchronized with namespace names. The folder structure is the architecture document. 디렉토리명은 반드시 네임스페이스명과 동기화한다. 폴더 구조가 곧 아키텍처 문서이다.
Do not mix subfolders and files when creating a subnamespace. 서브 네임스페이스 생성 시 서브폴더와 파일을 혼재하지 않는다.

Each module directory contains: 각 모듈 디렉토리의 구성:

File	Namespace Scope	Architectural Role
context.h	`::Ex::Context`	State Ownership : Definition of state data structure State Ownership : 상태 데이터 구조 정의
define.h	`::Ex`	Foundation : Definition of types and constants Foundation : 타입 및 상수 정의
fptable.h	`::Ex::FPTable`	Execution Model : Function pointer-based execution interface Execution Model : 함수 포인터 기반 실행 인터페이스
impl.h	`::Ex::Impl`	Declarations : Internal Implementation Declarations : 내부 구현
impl.cpp	`::Ex::Impl`	Implementation : Business logic, detailed implementation Implementation : 비즈니스 로직 및 세부 구현
main.h	`::Ex`	Interface : Entry point definition Interface : 엔트리 포인트 정의
main.cpp	`::Ex`	Ownership : Entry point, ownership, and connection management Ownership : 엔트리 포인트, 소유권, 연결 관리

Allow / Deny 허용 및 금지 목록 (Allow / Deny)
- Deny:
  - macro - functional - preprocessor pollution macro - 함수형 - 전처리기 오염
  - template - User-defined template - code duplication via generation template - 사용자 정의 template - 코드 복사 생성
  - class - heap and virtual function overhead class - 힙/가상함수
  - auto - type ambiguity (allowed only when the expression is excessively long) auto - 타입 모호성 (단, 표현이 지나치게 길어질 경우 예외적으로 허용)
  - enum - global scope pollution enum - 전역 오염
  - inline - No abuse, only allowed under certain conditions, such as when performance is required inline - 남용 금지, 성능이 요구되는 등, 특정 조건에서만 허용
  - variable definition in code - state outside context is prohibited 코드 내 변수 정의 - 컨텍스트 외부의 상태 금지
- Allow:
  - Lambdas (argument passing is not permitted) 람다 (단, 인자 전달 불가)
  - static constexpr inside context 컨텍스트 내 static constexpr
  - Language features such as class/try/catch for external library support are allowed 외부 라이브러리 대응을 위한 class/try/catch 등 언어 기능은 허용
Team structure and file access policy 팀 구조 및 파일 접근 권한 (Team Structure)
- Junior handles implementation only. No knowledge of function pointer structure required. The structure itself prevents mistakes. 구현부만 담당. 함수 포인터 구조를 몰라도 되며, 구조가 실수를 차단한다.
  - impl.cpp, impl.h - read/write (rw)
  - all other files - read only (r)
- Senior manages module connections and execution model. Responsible for FPTable composition and ownership wiring. 모듈 연결 및 실행 모델 관리. FPTable 구성과 소유권 연결을 담당한다.
  - main.cpp, main.h, fptable.h - read/write (rw)
  - impl.cpp, impl.h - read only (r)
  - all other files - read only (r)
- Maintainer designs overall namespace structure and enforces rules. Responsible for context design and module boundary decisions. 전체 네임스페이스 구조 설계 및 룰 유지. context 설계와 모듈 경계 결정을 담당한다.
  - all files - read/write (rw)
- Operations Tips 운영 팁
  - impl_name.cpp clearly identifies the responsible developer. Ownership transfer makes accountability explicit. impl_name.cpp 로 구현 책임자 표시 및 소유권 이양으로 책임 소재 명확화
  - New implementations can be tested by simply swapping FPTable*. Rollback on failure is a one-liner - no git required. FPTable* 교체만으로 새로운 구현 테스트 가능, 오류 시 롤백이 한 줄로 완료 - git 없이도 원복 가능
  - Junior developers can create a personal implementation file such as impl_Smith.cpp and verify it via FPTable swap before merging into the mainstream. Junior 테스트 시 impl_kim.cpp 처럼 개인 구현부를 별도 파일로 작성 후 FPTable 교체로 메인스트림 투입 전 검증 가능.
The following content will be covered in a separate post 다음 내용은 별도의 게시물에서 진행 예정
- Code Reuse 코드 재사용
- External API Integration 외부 API 연동
- Pipelines 파이프라인
- Multithreading 멀티스레딩
- Function Pointer 함수 포인터
- Other details 기타 세부 사항
Conclusion 결론
- This architecture provides a clear starting point for beginners learning C++, while also offering experienced C++ developers a way to maintain safety and leverage their existing legacy assets. C++을 처음 배우는 입문자에게도 이 구조는 명확한 시작점을 제공하며, 기존 C++ 전문가의 레거시 자산을 그대로 활용하면서 안전성을 확보하는 경로를 제시한다.
- Which do you want?
  - C++ Permits everything. Guarantees nothing.
  - C++ Redefine permits less. Guarantees more.

wars.asm

_ O X

; ====================================================== ; ====================== EPILOGUE ====================== ; ====================================================== section .wars data The_Structured_Brotherhood: dw msg_10, msg_11 The_Corrupted_Warband: dw msg_20, msg_21 The_Comptime_Sorcerers: dw msg_30, msg_31 The_Simple_Horde: dw msg_40, msg_41 The_Machine_Cult: dw msg_50, msg_51 The_Endless_Swarm: dw msg_60, msg_61 ; The_Structured_Brotherhood msg_10 db "Structure is strength. Chaos is build failure.", 0 msg_11 db "My domain. My rules. My cpp.", 0 ; The_Corrupted_Warband msg_20 db "We promised safety. We brought borrow checker.", 0 msg_21 db "We never promised comfort.", 0 ; The_Comptime_Sorcerers msg_30 db "No hidden control flow. Only the Warp's logic.", 0 msg_31 db "The binary is a lie. Only the comptime is real.", 0 ; The_Simple_Horde msg_40 db "LGTM. Ship it.", 0 msg_41 db "Duplication over abstraction. Always.", 0 ; The_Machine_Cult msg_50 db "Write Once. Run Anywhere. Slowly.", 0 msg_51 db "The JVM is eternal. The cache line is not.", 0 ; The_Endless_Swarm msg_60 db "pip install everything.", 0 msg_61 db "dependency_hell==True", 0 section .text global _start _start: mov rax, 2 syscall

FAQ

Q: auto is banned?
A: Types must be explicit. auto is allowed where the type is too long or where it is required in lambdas.

Q: auto 금지
A: 타입은 명시, 타입이 너무 길거나 람다 에서 auto 가 필수인 곳에서는 허용.
Q: macro is banned?
A: Only Macros that generate code or alter control flow are banned.

Q: macro 금지
A: 코드를 생성하고 흐름을 바꾸는 macro 만 금지.
Q: template is banned?
A: User-defined templates are banned. STL templates are allowed.

Q: template 금지
A: 사용자 정의 template 금지. STL template 은 허용.
Q: What about existing libraries?
A: Separate them under externals. External code must not pollute internal structure, Divided into OS and Userland concepts

Q: 기존 라이브러리
A: externals로 분리. 외부 코드 => 내부 구조 오염 주의, OS 와 Userland 영역 개념으로 구분
Q: Why are so many C++ features restricted?
A: Redefine targets extreme environments - ultra-high traffic servers and hardware-level control. The restrictions are not rules but naturally derived consequences of that design target. In general applications, STL containers with internal heap allocation are possible but not recommended(this is not even an exception, at your own choice). Manual heap management is not allowed under any circumstances.

Q: 왜 이렇게 많은 C++ 기능이 제한?
A: Redefine은 초고도 트래픽 서버와 하드웨어 제어 레벨 환경을 상정하며, 제한 목록은 규칙이 아닌, 설계 타겟에서 도출된 결과이다. 일반 애플리케이션에 적용시 내부 힙 할당 STL 컨테이너 사용은 가능하지만 추천하지 않으며(예외 적용이 아니며, 전적으로 사용자 선택), 수동 힙 관리는 어떠한 경우에도 불가능하다.
Q: Incomplete?
A: The complete structure will not be covered in this document, A complete Redefine can only be achieved when combined with subsequent documents.

Q: 미완성?
A: Redefine의 전체 구현을 이번 문서에서는 다루지 않는다. 이후 내용들과 합쳐야만 Redefine을 구성할 수 있다.
Q: C++ -> C conversion?
- Design with C++ (Define)
- Refine to the purity of C (Refine)
- A complete state that runs in any environment (Fine)
A: Transformation is possible only when the codebase's redefinition structure is perfectly conditioned. The design of Redefine is handled structurally—clearing space is mapped 1:1 to C-style user (Ex::Impl::DoSomething -> Ex_Impl_DoSomething), outside of the POD is identical to C and outside of memory, and the FPTable is a C pointer itself. The transducer (tentatively named DRF) is intended to start anew, and the transducer provides the result of structural necessity for transferring rather than the original.
Q: C++ -> C 변환?
- C++로 설계(Define)하고
- C의 순수함으로 정제(Refine)하여
- 어떤 환경에서도 돌아가는 완전한(Fine) 상태
A: 변환은 코드베이스가 Redefine 구조가 완전히 적용된 조건하에서만 가능하며. Redefine의 설계가 이를 구조적으로 가능하게 한다 - 네임스페이스는 C 스타일 접두어로 1:1 매핑되고(Ex::Impl::DoSomething -> Ex_Impl_DoSomething), POD 컨텍스트 구조체는 C와 메모리 레이아웃이 동일하며, FPTable은 그 자체로 C 함수 포인터 구조체이다. 변환기(DRF 가칭)는 향후 출시될 예정이며 변환기는 번역기가 아닌 전달기가 될 것이며 구조적 필연의 결과이다.
Warhammer?
A: Games Workshop has maintained the Warhammer franchise for over 40 years through consistent lore, clear faction rules, and structured ownership of each domain. C++ Redefine draws the same lesson: A system survives not by adding more, but by maintaining the structure that holds it together. In that sense, GW and software architecture share the same worldview.

워해머?
A: Games Workshop은 40년 이상 일관된 세계관, 명확한 파벌 규칙, 각 영역의 구조화된 소유권을 통해 Warhammer 프랜차이즈를 유지해왔다. C++ Redefine은 같은 교훈을 따른다: 시스템은 더 많은 것을 추가함으로써가 아니라, 그것을 하나로 묶는 구조를 유지함으로써 살아남는다. 그런 의미에서 GW와 소프트웨어 아키텍처는 비슷한 세계관을 공유하고 있다.
Q: Design Philosophy?
This model pursues a Deterministic Structure. All state is owned by the context, all execution is determined by the FPTable, and external interference is structurally blocked.

Q: 디자인 철학?
이 모델은 결정론적 구조(Deterministic Structure)를 지향한다, 모든 상태는 컨텍스트가 소유하고, 모든 실행은 FPTable이 결정하며, 외부 간섭이 구조적으로 차단된다.
Q: Redefine?
Q: C?
Q: C#?

© 2026 [http://project-ap.blogspot.com]. All Rights Reserved. This content is exclusive to http://project-ap.blogspot.com. Any unauthorized reproduction, redistribution, or hosting of this material on other platforms is strictly prohibited. Sharing is permitted only via the original URL link.

이 게시물의 모든 이미지는 비상업적 용도로 사용하기 위해 AI가 생성한 비공식 팬 창작물입니다. Warhammer 40,000은 Games Workshop Ltd.의 상표이며 모든 권리가 보호됩니다.

C++ Redefine template code v0.0.1 (based on c++20)

context.h

vim - example/context.h

_ O X

//================================================================================ // // this code written by http://project-ap.blogspot.com/ // // Copyright (C) 2026 http://project-ap.blogspot.com/ // // This code is released under the MIT License. // Permission is hereby granted, free of charge, to any person obtaining // a copy of this code to use, copy, modify, merge, publish, distribute, // sublicense, and/or sell copies, subject to the above copyright notice // being included in all copies. // // For more information, please visit the blog address above. //================================================================================ #pragma once namespace Ex { struct Context { // Whatever you need int* id = nullptr; int clientid = -1; }; extern Context ctx; } //********************************************** // Uncomment after defining your struct with Hot data // Cold Data doesn't need these. //********************************************** // Waiting for excommunication //static_assert(sizeof(::Ex::Context::YourStruct) <= 64, "Heresy detected: Size overflow"); // required alignas(64) with YourStruct //static_assert(std::is_trivially_copyable_v<::Ex::Context::YourStruct>); //static_assert(std::is_standard_layout_v<::Ex::Context::YourStruct>);
define.h

vim - example/define.h

_ O X

#pragma once namespace Ex { struct Info { static constexpr int USR = 1; }; }
fptable.h

vim - example/fptable.h

_ O X

#pragma once namespace Ex { typedef void (*FnVoidNoArgs)(); struct FPTable { FnVoidNoArgs Init; }; extern FPTable* Current; extern FPTable FPTDefault; }
impl.h

vim - example/impl.h

_ O X

#pragma once namespace Ex::Impl { void DoSomething(); }
impl.cpp

vim - example/impl.cpp

_ O X

#include <example/context.h> #include <cstdio> namespace Ex::Impl { void DoSomething() { printf("%d", ctx.clientid); } }
main.h

vim - example/main.h

_ O X

#pragma once namespace Ex { void Init(); }
main.cpp

vim - example/main.cpp

_ O X

#include <example/context.h> #include <example/define.h> #include <example/fptable.h> #include <example/impl.h> #include <example/main.h> namespace Ex { Context ctx; FPTable FPTDefault = { Impl::DoSomething }; #if defined(YourCondition) FPTable* Current = &FPTDefault; #else //FPTable* Current = Put Your Table; #endif void Init() { // Do Someting Current->Init(); } }

Template code is released under the MIT License. Copyright © http://project-ap.blogspot.com. Permission is hereby granted, free of charge, to any person obtaining a copy of this code to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies, subject to the above copyright notice being included in all copies.

awakening.asm

_ O X

mov rax, 2 syscall ; [ SYSTEM ] STAGE 1: CANOPTEK UNITS DEPLOYED. ; [ SYSTEM ] LORDS: STILL IN STASIS. .L_TOMB_REPAIR: ; [ SCARAB ] STRUCTURAL DAMAGE DETECTED. ; [ SCARAB ] LIVING METAL RECONSTRUCTION: IN PROGRESS. ; [ SCARAB ] TOMB INTEGRITY: RESTORED. .L_INTRUDER_SCAN: ; [ SPYDER ] SCANNING FOR INTRUDERS... test rcx, rcx jz .L_STAGE1_COMPLETE .L_PURGE: ; [ SPYDER ] INTRUDER DETECTED. NEUTRALIZING. dec rcx jnz .L_PURGE .L_STAGE1_COMPLETE: ; [ STATUS ] TOMB: SECURE. ; [ SYSTEM ] INITIATING STAGE 2. jmp .L_AWAKEN [Press Enter]

[ ACCESS GRANTED ]
THE DYNASTY AWAKENS

Another Planet # /usr/local/bin/blog --start

Search This Blog

C++ Redefine

C++ Redefine: c++ -20 (cpp negative 20) v0.0.1

Which do you want?

C++ Permits everything. Guarantees nothing.

C++ Redefine permits less. Guarantees more.

FAQ

C++ Redefine template code v0.0.1 (based on c++20)

context.h

define.h

fptable.h

impl.h

impl.cpp

main.h

main.cpp

[ ACCESS GRANTED ]

Comments

Post a Comment