- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
std::string loc =
( {
const char *str = "";
switch (location) {
case Net::HANDSHAKE_TIMEOUT:
str = _(" due to handshake timeout");
break;
case Net::RECV_HANDSHAKE:
str = _(" while waiting for handshake");
break;
case Net::HANDSHAKE_DATA:
str = _(" due to unsupported handshake data");
break;
case Net::HANDSHAKE_AUTH:
str = _(" while parsing handshake data");
break;
case Net::WAIT_DEVICE:
str = _(" while waiting for device");
break;
case Net::TRANSFER_DATA:
str = _(" while transferring data");
break;
}
str;
});
Follow us!
http://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html
const char* get_error(Net::EErrorLocation location)
{
const char *str = "";
switch (location) {
case Net::HANDSHAKE_TIMEOUT:
str = _(" due to handshake timeout");
break;
case Net::RECV_HANDSHAKE:
str = _(" while waiting for handshake");
break;
case Net::HANDSHAKE_DATA:
str = _(" due to unsupported handshake data");
break;
case Net::HANDSHAKE_AUTH:
str = _(" while parsing handshake data");
break;
case Net::WAIT_DEVICE:
str = _(" while waiting for device");
break;
case Net::TRANSFER_DATA:
str = _(" while transferring data");
break;
}
return str;
}
std::string loc = get_error(location);
А я бы все-таки вот так переписал (если мапа/массив не подходит):
1) Линейный поиск. Например в std::vector. O(n)
2) std::map. O(log n)
3) std::unordered_map. O(1)
4) boost::flat_map/Loki::AssocVector. O(log n)
5) Таблица. О(1)
6) ...
?
От каких критериев отталкиваетесь при выборе?
> От каких критериев отталкиваетесь при выборе?
Составляешь список основных операций, которые будут выполняться, пытаешься оценить насколько часто они будут использоваться. На основе этих рассуждений можно выбрать наиболее удобную структуру.
Если есть возможность, имхо, стоит инкапсулировать выбранную структуру данных внутри какого-нибудь более-менее высокоуровневого модуля\класса (игровое поле, фабрика объектов и т.п.), дабы если потом возникнет желание заменить ее на другую, не пришлось перелопачивать код в зависимых модулях\классах.
Массив не подходит, коды не идут подряд. map тем более не нужен для такого маленького числа вариантов, он будет работать медленнее, чем этот switch.
Я не из-за производительности переписал бы, она тут всяко будет одинаковая, да и не сильно она важна в обработчиках ошибок.
Я переписал бы чисто из-за удобства - с return выходит меньше кода, меньше возможности накосячить, легче читать.
>Массив не подходит, коды не идут подряд. map тем более не нужен для такого маленького числа вариантов, он будет работать медленнее, чем этот switch.
Ну собственно поэтому и написал "если мапа/массив не подходит".
Я видел проекты, где система тормозила именно из-за обработчиков ошибок, а именно из-за постоянного падения исключений "до низа стека".
Тоже с подобным проектом встречался... несложный скриптовый двиг, но автор не знал про TryStrToFloat, и юзал вместо него StrToFloat. Причем вызывалась эта гадость на каждый чих - на каждом операторе '+', чтобы выяснить типы аргументов. Вот там замена try { StrToFloat() } на TryStrToFloat() подняла производительность на порядок ;)
Но в нормальных ситуациях, когда все идет по плану, исключение это все-таки исключительная ситуация. Поэтому их оптимизация почти всегда преждевременная.
or
Data.Maybe
or
type?
or
Nullable
Но таки TryStrToFloat это не осилил
float?
или
Nullable<float>
вернуть из TryStrToFloat не осилили.