É prático abandonar o STL no desenvolvimento de C ++? [fechadas]

Eu sei que em algumas áreas (indústria de jogos, por exemplo), STL não é recomendado. Então, minha pergunta é: é realmente uma boa prática não usar STL em alguns casos? Se sim, quais são os maiores motivos para não usar o STL moderno do C ++?

• Só consigo pensar em um motivo válido e é realmente raro: tempo real difícil. Muitas coisas na biblioteca padrão alocam memória internamente e isso não é determinístico o suficiente para aplicativos difíceis em tempo real; portanto, elas devem ser evitadas. Esses aplicativos geralmente são bastante simples, embora levem um tempo desproporcional para serem desenvolvidos devido à rigorosa revisão e teste.

• Posso pensar em um motivo inválido, mas muito comum: desenvolvedores que não entendem a complexidade computacional, usam mal o STL e depois culpam a biblioteca.

  O STL geralmente é mais rápido em tempo de execução do que as soluções no estilo C com ponteiros de retorno de chamada ou soluções baseadas em polimorfismo com métodos virtuais ( consulte também a palestra de abertura de Bjarne Stroustrup ). No entanto, quando o desenvolvedor não entende as especificações de complexidade fornecidas e utiliza mal a biblioteca, criando algo como vetor de vetores de alguns objetos complexos (no C ++ 11, porém, isso não é mais um problema!), Causa um problema de desempenho e se defende. com "você vê, os vetores são bastante lentos", pode causar uma percepção de que a biblioteca padrão é lenta. E uma vez que os gerentes tenham essa percepção, ela poderá viver muito tempo na organização.

• Obviamente, você não pode usar nada que a plataforma que você está direcionando não suporta. No entanto, atualmente estamos segmentando quatro plataformas móveis mais comuns (Android, iOS, Bada e WinCE antigo) e usamos a biblioteca padrão e algumas partes do Boost em todas elas.

  Grande parte da biblioteca padrão costumava não ser suportada pela Microsoft no início do WinCE (os iostreams IIRC eram lançados apenas com o Visual Studio 2005), mas era possível usar o STLport muito antes disso. E você pode conseguir isso para compilar qualquer coisa. Então, eu chamaria esse motivo de inválido também.

  Além disso, por um longo tempo, não é "STL", mas sim a Biblioteca Padrão ANSI C ++. É definido pelo mesmo documento padrão que define o próprio idioma. Qualquer coisa que não o suporte realmente não merece ser chamado de C ++.

Eu estou usando STL e impulsionar por muitos anos já. Se eu quisesse abandoná-lo e usar minhas ferramentas personalizadas, a motivação seria:

1. Redução do tempo de compilação (75%). Apenas incluir iostreams pode adicionar 1 milhão de linhas de código ao seu módulo. Sim, cabeçalhos pré-compilados ajudam muito, mas ainda retarda muito a compilação em grandes projetos. A longo prazo, perde muito tempo de quem trabalha nele.
2. Atuação. (25%) O STL é escrito para funcionar geralmente, mas você pode otimizar suas estruturas para funcionarem exatamente como você deseja. Por exemplo, você pode ter estruturas de dados com milhões de cadeias curtas. Pode ser muito mais rápido usar a classe de string personalizada com base no princípio de boost :: small_vector (vetor estático local pequeno de dados, alocação dinâmica apenas para strings maiores), esse tipo de alteração pode fazer com que seções críticas do código funcionem muitas vezes mais rapidamente.

Há um grande motivo válido para não usar a biblioteca de modelos padrão do C ++: uma de suas plataformas de destino não possui uma implementação totalmente em conformidade (ou nenhuma implementação) e você sabe que ela não estará recebendo uma nos próximos anos.

Eu não sei sobre complexidade (eficiência de implementação), mas estou usando contêineres e strings Qt extensivamente em vez dos std e eles funcionam bem. Também acho a implementação Qt de conjuntos e listas mais fácil de usar.

Portanto, pode ser prático abandonar o STL se você puder usar outra biblioteca que atenda às suas necessidades.

Patrick mencionou o motivo de não usar todo o STL, a saber, que sua (s) plataforma (s) não possui um.

Em suma, acho que a questão está faltando. Principalmente não é uma decisão do tipo tudo ou nada, mas uma escolha. Você pode optar por usar os contêineres e algoritmos, mas decide usar algo fora do Lib Std para strings e E / S.

Não é prático, a menos que haja uma forte razão para fazê-lo. Alguns dos motivos pelos quais posso pensar incluem apenas a implementação parcial ou inexistente do STL (ou qualquer outra parte da biblioteca padrão) ou uma limitação de recursos (memória, velocidade da CPU, armazenamento, ...) que você precisa contornar rolando suas próprias ferramentas que aderem ao que você precisa realizar.

Na indústria de jogos, a maioria dos estúdios (até um pouco menores) tem suas bibliotecas e implementações internas de muitas partes da biblioteca padrão, altamente adaptadas para a plataforma de destino e, em alguns casos, como alvo do engnie ou mesmo do próprio jogo. Simplificando, ao desenvolver um jogo para consoles, o hardware é muito limitado pelos padrões atuais. Existem milhares e milhares de linhas de montagem artesanal por um motivo. É muito importante minimizar todos os tipos de pegadas de recursos no seu código, para que o jogo corra mais rápido, o que permite mais conteúdo no mundo do jogo (ou um mundo maior, por exemplo), o que, esperançosamente, resulta em um produto melhor.

"Todo jogo bem-sucedido começa lançando sua própria implementação de lista vinculada".