Template:Leaking Nasal disclaimer: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
mNo edit summary
No edit summary
Line 1: Line 1:
{{caution|Using the <code>{{{oldapi|foo}}}</code> API, it is fairly easy to leak resources by not using the API properly. This happens typically by not keeping track of how many callbacks are registered to be invoked by a timer/listener. Equally, [[Reset & re-init]] handling is usually not handled properly by such low-level code. These days, it is generally recommended to favor the <code>{{{newapi|bar}}}</code> API instead. Alternatively, you should consider wrapping the low-level APIs using a helper class.}}
{{caution|Using the <code>{{{oldapi|foo}}}</code> API, it is fairly easy to leak resources by not using the API properly. This happens typically by not keeping track of how many callbacks are registered to be invoked by a timer/listener. Equally, [[Reset & re-init]] handling is usually not handled properly by such low-level code. These days, it is generally recommended to favor the <code>{{{newapi|bar}}}</code> API instead. Alternatively, you should consider wrapping the low-level APIs using a helper class, which is also the recommended way for supporting multiple different FlightGear binaries.}}

Revision as of 11:45, 9 January 2015

Caution  Using the foo API, it is fairly easy to leak resources by not using the API properly. This happens typically by not keeping track of how many callbacks are registered to be invoked by a timer/listener. Equally, Reset & re-init handling is usually not handled properly by such low-level code. These days, it is generally recommended to favor the bar API instead. Alternatively, you should consider wrapping the low-level APIs using a helper class, which is also the recommended way for supporting multiple different FlightGear binaries.