¿Qué tan incorrecto es hablar de "métodos" C ++ (versus "funciones miembro")?

Yo entiendo que de acuerdo a la especificación C ++ no hay tal cosa como un "método", y algunos (muchos? La mayoría?) Los programadores de C ++ consideran "método" para ser un Java-ismo. Por otro lado, incluso en un foro de C ++ la gente parece hablar sobre métodos sin contracciones. Estoy buscando convenciones conocidas o prácticas comunes con respecto a esta terminología.

Estoy documentando una API que tiene versiones de C ++ y Java. Los desarrolladores realmente mantuvieron los nombres de clase y método / función de miembro iguales entre los dos, presumiblemente por conveniencia en portabilidad y prueba. Debido a esto, parte de lo que debe documentarse sobre estas API se encuentra "por encima" de la elección del idioma; Necesito poder hablar en general sobre Foos y Bars, con sus métodos baz () y mumble () ...

Si hablo de métodos, los programadores de Java lo considerarán natural y, al parecer, los programadores de C ++ probablemente lo entenderán, pero algunos lo considerarán incorrecto. Mi pregunta es: ¿qué tan atroz es esto en la práctica ? ¿Cómo se habla convencionalmente de las funciones miembro de C ++ en contextos "OOP generales", en oposición a los específicos de C ++? ¿Hay una mejor manera de hablar sobre las funciones de los miembros de una manera que no sea incorrecta para ninguno de los idiomas? ("Funciones de miembro" es un poco detallado).

Esta no es una encuesta de opinión; Estoy tratando de determinar si hay convenciones reales o prácticas comunes para abordar este problema.

Soy consciente de esta pregunta , pero se trata de OOP en general y no pregunta sobre idiomas específicos.

¿Por qué no incluye una explicación (como lo hizo en su pregunta) en la parte introductoria de la documentación, por ejemplo, una sección de Convenciones ? Luego, podría explicar que el término "método", como se usa en su documentación, se entiende en el sentido genérico de método (Java), función miembro (C ++), ... ya que la documentación se aplica a todas las implementaciones.

Bueno, no vas a ser ejecutado por eso.

La queja en el mundo de C ++ no es de corrección pedante: es de ambigüedad. Hay tantos tipos diferentes de "métodos" en el desierto dependiendo del dominio del que esté hablando, que muchos de nosotros preferimos apegarnos a la terminología estándar para evitar malentendidos más adelante. Eso significa, aproximadamente, "función estática / [no estática] [pura] virtual / miembro [no virtual] / [libre]".

Si escribe "método" en su documentación, algunos programadores de C ++ pueden quejarse de que no está realmente claro de qué está hablando, o preocuparse de que si no está familiarizado con esta convención de C ++, ¿qué otros se están perdiendo?

Pero estoy seguro de que hay millones de programadores profesionales de C ++ que no tienen ni idea de que esto sea siquiera una cosa. Es un gran mundo antiguo.

No vas a ser ejecutado por eso.

Eiffel los llama Rutinas o Características , C ++ los llama Funciones de Miembros , y (casi) cualquier otro lenguaje OO que se haya creado en toda la historia de la computación, tanto antes como después de que C ++ los llame Métodos , por lo que este último término generalmente debe ser entendido incluso por C ++ (y programadores Eiffel), a menos que realmente nunca han oído hablar de Simula, Smalltalk, Ser, Objective-C, la neolengua, Java, C #, VB.NET, PHP, Python, Ruby, ECMAScript / JavaScript, Scala, CoffeeScript, ...