Feature #23424

Tool to build extern definition

Added by kju about 4 years ago. Updated about 3 years ago.

Status:Closed Start date:08/13/2011
Priority:Normal Due date:
Assignee:mikero % Done:

0%

Category:-
Target version:-
Affected Version:

Description

I thought FixAddon.exe or CreateTree.exe were made for this goal,
but for some reason both do not work for the attached file.

T:\pbodll>CreateTree.exe "C:\1config.cpp" 
CreateTree.exe Version 1.00, Dll 3.58 config.cpp
File C:\Dokumente und Einstellungen\Besitzer\Desktop\#\AI\cfgWeapons_recoil\config.cpp: Line 109 rap: missing inheritence class(es)
T:\pbodll>FixAddon.exe "C:\1\config.cpp" 
FixAddon.exe Version 1.65, Dll 3.58 config.cpp
File C:\Dokumente und Einstellungen\Besitzer\Desktop\#\AI\cfgWeapons_recoil\config.cpp: Line 109 rap: missing inheritence class(es)

config.cpp (30.3 kB) kju, 08/13/2011 16:51

History

Updated by mikero about 4 years ago

it's telling the truth

line109

class whatever: pistol

pistol is not declared

Updated by kju about 4 years ago

yes - but this is the reason for a tool to define/locate
the missing extern/parent classes, right?!?

Updated by mikero about 4 years ago

then the tool will be deprecated. There's too many assumptions made where the extern should be declared. It introduces errors of it's own.

Updated by kju about 4 years ago

What (type) of assumptions do you mean mikero?

In the most simple form, it only had to gather all missing extern definitions
and provide them as a list in the (error) return for example.

Updated by mikero about 3 years ago

  • Status changed from Feedback to Closed

the dll (and consequently all tools only list the first occurrence of an error). This based on the very solid knowledge that statistically, 'first error' produces the majority of subsequent errors. In point of fact, msdn news groups are full of screams that microsoft compiler tools don't follow this principle (stopping after first error) and how long it takes for a crap build to complete as a result.

1) It would be 'nice' to provide a convenient list of missing externs. My dll isn't designed for that.

2) Providing a list would produce too many phantoms. It would make wrong assumptions on subsequent classes that would only frustrate the user when re-editing. Instead, the extern is missing. Find it, fix it, test again.

2) Neither the tool(s) nor the dll can anticipate at which level of embedded classes the missing extern should have been declared. It only knows, it's missing from 'somewhere'.

Also available in: Atom PDF