Jan Marco. Zo gretig als jij ook in het bovenstaande weer klinkt, ik ben toch wel heel benieuwd wat voor software dat gaat worden die jij zit te schrijven. Als jij daarbij in je enthousiasme wat doorschiet, maakt niet uit, weer mijn pakkie-an om je een beetje af te remmen?
Hoi Weerman,
Ik ben niet zo zeer bezig met het programmeren ‘van scratch af’, maar meer met het integreren van de verschillende bestaande source distributies. Wel werk ik het liefst met C en/of CPP code. Ik compileer het door alle code met includes in het hoofdprogram in te voegen. Ik geloof in het Amalgamationconcept. Zie ook appendix A. Voordeel is dat je source code gemakkelijk kan transporteren naar andere projecten. Denk aan 1 loggingroutine die alle programma’s gaan gebruiken.
Een project gebruikt m.i. twee typen include files.
Eerste type zijn de Windows include files (stdlib.h, stdio.h, etc.) en tweede type zijn de door het project zelf gemaakte include files. Ik gebruik voor de Windows-include-files 1 file met alle Windows include files. Ik ben er achter gekomen dat de volgorde van deze include files belangrijk is voor het goed kunnen compileren. Elk project source codes stop in 1 file en de specifieke project include files stop ik er maar 1 keer in. Compileren gaat snel omdat Visual Studio maar weinig include files hoeft te laden.
Probleem waar ik tegen aanloop is dat de source code project steeds vernieuwen en ik steeds veel tijd moet steken in het integreren in het totale source stack en loop dus steeds achter de feiten aan. Om dit probleem op te lossen wil ik tools gaan ‘bouwen’ die de C/CPP source code preprocessen. Dus conflicten automatisch oplossen als ik nieuwe (GIT) source ga integreren en daarbij wil ik ook de source automatisch gaan formateren zoals ik het liefst het graag zie. Eigenlijk maak je persoonlijke view op de source code.
Voor preprocessen ga ik eerst naar 8cc kijken hoe het werkt. Dus niet het gedeelte van 8cc gebruiken die de C/CPP code omzet naar machine taal. Wel de source gaan omzetten naar een nieuwe geïntegreerde versie. Daarna deze code met de gebruikelijke Visual Studio (Windows platform) compiler compileren.
Later mogelijk naar andere programma kijken, zoals Flex, Bison, Jason, etc. Mijn uiteindelijk doel is om met 1 druk op de knop bijvoorbeeld de nieuwste versie van llvm en libxml2 in Clamav kunnen integreren.
Wat mij opviel is dat Apple ook de Clang compiler op het llvm (http://llvm.org/releases/download.html ) platform gebruikt. Anders geformuleerd zou ik mogelijk ook logica van Clang kunnen gebruiken.
Weerman, Hierbij een nieuwe Uber variant
De hartelijke groet Jan Marco
Appendix A: Scintilla:
Scintilla is a free source code editing component which includes useful features such as syntax styling, error indicators, folding, code completion and call tips. The project includes SciTE (SCIntilla based Text Editor). See Scintilla download | SourceForge.net
Appendix B: Amalgamation:
Amalgamation Versus Individual Source Files:
SQLite is built from over one hundred files of C code and script spread across multiple directories. Building the necessary C programs and transforming and/or creating the C-language source code for SQLite is a complex process.
To simplify matters, SQLite is also available as a pre-packaged amalgamation source code file: sqlite3.c. The amalgamation is a single file of ANSI-C code that implements the entire SQLite library. The amalgamation is much easier to deal with. Everything is contained within a single code files, so it is easy to drop into the source tree of a larger C or C++ program.
Building SQLite directly from individual source code files is certainly possible, but it is not recommended. For some specialized applications, it might be necessary to modify the build process in ways that cannot be done using just the prebuilt amalgamation source file downloaded from the website. For those situations, it is recommended that a customized amalgamation be built (as described below) and used. In other words, even if a project requires building SQLite beginning with individual source files, it is still recommended that an amalgamation source file be used as an intermediate step. See How To Compile SQLite
Appendix C: 8CC:
compiler functions: To checkout this MIT-licensed C11 compiler, see GitHub - rui314/8cc: A Small C Compiler There is yet another small hobbyist, open-source code compiler to talk about this weekend. Hello 8cc. The 8cc project is a compiler aimed at keeping its code as small and simple as possible while supporting all C11 language features. The 8cc compiler is in a state that it can self-host, but it’s not an optimizing compiler and the lead developer admits that the generated code out of 8cc is “usually 2x or more slower than GCC.” The 8cc project isn’t based on LLVM or any other compiler infrastructure. At the moment this small C11 compiler only supports x86_64 Linux and portability isn’t a concern for now. This is just a small project but is interesting for its clean code if you’re wanting to learn more how a C
Appendix D: Compiler:
A compiler is a translator whose source language is a high-level language and
whose object language is close to the machine language of an actual computer.
The typical compiler consists of several phases each of which passes its output
to the next phase
• The lexical phase (scanner) groups characters into lexical units or tokens.
The input to the lexical phase is a character stream. The output is a
stream of tokens. Regular expressions are used to define the tokens recognized
by a scanner (or lexical analyzer). The scanner is implemented as a
finite state machine.
Lex and Flex are tools for generating scanners: programs which recognize
lexical patterns in text. Flex is a faster version of Lex. In this chapter
Lex/Flex refers to either of the tools.
• The parser groups tokens into syntactical units. The output of the parser
is a parse tree representation of the program. Context-free grammars are
used to define the program structure recognized by a parser. The parser
is implemented as a push-down automata.
Yacc and Bison are tools for generating parsers: programs which recognize
the structure grammatical structure of programs. Bison is a faster version
of Yacc.
Appendix E: FLEX:
flexc++: A C++ class scanner generator comparable to flex. See flexc++ - Browse Files at SourceForge.net
Appendix F: JSON:
JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999. JSON is a text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. These properties make JSON an ideal data-interchange language.
JSON is built on two structures:
• A collection of name/value pairs. In various languages, this is realized as an object, record, struct, dictionary, hash table, keyed list, or associative array.
• An ordered list of values. In most languages, this is realized as an array, vector, list, or sequence.
These are universal data structures. Virtually all modern programming languages support them in one form or another. It makes sense that a data format that is interchangeable with programming languages also be based on these structures. Jsoncpp is an implementation of a JSON (http://json.org ) reader and writer in C++. JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. See GitHub - open-source-parsers/jsoncpp: A C++ library for interacting with JSON.