小编LiK*_*Kao的帖子

我需要为一个项目编写的代码来匹配一些样式指南.但是,CDT附带的标准模板与此样式不匹配.特别是头部防护装置的布局不是应该的方式.我查看了模板,对于我的Eclipse,它看起来像这样:

${filecomment}

#ifndef ${include_guard_symbol}
#define ${include_guard_symbol}

${typecomment}
${declarations}

#endif /* ${include_guard_symbol} */

所以我猜这个变量${include_guard_symbol}是在CDT的某个地方设置的,但是有可能在不需要修改CDT本身的情况下改变这个设置吗？

稍微不同但相关的说明:是否可以添加自己的模板,因此您可以使用项目的常规新对话框添加其他类型的新文件(测试用例,专用类等)？

我正在尝试找出postgres可以在事务内部安全处理的内容,但我在postgres手册中找不到相关信息.到目前为止,我发现了以下内容:

• UPDATE,INSERT并且DELTE在事务内部完全支持并在事务未完成时回滚
• DROP TABLE在事务中没有安全处理,并且使用a撤消CREATE TABLE,因此重新创建已删除的表但不重新填充它
• CREATE TABLE 也不是真正的交易,而是与相应的撤消 DROP TABLE

它是否正确？我也找不到关于ALTER TABLE和处理的任何提示TRUNCATE.这些处理方式在交易中是否安全？不同类型的交易和不同版本的postgres之间的处理有区别吗？

我有一个图表,我经常需要知道所有最短的路径(或更确切地说它们的长度).因为我不想重新计算它们,所以我将它们存储在一个简单的数组中,然后从那里检索它们.但是,由于图表可能也会随着时间的推移而改变,因此我必须在给定时间重新计算它们.

目前可能会发生以下变化:

• 将节点和边缘添加到图形中

• 改变边缘的长度

• 添加图表的新边缘

• 删除边缘或删除节点

在所有情况下,所有节点将始终连接,并且所有边缘都具有正权重.该图也是无向的.操作顺序是这样的,所有节点将始终来自图的同一组件.如果在添加其他节点和边之前删除节点或边缘,则图形永远不会分开.

目前我计划只进行更新,然后通过图形结构传播所有更改.但是我不确定如何正确处理这个问题.您将如何尝试实现缓存长度的这些更新.

编辑:

正如你们中的一些人所指出的那样,在添加节点或更改链接时重新计算所有内容可能是必要的.例如,当所有距离通过更新改变时.但是,如果我只是通过图表传播更改并按照dijkstras的方式进行放松,我可能需要多次放松同一个节点,因为我可能不会选择最佳顺序.问题是如何订购放松步骤,所以我尽可能避免多次更新.

如果没有我想到的实际想法,我不确定这有多大意义,但我希望这可以澄清更多.

我有一个问题刚刚提出我的同事,我想知道这个问题最好的git工作流程.

假设我们有两个分支A和B.现在我们foo.c在A和B中都改变了一些文件(),所以当我们将B合并到A时,我们得到合并冲突.现在让我们说一些开发人员搞砸了并离开了分支A一个破碎的状态,错误也在foo.c中,但在一个未合并的行中.

我看到了处理这种情况的一些可能性:

1. 存储挂起的合并,修复A上的问题,提交然后再次应用合并.但是在这一点上,我不确定如何为foo.c所做的更改处理正确的合并策略.破碎的部分可能会影响我所做的一些事情,因此我没有看到解决冲突的明确方法.

2. 撤消合并,修复A上的问题,然后重做整个合并.但是我可能已经解决了其他冲突,所以这可能会失去很多工作.

3. 拿--theirs/ - 我们的文件版本,完成合并,修改更改,樱桃选择已经丢失的更改.然而,我会有两次变化.

4. 其他一些解决方案,我无法想到.

所有这些解决方案让我感到有些不满意.根据我的惯常经验,我可能会选择1,但我绝对不确定.

你会如何处理这种情况？

我有一些代码可以通过使用lambda来大大降低复杂性.但不幸的是,我们必须使用不完全支持C++ 11的编译器,我们不能轻易切换.现在的问题是如何使逻辑尽可能接近具有不可用功能的lambda表达式(即可std::function用,lambda不是).

通常的解决方案是在其他地方定义仿函数,然后在适当的位置使用它:

struct functor{
   functor( type & member ) : m_member( member ) {}
   void operator()( ... ) {...}
   type & m_member;
};

void function() {
   use_functor( functor(...) );
}

我非常习惯这种模式,虽然我不喜欢它.不定义类的主要原因通常是我将在STL中使用仿函数,模板不喜欢函数内联定义的结构.但是在我的情况下,use_functor()函数将是一个普通的方法,所以我可以在函数内部定义函子(每个函子只在一个函数中使用).

void function() {
   struct functor{
      functor( type & member ) : m_member( member ) {}
      void operator()( ... ) {...}
      type & m_member;
   };
   use_functor( functor(...) );
}

这似乎有所改善,但仍然需要更多丑陋的代码,我想要.例如,我想完全摆脱仿函数的名称.我知道如果我只使用一个值,就可以创建一个匿名结构.

