Сообщите компилятору c ++, что аргумент не имеет псевдонима

Question

Одно из больших различий между C / C ++ и Fortran, когда дело доходит до скорости, заключается в том, что прежние языки используют указатели, которые могут иметь псевдонимы, и, следовательно, компилятор должен загружать данные на каждой l oop итерации, в то время как Fortran выделяется. не имеет этой проблемы.

C предлагает ключевое слово restrict, поэтому вы гарантируете компилятору, что указатель не имеет псевдонима. Для c++ стандарт не предлагает эту опцию. Я не хочу использовать расширение поставщика, поскольку меня беспокоит переносимость, но это также важная часть моего приложения. Следовательно, я не буду полагаться на вещи, выходящие за рамки стандартов, когда они являются фундаментальными для моего приложения.

ВОПРОС

Мой вопрос в том, есть ли способ чтобы гарантировать компилятору C ++, что указанный аргумент указателя c не имеет псевдонима. Поможет ли ссылка на C ++ (т.е. наличие ссылок в качестве аргументов, передаваемых по значению, не вариант, поскольку мы имеем дело с очень большими массивами)? Или мне просто написать эти подпрограммы в C и вызывать их из моего приложения на C ++?

  void HEAVY_CALC( double *p1, double *p2 , double *p3, int n1)
  {
     
       for(int i = 0; i<n1 ; i ++ ) {
           p1[i] = Func_1( ) ; 
           p2[i] = Func_2( ) ;  
           p3[i]= Func_3( ) ;  
       }
     
  }

Поскольку указатели здесь могут быть изменены другими, компилятор будет загружать p1, p2, p3 на каждой i итерации. В C, если я добавлю restrict, это будет разрешено. Что произойдет, если я добавлю ссылку вместо указателя, т.е.

    void HEAVY_CALC( double* &p1, double *&p2 , double* &p3, int n1)

Это что-то изменит?

Answer 1

[Is] есть способ [пообещать] компилятору [C ++], что указанный аргумент указателя c не имеет псевдонима [..] без необходимости go за пределами стандартного [?]

Нет, его нет.

Вместо него обычно можно использовать нестандартный __restrict, который был введен в основные инструментальные цепочки чтобы заткнуть именно этот пробел. Переносимость - это не такая , как вы могли подумать, поскольку G CC, Clang и Visual Studio намеренно поддерживают одно и то же ключевое слово.

Предположительно, это нетривиально добавить restrict к языку , даже если такое ключевое слово (как указано выше) было продемонстрировано как полностью реализуемое. Действительно, это уже сделано.