Ne sovsem ponyatno kak ispravit, kto podskajet?

Question

[Nightmare A]

Pri sborke voznikyet oshibka

In file included from ../deps/source-sdk-2013/mp/src/public/tier0/threadtools.h:15,
                 from ../deps/source-sdk-2013/mp/src/public/filesystem.h:14,
                 from ../src/serverplugin_valve.cpp:29:
../deps/source-sdk-2013/mp/src/public/tier0/threadtools.h: In instantiation of ‘CInterlockedIntT<T>::CInterlockedIntT() [with T = int]’:
../deps/source-sdk-2013/mp/src/public/tier0/threadtools.h:1130:22:   required from here
../deps/source-sdk-2013/mp/src/public/tier0/dbg.h:570:75: error: size ‘-1’ of array is negative
  570 |         #define COMPILE_TIME_ASSERT( pred ) typedef int UNIQUE_ID[ (pred) ? 1 : -1 ]
      |                                                                    ~~~~~~~^~~~~~~~

Kod gde zapis`

//-----------------------------------------------------------------------------
// Macro to assist in asserting constant invariants during compilation

// This implementation of compile time assert has zero cost (so it can safely be
// included in release builds) and can be used at file scope or function scope.
// We're using an ancient version of GCC that can't quite handle some
// of our complicated templates properly.  Use some preprocessor trickery
// to workaround this
#ifdef __GNUC__
	#define COMPILE_TIME_ASSERT( pred ) typedef int UNIQUE_ID[ (pred) ? 1 : -1 ]

Answer 1

[jcmvbkbc]

Ne sovsem ponyatno kak ispravit

смотреть не туда, куда ты смотришь сейчас (не на определение COMPILE_TIME_ASSERT, с ним всё ок, оно такое, чтобы генерировать ошибку компиляции, когда какое-то условие в коде не выполняется), а в строку

../deps/source-sdk-2013/mp/src/public/tier0/threadtools.h:1130

где этот assert сработал, и разбираться с ней.

Comments

[Nightmare A]

Изменил -1 на 0, не кретичным оказалось.

[jcmvbkbc]

Изменил -1 на 0

Вадим Ушаков, нет, это _не решение_. Код в ../deps/source-sdk-2013/mp/src/public/tier0/threadtools.h:1130 рассчитывает на что-то, и считает, что это достаточно важно, чтобы сломать компиляцию, если его ожидания не выполняются. Отключать COMPILE_TIME_ASSERT не глядя туда -- как минимум неразумно.

[Nightmare A]

jcmvbkbc, Но тем не менее проблемой меньше. Новая проблема. https://qna.habr.com/q/1146416

[jcmvbkbc]

тем не менее проблемой меньше.

Вадим Ушаков, это самообман. Проблема как была, так и остаётся, просто вы о ней теперь не знаете.

[Nightmare A]

jcmvbkbc, Поправил исходя из невозможности срабатывания ассерта (assertion) опираясь на предыдущий опыт.

[res2001]

Вадим Ушаков, Прислушайтесь к совету jcmvbkbc
Вы решили проблему при компиляции, но перенесли ее в run time, а там ее отловить еще сложнее и как она проявится - не известно.
К тому же, явно разработчикам софта виднее где у них критичное место в коде и где расставлять ассерты. А вы, походя, нарушаете заложенную в софт логику.

Надо разобраться в причине срабатывания ассерта и устранить ее!
Чтоб получить дальнейшие комментарии приведите, что содержится в участке кода рядом с ../deps/source-sdk-2013/mp/src/public/tier0/threadtools.h:1130