void function() {
   struct{
      // functor( type member ) : m_member( member ) {}
      void …

我目前正在查看一些代码,这些代码可以在较新版本的GCC上编译,但不能在较旧版本的GCC上编译.在我来说,我使用的是std::back_inserter到std::copy从一个数据结构中的一些数据,自定义数据结构.typedef value_type & const_reference但是,如果我忘记了此自定义数据结构中的typedef,则无法在GCC 4.4上编译.相同的代码在GCC 4.5上编译并运行正常.

这两个编译器版本之间有什么区别,这使得代码在一个版本上编译而在另一个版本上编译.我猜它与C++ 11的实现有关,这在GCC 4.4中完全不那么完整.decltype我想可能是某个或者另一个新的C++ 11关键字.

这个代码也正确,如果我使用std::back_inserter没有定义const_reference类型？我通常认为,一个必须实现全套的typedef(的value_type,reference,const_reference等),以便为与STL-算法库兼容？或者我可以安全地假设,如果我的代码在这种情况下编译,我不会调用任何危险的东西(例如移动语义,这会破坏我的其他数据结构).

以下程序崩溃时出现错误的glibc双重自由错误:

#include <iostream>
#include <memory>

class foo {
public:
   foo()
   {
      std::cout << "foo constructed" << std::endl;
   }

   ~foo()
   {
      std::cout << "foo destructed" << std::endl;
   }
};

int main() {
   auto f = std::make_shared< foo >();
   std::cout << "Before reset" << std::endl;
   f.reset( f.get() );
   std::cout << "After reset" << std::endl;
   return 0;
}

从这里我得到以下输出(后跟glibc错误):

foo constructed
Before reset
foo destructed
After reset
foo destructed

很明显,在这种情况下,对象被销毁两次.一旦通过重置和一次std::shared_ptr超出范围.这实际上是我所期待的.

但是在cppreference上我找到了以下文本(可在http://en.cppreference.com/w/cpp/memory/shared_ptr/reset找到):

如果*这已经拥有一个对象并且它是拥有它的最后一个shared_ptr,则该对象将通过拥有的删除器销毁,除非ptr是指向它的指针.

在我看来,这实际上说,对象不应该像我的例子那样被销毁.相当令人惊讶,但如果标准这样说.我是以某种方式误读了这个,还是std::shared_ptr我的实施不符合标准？

对于那些问我为什么这样做的人:

我目前正在试图弄清楚如何临时管理由 …

我目前有一些我试图重构的代码.大量异常具有一些针对所有异常的公共代码以及需要针对每种特定异常类型单独处理的一些特定代码.我试图弄清楚如何摆脱每个catch块中的共同部分.一个想法就是这样做:

try {
  /* Stuff that may fail */
} catch( const std::exception & ) {
  /* do common part here */
  try { throw; } 
  catch( const exception1 & ) {
    /* do stuff for exception1 here */
  }
  catch( const exception2 & ) {
    /* do stuff for exception2 here */
  }
}

然而,这让我觉得有些难看.

有没有更好的方法来分解这个共同的逻辑,或者实际上是否有理由完全避免这种尝试？

我目前正在玩模块,看看它们可以以类似的方式用于Haskell类型类.目前我正在尝试使用仿函数类型:

module type Functor =
   sig
      type 'a f
      val fmap : ('a -> 'b) -> ('a f -> 'b f)
   end


module IdFunc =
   struct
      type 'a f  = Id of 'a
      let fmap f = fun (Id a) -> Id (f a)
      let runId  (Id a) = a
   end

let outmap (module F : Functor) av = F.fmap f av

但是在这种情况下outmap输入不正确,编译器会产生错误The type constructor F.f would escape its scope.我知道为什么在这种情况下会导致这个错误,但我不知道如何解决它(因为类型f是参数化的).

我已经尝试使用本地抽象类型:

let outmap (type s) (module …

我目前正在尝试使用GIC或cps指令来理解在ARM体系结构上屏蔽/禁用中断的不同方法之间的关系.

到目前为止我收集了以下内容:

• cps可用于启用/禁用处理器的中断.使用cpsid i禁用发出指令的处理器的所有中断(通过设置cpsr寄存器),并使用cpsie i启用中断.这不会更改中断分配器或CPU接口的任何状态.
• 通过写入中断分配器1中的一个GICD_ICENABLERn寄存器中的相应位,可以屏蔽特定中断.
• 也可以通过在中断分配器中设置无目标来禁用特定中断.

到目前为止这种理解是否正确？

现在我目前还不清楚这些方法是如何相互关联的.我假设如下:

如果使用cpsr寄存器禁止中断,然后发出任何类型的中断信号(无论是否触发电平或边沿),则会通知cpu接口中断(假设它被设置为目标),这会改变状态中断到pending.然后,只要发出cpsie i指令,处理器就会切换到中断处理.

但是,如果通过设置无目标来全局禁用中断,并且发出边沿触发中断信号,则CPU接口将不会更改其状态.因此,如果稍后更改目标,则不会向任何CPU接口发出中断信号(因为触发器不再处于活动状态).这意味着,在这种情况下,边沿触发的中断会丢失.对于电平触发中断,如果中断线仍然有效,则只会向CPU接口发送信号.它是否正确？或者分销商"记住"状态以及是否已发出中断信号,以便在两种情况下中断都会被分发？

现在,如果中断被屏蔽,它将不会再分发到任何CPU接口.但是,在这种情况下,我希望稍后在取消屏蔽时分发中断.