Здравствуйте, igna, Вы писали:
P>>лучше static_cast... I>Верно, но тогда надо не void*. Я просто хотел идею показать.
не, всё верно, нужен static_cast — указатели "безопастно" кастятся к void* и обратно
static_cast нужен только при касте обратно http://ideone.com/ifP7O
int main()
{
int a;
void *p=&a;
int *b=static_cast<int*>(p);
return 0;
}
Здравствуйте, igna, Вы писали:
I>Это действительно интересно, потому-что хочу задать более конкрентые вопросы. Например, если функция должна разместить массив строк и вернуть его, как ты это делаешь? Например:
В первую очередь я подумаю, подходящее ли это представление для задачи. Потому что либо файл достаточно маленький, чтоб засосать его весь в память в один массив и обрабатывать целиком; либо он достаточно большой, чтобы бить на строки и обрабатывать построчно. И смогу ли я эффективно реализовать такое чтение — я же не знаю количество строк заранее и придётся делать реаллокации, это вообще приемлемо? Может, лучше связанный список строк?
А дальше, если я таки решил, что задача имеет смысл в исходной постановке, то начинают играть паттерны. В частности, паттерн «указатель на массив и счётчик элементов всегда ходят вместе»:
И ещё задокументирую все параметры. Поскольку у нас нет языковых средств для описания политики владения, она должна быть в комментариях.
/**
* Читает файл и возвращает массив его строк.
* @param [in, out] fp Открытый файл. Не закрывается.
* @param [out] prszLines На выходе указывает на массив указателей на строки файла.
* Клиент должен освободить каждую строку и сам массив функцией free().
* @param [out] pcLines На выходе содержит количество строк в массиве.
* @returns код ошибки.
*/
errno_t read_lines(FILE* fp, char** *prszLines, size_t *pcLines);
(Почему половина звёздочек слева от пробела, а половина справа? Потому что использование:
D>А в чем именно _преимущества_ перед плюсами на обычных платформах, где размер кода роли не играет? Тебе по-любому придется часть вещей делать через макродрочество, которое заменяется на шаблоны с небольшим/большим распуханием по коду но делающими ровно тоже самое. Пользоваться своими менеджерами памяти объектов и ты в плюсах можешь.
Теоретически да. Практически же макросов в рабочем коде почти нет. Чтобы добиться похожего результата, в С++ мне приходится писать кучу обёрток или использовать их. Причём явно и понимая как оно может взбрыкнуть и с какими последствиями. С учётом трейтсов и всяких других неявных стратегий это легко вырастает в серьёзную головную боль. В коде на С, я просто пишу код. Так называемое макродрочерство присутствует только в коде yoyo, в целевом коде его нет. Хотя фиг его знает что ты под этим понимаешь.
Фактически преимущество в том, что мне нужно меньше думать на тему как, и больше о том что именно и зачем я делаю. Но в общем-то вопрос привычки. Однако тезис о принципиальном превосходстве C++, и ущербности C — я рассматриваю уже как миф и не более.
Здравствуйте, Alexéy Sudachén, Вы писали:
D>>А в чем именно _преимущества_ перед плюсами на обычных платформах, где размер кода роли не играет? Тебе по-любому придется часть вещей делать через макродрочество, которое заменяется на шаблоны с небольшим/большим распуханием по коду но делающими ровно тоже самое. Пользоваться своими менеджерами памяти объектов и ты в плюсах можешь.
AS>Теоретически да. Практически же макросов в рабочем коде почти нет.
Ну я глянул пару файлов, они были, но в глаза особо не бросались.
AS>Чтобы добиться похожего результата, в С++ мне приходится писать кучу обёрток или использовать их. Причём явно и понимая как оно может взбрыкнуть и с какими последствиями. С учётом трейтсов и всяких других неявных стратегий это легко вырастает в серьёзную головную боль. В коде на С, я просто пишу код. Так называемое макродрочерство присутствует только в коде yoyo, в целевом коде его нет. Хотя фиг его знает что ты под этим понимаешь.
Это не плюсы виноваты, а мейнстримовый стиль написания (спасибо, майерсу и остальным). У него есть плюсы и минусы, основной минус — толстовство, т.е. алаконичность. Меня это не волнует, я печатаю быстро.
AS>Фактически преимущество в том, что мне нужно меньше думать на тему как, и больше о том что именно и зачем я делаю. Но в общем-то вопрос привычки. Однако тезис о принципиальном превосходстве C++, и ущербности C — я рассматриваю уже как миф и не более.
Современные программисты под то и под то уже эволюционировали так, чтобы писать код с примерной одинаковой скоростью и одинаковыми параметрами по качеству, производительности и.т.д. Но для тех, кто не эволюционировал, это более или менее правда. Например, студенческие поделки на ++ более управляемы, отлаживаемы и поддерживаемы, чем то же самое на голых сях.
Здравствуйте, Alexéy Sudachén, Вы писали:
D>>А в чем именно _преимущества_ перед плюсами на обычных платформах, где размер кода роли не играет? Тебе по-любому придется часть вещей делать через макродрочество, которое заменяется на шаблоны с небольшим/большим распуханием по коду но делающими ровно тоже самое. Пользоваться своими менеджерами памяти объектов и ты в плюсах можешь.
AS>Теоретически да. Практически же макросов в рабочем коде почти нет. Чтобы добиться похожего результата, в С++ мне приходится писать кучу обёрток или использовать их.
у тебя макросы запрятаны в yoyo lib, что мешает запрятать обвёртки C++ в либу, или даже использовать готовые?
AS>Причём явно и понимая как оно может взбрыкнуть и с какими последствиями. С учётом трейтсов и всяких других неявных стратегий это легко вырастает в серьёзную головную боль. В коде на С, я просто пишу код. Так называемое макродрочерство присутствует только в коде yoyo, в целевом коде его нет. Хотя фиг его знает что ты под этим понимаешь.
P>у тебя макросы запрятаны в yoyo lib, что мешает запрятать обвёртки C++ в либу, или даже использовать готовые?
std::unique_ptr<MyySuperType> a(new MySuperType);
Как? Особенно если компилятор про C++11 не слышал. Я когда ПРАВИЛЬНЫЙ код на C++ вижу, у меня от этих бла::бла::бла< бла::бла<бла::бла> > в глазах рябит.
P>грабли есть и в yoyo подходе
Грабли есть везде. Даже в жабе и точка-нете бывают утечки памяти и краши. Вопрос в сложности их нахождения и исправления.
P>В C++ никто не заставляет тебя использовать non-intrusive'ные traits.
Э... а дальше переписать STL и бюст? Тебя не смущает что одним только определением функции swap (как-то мы это уже обсуждали) можно принципиально изменить поведение программы. Я уж не говорю про более сложные примеры. Тот же vector<bool> очень чётко это демонстрирует.
Фактически когда ты пишешь модуль на C++ и он у тебя работает и проходит все тесты — это совершенно не значит что при подключении к другому модулю он вдруг не начнёт отплясывать джигу.
Здравствуйте, Alexéy Sudachén, Вы писали:
P>>у тебя макросы запрятаны в yoyo lib, что мешает запрятать обвёртки C++ в либу, или даже использовать готовые? AS>
AS>Как? Особенно если компилятор про C++11 не слышал. Я когда ПРАВИЛЬНЫЙ код на C++ вижу, у меня от этих бла::бла::бла< бла::бла<бла::бла> > в глазах рябит.
у меня от Oj_, YOYO, "_" в начале, рябит не меньше.
namespace alias-ы, using были как минимум с C++98
P>>В C++ никто не заставляет тебя использовать non-intrusive'ные traits.
AS>Э... а дальше переписать STL и бюст? Тебя не смущает что одним только определением функции swap (как-то мы это уже обсуждали) можно принципиально изменить поведение программы. Я уж не говорю про более сложные примеры. Тот же vector<bool> очень чётко это демонстрирует.
а тебя не смущает что одним макросом
#define while(x) /*BOOM Baby!*/
или чем-нибудь менее экстремальным и более реалистичным можно принципиально изменить поведение программы, подключив весёлый header?
AS>Фактически когда ты пишешь модуль на C++ и он у тебя работает и проходит все тесты — это совершенно не значит что при подключении к другому модулю он вдруг не начнёт отплясывать джигу.
также как и в C
у меня при подключении модулей в production, ни разу джигу не танцевал а у тебя?
AS>>Покажи чистый. Буду знать как надо писать правильно. P>ну мне он тоже кажется грязным — но это чисто субъективно, дело привычки, и не относится к языку. P>я бы предпочёл:
Может ещё про расстановку скобочек поспорим. Когда я чужой код читаю, мне вот совершенно пофигу как стоят скобочки, как пишутся имена ... Свой стиль кодирования я здесь обсуждать не буду, могу только сказать что он выработан годами и всё в нём имеет объяснение. Опять же, как с тем for циклом, я пробовал много разных способов. То что я выбрал имеет совершенно конкретные причины. Однако, это мой личный стиль кодирования, и использую я его только в своих проектах.
Тут на самом деле важно другое, код то вообще-то хоть кто нить прочитал?! Я вообще-то ребёнка в садик собирал и потому особенно не проверял что пишу, то что в Array_Push, исходя из здравого смысла, аргумента не хватает так похоже никто и не заметил ))))
Здравствуйте, igna, Вы писали:
I>Здравствуйте, Mystic, Вы писали:
M>>errno обычно установлена соответственно
I>Что значит соответственно? В стандарте 3 значения, как можно определить свои?
В стандарте POSIX больше значений. Среди них ENOMEM, ENOENT, ... Обычно эти значения уже вернут функции libc.
Ровно так же как и в С++. Так что не считается. К тому же легко посмотреть что нарисовал препроцессор, а вот во что шаблоны развернулись....
AS>>Фактически когда ты пишешь модуль на C++ и он у тебя работает и проходит все тесты — это совершенно не значит что при подключении к другому модулю он вдруг не начнёт отплясывать джигу. P>у меня при подключении модулей в production, ни разу джигу не танцевал а у тебя?
Танцевали. Но не в продакшене, а просто при сборке разных модулей. В диапазоне от резкого просада производительности до расстрела памяти. А с учётом что этот код написан на матёром двоеплюсии .... веселуха ещё та. Собственно из за матёрого двоеплюсия оно так и бывает.
Здравствуйте, igna, Вы писали:
AS>>Дык, а как это обычно делается в С++? Используется соответствующий фреймворк/библиотека примитивов. Ну и я то же использую свой фреймворк.
I>
I>Но у меня есть еще один вопрос, как сообщать об ошибке, если файл не прочитался или память не разместилась? Менять сигнатуру функции? Просто вернуть нулевой указатель недостаточно, если нужно различать между двумя причинами ошибки.
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
