CHelper - Revision history

Skalogryz: /* attributes */

2015-03-03T14:36:48Z

‎__attributes__

Skalogryz: /* Compiler Features */

2015-03-03T14:36:18Z

‎Compiler Features

Skalogryz: /* attributes */

2015-03-03T14:35:10Z

‎__attributes__

Skalogryz: /* attributes */

2015-03-03T14:33:50Z

‎__attributes__

Skalogryz: /* CConvert */

2015-03-03T14:32:17Z

‎CConvert

Skalogryz: /* CConvert */

2015-02-28T04:54:45Z

‎CConvert

Skalogryz: /* CConvert */

2015-02-28T04:54:25Z

‎CConvert

Skalogryz: /* CConvert */

2015-02-28T04:53:20Z

‎CConvert

Skalogryz: /* CConvert */

2015-02-28T04:37:53Z

‎CConvert

Skalogryz: /* CConvert */

2015-02-28T04:19:31Z

‎CConvert

@@ Line 49: / Line 49: @@
 The cconvert is unable to parse the compiler directive. Instead of parsing it you could define it as a custom definition
-  custom_defines.h
+  custom_defines.h:
    #define __attribute__ (x, ...)
 That will cause the cconvert it ignore the directive.

@@ Line 35: / Line 35: @@
 ===__attributes__===
 The directive was introduced in [https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#Attribute-Syntax GCC] to give a hint to the compiler about the code
 Here's an example from svn_error.h (1.6.9)
   /** Create an error structure with the given @a apr_err and @a child,
@@ Line 48: / Line 49: @@
 The cconvert is unable to parse the compiler directive. Instead of parsing it you could define it as a custom definition
    #define __attribute__ (x, ...)
 That will cause the cconvert it ignore the directive.
-cconvert would stop with an error on __attribute__. But if the custom define is used it would just ignore it and generate
+cconvert would stop with an error on __attribute__. But if the custom define is used...
   function svn_error_createf(apr_err: apr_status_t; child: Psvn_error_t;
    fmt: PChar; par3: array of const): Psvn_error_t; cdecl; external;

@@ Line 34: / Line 34: @@
 Different C/C++ compiler might have the compiler specific syntax modifiers. It's assume that CConvert should handle them. However, if it's not, it should be possible to overcome the limitation by using preprocessor by defining a macros.
 ===__attributes__===
-The cconvert is unable to parse the compiler directive. Instead of parsing it you could define it as a custom definition
+The directive was introduced in [https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#Attribute-Syntax GCC] to give a hint to the compiler about the code
 Here's an example from svn_error.h (1.6.9)
   /** Create an error structure with the given @a apr_err and @a child,
@@ Line 49: / Line 46: @@
                     ...)
     __attribute__ ((format(printf, 3, 4)));
 cconvert would stop with an error on __attribute__. But if the custom define is used it would just ignore it and generate
   function svn_error_createf(apr_err: apr_status_t; child: Psvn_error_t;
    fmt: PChar; par3: array of const): Psvn_error_t; cdecl; external;

← Older revision		Revision as of 14:33, 3 March 2015
Line 37:		Line 37:
	#define __attribute__ (x, ...)		#define __attribute__ (x, ...)
	That will cause the cconvert it ignore the directive.		That will cause the cconvert it ignore the directive.
		+
		+	Here's an example from svn_error.h (1.6.9)
		+	/** Create an error structure with the given @a apr_err and @a child,
		+	* with a printf-style error message produced by passing @a fmt, using
		+	* apr_psprintf().
		+	*/
		+	svn_error_t *
		+	svn_error_createf(apr_status_t apr_err,
		+	svn_error_t *child,
		+	const char *fmt,
		+	...)
		+	__attribute__ ((format(printf, 3, 4)));
		+	cconvert would stop with an error on __attribute__. But if the custom define is used it would just ignore it and generate
		+	function svn_error_createf(apr_err: apr_status_t; child: Psvn_error_t;
		+	fmt: PChar; par3: array of const): Psvn_error_t; cdecl; external;

← Older revision		Revision as of 14:32, 3 March 2015
Line 31:		Line 31:
	float*=PSingle		float*=PSingle
	It suggests the pascal name equivalent for a C-declared type. Useful to avoid reserved named conflicts.		It suggests the pascal name equivalent for a C-declared type. Useful to avoid reserved named conflicts.
		+	==Compiler Features==
		+	Different C/C++ compiler might have the compiler specific syntax modifiers. It's assume that CConvert should handle them. However, if it's not, it should be possible to overcome the limitation by using preprocessor by defining a macros.
		+	===__attributes__===
		+	The cconvert is unable to parse the compiler directive. Instead of parsing it you could define it as a custom definition
		+	#define __attribute__ (x, ...)
		+	That will cause the cconvert it ignore the directive.

@@ Line 21: / Line 21: @@
 ;RefTypeNamePrefix (string, default "P"): prefix that should be added to each reference type (pointer). I'ts a common convention to name reference types in object pascal starting with "P". C syntax allows NOT to declare a special type name for reference type, for Pascal the ref-type declaration is required. Since there's usually no corresponding C-type it's fine to put "P" prefix for these auxilary types.
 ;FuncConv (string, default "cdecl"): function calling convention that should be used. When creating an interface for Win.DLL, it's likely that convention should be set to "stdcall"
-;FuncDeclPostfix (string) - additional pascal verbiage that should be added after the pascal function declaration (after function convention)
+;FuncDeclPostfix (string): additional pascal verbiage that should be added after the pascal function declaration (after function convention)
 ;ParamPrefix (string, default "par"): name of parameter, that's used for "nameless" function declarations (common for C++ dialect or C)
 :ExtLibName (string): the library name that should be added for "external" modified in pascal declarations.

@@ Line 15: / Line 15: @@
 Section [Main]
-* RecordsArePacked (0 / 1 default) - if set, the pascal code would explicitly set "packed" record for each C-struct defined
+;RecordsArePacked (0 / 1 default): if set, the pascal code would explicitly set "packed" record for each C-struct defined
-* FuncsAreExternal (0 / 1 default) - if set, any function declaration is considered as external function (otherwise "extern" modified is expected). You want to set this flag to 0, if you're intent to use static object files, rather than dynamically loaded library
+;FuncsAreExternal (0 / 1 default): if set, any function declaration is considered as external function (otherwise "extern" modified is expected). You want to set this flag to 0, if you're intent to use static object files, rather than dynamically loaded library
-* EnumAsConst (0 / 1 default) - the flag indicates, if enumerations should be declare in pascal as (integer) constants. Having enumeration declare as constants, rather than enumerations has it's own benefits, such as extensibility (an integer would accept any value) and well-defined file size (by default, pascal enumerations byte size, depends on the number of elements. C enumerations by default as 4-bytes, matching "int").
+;EnumAsConst (0 / 1 default): the flag indicates, if enumerations should be declare in pascal as (integer) constants. Having enumeration declare as constants, rather than enumerations has it's own benefits, such as extensibility (an integer would accept any value) and well-defined file size (by default, pascal enumerations byte size, depends on the number of elements. C enumerations by default as 4-bytes, matching "int").
-* TypeNamePrefix (string) - the prefix that should be added to each non-pointer type. It's a common convention to name types in object pascal starting with "T". However, when creating an interface to C, it's usually omitted.
+;TypeNamePrefix (string): the prefix that should be added to each non-pointer type. It's a common convention to name types in object pascal starting with "T". However, when creating an interface to C, it's usually omitted.
-* RefTypeNamePrefix (string, default "P") - prefix that should be added to each reference type (pointer). I'ts a common convention to name reference types in object pascal starting with "P". C syntax allows NOT to declare a special type name for reference type, for Pascal the ref-type declaration is required. Since there's usually no corresponding C-type it's fine to put "P" prefix for these auxilary types.
+;RefTypeNamePrefix (string, default "P"): prefix that should be added to each reference type (pointer). I'ts a common convention to name reference types in object pascal starting with "P". C syntax allows NOT to declare a special type name for reference type, for Pascal the ref-type declaration is required. Since there's usually no corresponding C-type it's fine to put "P" prefix for these auxilary types.
-* FuncConv (string, default "cdecl") - function calling convention that should be used. When creating an interface for Win.DLL, it's likely that convention should be set to "stdcall"
+;FuncConv (string, default "cdecl"): function calling convention that should be used. When creating an interface for Win.DLL, it's likely that convention should be set to "stdcall"
-* FuncDeclPostfix (string) - additional pascal verbiage that should be added after the pascal function declaration (after function convention)
+;FuncDeclPostfix (string) - additional pascal verbiage that should be added after the pascal function declaration (after function convention)
-* ParamPrefix (string, default "par") - name of parameter, that's used for "nameless" function declarations (common for C++ dialect or C)
+;ParamPrefix (string, default "par"): name of parameter, that's used for "nameless" function declarations (common for C++ dialect or C)
-* ExtLibName (string) - the library name that should be added for "external" modified in pascal declarations.
+:ExtLibName (string): the library name that should be added for "external" modified in pascal declarations.
 Section (Types)
 The section consists of pair - CType=Pascal Type name.

← Older revision		Revision as of 04:37, 28 February 2015
Line 11:		Line 11:

	It's quite common for a C library to have one base headers that's used to store definitions. The base header is (in)directly included by other headers of the library. Definitions declared in the base headers would be used by other headers of the library.		It's quite common for a C library to have one base headers that's used to store definitions. The base header is (in)directly included by other headers of the library. Definitions declared in the base headers would be used by other headers of the library.
		+
		+	-configuration file represents pascal code generation settings. The format of the file is .ini file. Following sections and values are expected to be in the file.
		+
		+	Section [Main]
		+	* RecordsArePacked (0 / 1 default) - if set, the pascal code would explicitly set "packed" record for each C-struct defined
		+	*

← Older revision		Revision as of 04:19, 28 February 2015
Line 9:		Line 9:

	-defines - allows to add additional C-preprocess definitions. This is used to add additional defines that are defined outside of the converted the converted header. It's allowed to define multiple definition files. If two different definitions are sharing the same name, the later definition takes precedence.		-defines - allows to add additional C-preprocess definitions. This is used to add additional defines that are defined outside of the converted the converted header. It's allowed to define multiple definition files. If two different definitions are sharing the same name, the later definition takes precedence.
		+
		+	It's quite common for a C library to have one base headers that's used to store definitions. The base header is (in)directly included by other headers of the library. Definitions declared in the base headers would be used by other headers of the library.

CHelper - Revision history

Skalogryz: /* __attributes__ */

Skalogryz: /* Compiler Features */

Skalogryz: /* __attributes__ */

Skalogryz: /* __attributes__ */

Skalogryz: /* CConvert */

Skalogryz: /* CConvert */

Skalogryz: /* CConvert */

Skalogryz: /* CConvert */

Skalogryz: /* CConvert */

Skalogryz: /* CConvert */

Skalogryz: /* attributes */

Skalogryz: /* attributes */

Skalogryz: /* attributes */