在C ++中定义短函数名别名的最安全的方法是什么？ [英] What's the safest way to define short function name aliases in C++?

问题描述

假设我在文件 utility.h 中有一个类 Utility ：

  class Utility {
 public：
 static double longDescriptiveName（double x）{return x + 42; } 
}; 
  

然后我发现我使用函数 longDescriptiveName a LOT。所以像一个不负责任的C ++程序员，当我有太多的咖啡，我创建一个新文件 utilitymacros.h 并添加以下内容：

  #define ldn Utility :: longDescriptiveName 
  

现在我在任何 *。cpp 中包含utilitymacros.h $ c> ldn（...）和我的心充满了欢乐，更多的方便是打字3个字母对28。

问题：是否有比 #define 更安全（更恰当）的方式？

我注意到，我必须包括utilitymacros.h包括boost标题后，我显然不喜欢，因为它是一个冲突的迹象（虽然我得到的Boost错误不是很清楚

如果你可能会说这会对代码的可读性产生负面影响，我保证它不会，因为它是一个小集合使用的A LOT的函数。众所周知的一个示例是 stringToInteger 的 stoi 。另一个是 pdf for probabilityDensityFunction 等等。因此，如果我想要执行以下操作， stoi 在我看来更可读：

  int x = stoi（a）+ stoi + stoi（c）+ stoi（d）; 
  

比率：

 code> int x = Utility :: stringToInteger（a）+ Utility :: stringToInteger（b）
 + Utility :: stringToInteger（c）+ Utility :: stringToInteger 
  

或：

 code> int x = Utility :: stringToInteger（a）; 
 x + = Utility :: stringToInteger（b）; 
 x + = Utility :: stringToInteger（c）; 
 x + = Utility :: stringToInteger（d）; 
  

澄清2：编辑器宏

b $ b

我使用Emacs作为我的选择IDE和Kinesis键盘，所以你知道我使用大量的键盘宏，自定义键盘快捷键，以及实际上修改我在编辑器中看到的内容，实际存储在h / cpp文件。但仍然，我觉得简单和视觉可读性（如上所述）在几个选择案例中使用函数缩写真的是我正在寻找的结果（这当然是受到一定程度）。

$代替宏，你可以写 inline 函数，它将调用转发给实际的函数：

  inline double ldn（double x）
 {
 return Utility :: longDescriptiveName（x）; 
} 
  

这比宏确实更安全 p>

Suppose I have a class Utility in a file utility.h:

class Utility {
public:
    static double longDescriptiveName(double x) { return x + 42; }
};

And then I find that I use the function longDescriptiveName(...) a LOT. So like an irresponsible C++ programmer that I am when I've had too much coffee, I create a new file utilitymacros.h and add the following there:

#define ldn Utility::longDescriptiveName

Now I include "utilitymacros.h" in any *.cpp where I use ldn(...) and my heart is filled with joy over how much more convinient it is to type 3 letters vs 28.

Question: Is there a safer (more proper) way of doing this than with #define?

I've noticed that I have to include "utilitymacros.h" after including boost headers, which I obviously don't like because it's a sign of clashes (though the Boost errors I get are not very clear as to what the clash is).

Clarification 1: On Code Readability

In case you might say that this negatively affects code readability, I assure you it does not, because it's a small set of functions that are used A LOT. An example that is widely know is stoi for stringToInteger. Another is pdf for probabilityDensityFunction, etc. So if I want to do the following, stoi is more readable in my opinion:

int x = stoi(a) + stoi(b) + stoi(c) + stoi(d);

Than:

int x = Utility::stringToInteger(a) + Utility::stringToInteger(b)
        + Utility::stringToInteger(c) + Utility::stringToInteger(d);

Or:

int x = Utility::stringToInteger(a);
x += Utility::stringToInteger(b);
x += Utility::stringToInteger(c);
x += Utility::stringToInteger(d);

Clarification 2: Editor Macro

I use Emacs as my IDE of choice and a Kinesis keyboard so you KNOW I use a ton of keyboard macros, custom keyboard shortcuts, as well as actually modifying what I see in the editor vs what's actually stored in the h/cpp file. But still, I feel like the simplicity and visual readability (as argued above) of using a function abbreviation in a few select cases really is the result I'm looking for (this is certainly subject to a degree).

解决方案

Instead of macro, you could write inline function that forwards the call to the actual function:

inline double ldn(double x)
{
   return Utility::longDescriptiveName(x);
}

That is certainly safer than macro.

这篇关于在C ++中定义短函数名别名的最安全的方法是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！