Em geral, para C # e especificamente para Unity, eu desaconselharia ... mas se você realmente quisesse ou tivesse um bom motivo, poderia.
Em C #, você precisaria se familiarizar com o que é chamado de código inseguro . Assustado ainda?
No Unity, seria necessário ativar o modo de compilação não seguro, para que você não possa usar o web player se planejou isso. Você pode ler mais aqui ou aqui .
Então, basicamente, o C # foi projetado com um Garbage Collector como muitas linguagens de script. A idéia geral é tentar abstrair a noção de gerenciamento de memória para simplificar o desenvolvimento. Você ainda pode acabar com vazamentos de recursos se não anular seus objetos. Sinceramente, não sou um grande apoiador dos GCs e preferiria os métodos RAII , mas este é o mundo em que vivemos.
A maioria dos desenvolvedores de C ++ também concorda, no entanto, que você não deve usar ponteiros diretamente e prefere usar um tipo projetado para RAII, também conhecido como ponteiros inteligentes . Se você estiver em terra C, provavelmente os ponteiros são uma segunda natureza para você, mas mesmo assim isso ajuda a abstraí-los até certo ponto.
Se você usá-los em C #, esteja ciente de que existe um potencial muito real, você pode adicionar vulnerabilidades de segurança ou realmente desagradáveis e difíceis de rastrear bugs. Você também deve ter em mente que deve tomar cuidado para não fazer referência a objetos que podem ser movidos pelo GC. Observe o uso da instrução fixa aqui .
Você também pode usar ponteiros no Unity escrevendo um plug-in nativo . Isso novamente descartará as compilações do webplayer, mas o novo recurso HTML5 funciona com base no emscripten; portanto, se você planejou usá-lo, provavelmente faria isso se tomar cuidado. Os plugins nativos permitem que você estenda o Unity em uma base por plataforma. Eu escrevi um plugin nativo para se comunicar com alguns microcontroladores através de uma conexão serial, por exemplo.
Então, para resumir, você deve definitivamente se perguntar por que quero usar ponteiros em C # no Unity. Se você só quer fazer isso por diversão ... Nocauteie-se.
Edit:
Me desculpe se eu ofendi alguém, pois sei que meus pensamentos sobre a GC não são da opinião popular no momento.
Se você realmente ler minha resposta, notará que eu não chamo o C # de uma linguagem de script. Comparo-o a "muitas linguagens de script", no entanto, no contexto do Unity, é muito usado como uma linguagem de script. É uma espécie de DSL para Unity, se você preferir. Muitas vezes, você o verá referido como Script do Unity nesse contexto (isso se refere principalmente à alternativa Javascript do Unity ao C #). Se você colocar o LLVM em seu pipeline, poderá compilá-lo diretamente no código nativo da plataforma ... então como você o chamaria? Então, na verdade, eu não queria dividir os cabelos aqui.
Muitas ótimas referências à engenharia de software estão cheias de opiniões:
Effective C ++ ,
mais eficaz C ++ ,
C ++ FAQ ,
eficaz C # ,
design ++ Modern C ,
Design Patterns
... E inúmeros outros. Não acho que isso torne os argumentos menos credíveis se forem seguidos de explicações ponderadas.
Eu não estava realmente dizendo: "Nunca use ponteiros!" . Na verdade, eu ainda os uso nus de vez em quando. Eu disse "em geral", como em "prefiro usar código seguro para código não seguro em C #". Há situações em que isso pode ser benéfico, e esse é um dos recursos realmente poderosos do C # para escolher suas ferramentas. O C # ainda permite que você tenha transparência no processo de GC em algum grau, idiomas como o Dart não têm e podem levar a vazamentos de recursos com muita facilidade. Claro, se você é o único desenvolvedor de um projeto pequeno, provavelmente não é um problema. Se você estiver em uma equipe de digamos 10+ com centenas de milhares de linhas de código, pode ser complicado.
Eu simplesmente queria que o leitor tivesse cuidado ao usar ponteiros nus. É como dizer muito cuidado ao trabalhar com eletricidade da rede elétrica. Não estou dizendo que não seja eletricista, apenas se você fizer o movimento errado e não o tratar com respeito, estará morto.
Eu gosto do exemplo dado por Lasse no qual o desempenho pode ter ditado a necessidade.