Re: C vs. C++
От: Abyx Россия  
Дата: 11.09.12 12:03
Оценка: 8 (3) +4 -1 :))) :)
Здравствуйте, igna, Вы писали:

I>Есть тут кто-нибудь, кто предпочитает C вместо C++ хотя бы и для отдельных проектов?


I>Использую libxml2, это библиотека на C, и решил из интереса попробовать и свой модуль, непосредственно использующий libxml2, написать на C. Сначала оно было как бы неплохо, потом хуже. Возможно с непривычки, а есть здесь те, кто предпочитает C?


на Си пишут либо те у кого нет компилятора С++, либо те кто ниасилил С++
In Zen We Trust
Re: C vs. C++
От: Сыроежка  
Дата: 11.09.12 11:42
Оценка: 1 (1) +2 -5 :))
Здравствуйте, igna, Вы писали:

I>Есть тут кто-нибудь, кто предпочитает C вместо C++ хотя бы и для отдельных проектов?


I>Использую libxml2, это библиотека на C, и решил из интереса попробовать и свой модуль, непосредственно использующий libxml2, написать на C. Сначала оно было как бы неплохо, потом хуже. Возможно с непривычки, а есть здесь те, кто предпочитает C?


С более легкий для использования язык, который позволяет разработчику сосредоточиться на решении прикладных задач, а не копаться в сложностях самого языка. Его использование менее затратно по стоимости. Компиляторы С более совместимы между собой, чем компиляторы С++, то есть обеспечивается лучшая переносимость кода, если конечно речь не идет о "кросс-стандартных" компиляторах.
С значительно реже допускает компиляторам компилировать ill-formed код без соответствующей диагностики, чем С++.
Меня можно встретить на www.cpp.forum24.ru
Re: C vs. C++
От: okman Беларусь https://searchinform.ru/
Дата: 12.09.12 08:10
Оценка: +8
Здравствуйте, igna, Вы писали:

I>Есть тут кто-нибудь, кто предпочитает C вместо C++ хотя бы и для отдельных проектов?


Интересно вот что.
Есть ли такие, кто, владея на хорошем практическом уровне обоими языками, отказался от C++ в
пользу C в силу каких-то адекватных причин, о которых может внятно рассказать ?
Послушать таких людей было бы крайне интересно.

А то ведь принято ругать С++ за усложнизм, за всякие там SFINAE/CRTP/множественное виртуальное
наследование внучатого племянника шаблонного параметра-шаблона, а как послушаешь — оказывается,
что эти люди вообще на плюсах особо не писали и знают о нем только понаслышке.

I>Использую libxml2, это библиотека на C, и решил из интереса попробовать и свой модуль, непосредственно использующий libxml2, написать на C. Сначала оно было как бы неплохо, потом хуже. Возможно с непривычки, а есть здесь те, кто предпочитает C?


Я пишу на C преимущественно код для kernel-mode. Ну еще иногда использую его для переносимых
программных интерфейсов, когда есть вероятность, что их будут вызывать из всяких там Delphi/.NET, а
использовать COM слишком дорого. Но вообще, программировать на C считаю неудобным.
В основном из-за отсутствия RAII. Тот, кто не знает, что такое RAII — не знает C++ и объяснять
ему плюсы бесполезно. В отсутствие RAII приходится постоянно следить за тем, кто зовет add_ref, а
кто release, кто инкрементировал счетчик на входе, а кто декрементировал на выходе, кто
занял дескриптор, а кто освободил, и так далее. Добавляешь новую ветку кода — будь добр, проследи,
чтобы и в ней была правильная очистка ресурсов. Удаляешь ветку — тоже проследи. Проследи, чтобы
не было двойного освобождения ресурсов. И так далее, до бесконечности. В C это очень утомляет, а
существующие решения на всяких там лонгджампах выглядят костыльно (и, по сути, костылями и являются).
Во время переработки кода очень легко внести ошибку. Правильно приготовленный C++ избавляет от
подобных проблем — всем заведует RAII и все счастливы, а накладных расходов нет. И код чище.

Я C++ бы выучил только за то,
что в нем присутствует RAII.
Re[2]: C vs. C++
От: SilentNoise  
Дата: 11.09.12 13:17
Оценка: +3 -3 :)
Здравствуйте, Piko, Вы писали:

Потому что очень много низкокачественных С++ программистов (перешедших с С), которые
верят в то, что компилятор соптимизирует их монструозные конструкции на шаблонах,
верят в const, строгую типизацию и т.п.
думают что С++ это ООП язык,
могли не осилить 20 лет назад указатели и этот опыт имеет их до сих пор.
В результате, когда этот сброд слышит что-то — они бездумно используют С++.
Re[2]: C vs. C++
От: SilentNoise  
Дата: 11.09.12 12:42
Оценка: +2 -4
Здравствуйте, MasterZiv, Вы писали:

MZ>Я бы только один проект писал на С -- ядро линукса. Остальные -- только на

MZ>плюсах. С так ужо убого выглядит, что просто морально нельзя его терпеть.
Вы это так говорите, будто С++ выглядит менее убого.
Re[9]: Идею поняли
От: Qbit86 Кипр
Дата: 11.09.12 13:15
Оценка: +2 :))) :)
Здравствуйте, SilentNoise, Вы писали:

SN>Виноват, совсем запутался :) Да, надо 3 звездочки.

SN>Но идею, думаю, Вы поняли.

Используй Си
@
Считай звёздочки
Глаза у меня добрые, но рубашка — смирительная!
Re[3]: C vs. C++
От: Centaur Россия  
Дата: 11.09.12 14:52
Оценка: 4 (3) +2
Здравствуйте, igna, Вы писали:

I>Это действительно интересно, потому-что хочу задать более конкрентые вопросы. Например, если функция должна разместить массив строк и вернуть его, как ты это делаешь? Например:


В первую очередь я подумаю, подходящее ли это представление для задачи. Потому что либо файл достаточно маленький, чтоб засосать его весь в память в один массив и обрабатывать целиком; либо он достаточно большой, чтобы бить на строки и обрабатывать построчно. И смогу ли я эффективно реализовать такое чтение — я же не знаю количество строк заранее и придётся делать реаллокации, это вообще приемлемо? Может, лучше связанный список строк?

А дальше, если я таки решил, что задача имеет смысл в исходной постановке, то начинают играть паттерны. В частности, паттерн «указатель на массив и счётчик элементов всегда ходят вместе»:

… read_lines(FILE* fp, char** *rszLines, size_t *pcLines);

(да, венгерка! Низкоуровневым языкам — низкоуровневые приёмы)

Возвращать буду, естественно, код ошибки:

errno_t read_lines(FILE* fp, char** *rszLines, size_t *pcLines);


И ещё задокументирую все параметры. Поскольку у нас нет языковых средств для описания политики владения, она должна быть в комментариях.

/**
 * Читает файл и возвращает массив его строк.
 * @param [in, out] fp Открытый файл. Не закрывается.
 * @param [out] prszLines На выходе указывает на массив указателей на строки файла.
 *                        Клиент должен освободить каждую строку и сам массив функцией free().
 * @param [out] pcLines На выходе содержит количество строк в массиве.
 * @returns код ошибки.
 */
errno_t read_lines(FILE* fp, char** *prszLines, size_t *pcLines);


(Почему половина звёздочек слева от пробела, а половина справа? Потому что использование:
char** rszLines;
size_t cLines;
switch (read_lines(fp, &rszLines, &cLines))
{
…
}
)
Re[2]: C vs. C++
От: Сыроежка  
Дата: 11.09.12 12:41
Оценка: 1 (1) +1 :)))
Кроме того многие компиляторы С++ имеют собственные расширения языка, которые меняют семантику стандартных конструкций. Если вы используете, например, MS VC++ или Embarcadero C++ Builder, то вы будете спотыкаться на каждом шаге, не зная, то ли вы имеете дело с расширением языка компилятора, то ли это обыкновенный баг компилятора, то ли вы сами что-то делаете не так. Кроме того недостаточно высокая квалификация программиста ( я не имею в виду низкую квалификацию, а именно недостаточно высокую, что характерно для подавляющего числа программистов С++) может привести к тому, что в коде будет использоваться семантически неверная конструкция с неопредленным поведением, которая при переносе кода на другую платформу может привести к серьезным последсвтиям в смысле затрат по устранению этого изъяна.
Кроме того программы С++ сильно зависят от начальных правильных проектных решений, заложенных в них. Если начальные проектные решения были неправильны, то изменить их на более поздней стадии разработки программы бывает очень сложно, а порой даже просто невозможно. У меня сейчас нет ссылки под рукой, но насколько я помню, число незавершенных проектов на С++ существеннно выше числа незавершенных проектов на С.
Разработка проекта на С++ требует значительно больше усилий от программистов, чем на С. Обычно в группе имеются программсты с разной квалийикацией, с разным знанием специфических особеннностей того или иного компилятора, а это приводит к тому, что программистам приходится тратить много времени на выявление некорректных конструкций при ревью кода. То есть много времени тратится на выяснение, правильный ли это код или нет. И то, что код на С++ успешно компилируется, совершенно не означает, что он корректный, а поведение программы опредленное.
Все это делает проекты на С++ более затратными.
Меня можно встретить на www.cpp.forum24.ru
Re[3]: C vs. C++
От: MasterZiv СССР  
Дата: 11.09.12 13:06
Оценка: 1 (1) +4
On 09/11/2012 04:42 PM, SilentNoise wrote:

> MZ>Я бы только один проект писал на С -- ядро линукса. Остальные -- только на

> MZ>плюсах. С так ужо убого выглядит, что просто морально нельзя его терпеть.
> Вы это так говорите, будто С++ выглядит менее убого.

Ходи, ходи отседова...
Posted via RSDN NNTP Server 2.1 beta
Re[8]: C vs. C++
От: Трололоша  
Дата: 11.09.12 19:01
Оценка: 4 (2) +2
Здравствуйте, Alexey Sudachen, Вы писали:

AS>в С++ мне приходится писать кучу обёрток или использовать их.

А тут тебе мало того что пришлось написать свой FW так ещё и приходится его использовать. Тока в С++ scoped ptr пишется в любой момент с нуля десятком строк, а твой FW с нуля мало того что задолбёшься писать так ещё и отладить это всё сильно геморнее.

AS> Причём явно и понимая как оно может взбрыкнуть и с какими последствиями.

А твоё что, взбрыкнуть не может нигде? По мне так как раз твой FW надо очень осторожно применять, потому как хз что там у тебя за мины разложены.

AS> С учётом трейтсов и всяких других неявных стратегий

А не надо быть укушенным александреску. На С++ можно писать просто.

AS>Так называемое макродрочерство присутствует только в коде yoyo, в целевом коде его нет. Хотя фиг его знает что ты под этим понимаешь.

Вызовы трёхэтажных макросов в прикладном коде.

AS>Фактически преимущество в том, что мне нужно меньше думать на тему как, и больше о том что именно и зачем я делаю.

AS> Но в общем-то вопрос привычки.
Ты привык колбасить на своём FW, потому и думать тебе о нём не надо — ты знаешь как оно работает.
Мы пишем на С++ и уже давно на уровне подсознания знаем как оно работает.
... << RSDN@Home >>
Да, йа зелёный тролль!
Re: C vs. C++
От: MasterZiv СССР  
Дата: 11.09.12 11:41
Оценка: +1 -3
> Есть тут кто-нибудь, кто предпочитает C вместо C++ хотя бы и для отдельных проектов?

Я бы только один проект писал на С -- ядро линукса. Остальные -- только на
плюсах. С так ужо убого выглядит, что просто морально нельзя его терпеть.
Posted via RSDN NNTP Server 2.1 beta
Re[5]: C vs. C++
От: SilentNoise  
Дата: 11.09.12 13:03
Оценка: -2 :))
Здравствуйте, igna, Вы писали:

I>Ты третью звездочку точно не забыл?

Чтобы был указатель на указатель на указатель на массив строк? we need to go deeper Можно, а зачем?


int get_lines_as_strings(FILE *, char **ptr);

...

char *strings; // указатель на первый (нулевой) элемент массива строк.
int numlines = get_lines_as_strings(f, &strings);
Re[7]: C vs. C++
От: uzhas Ниоткуда  
Дата: 11.09.12 13:11
Оценка: +3 :)
Здравствуйте, SilentNoise, Вы писали:

SN>Please disregard... конечно же вот так:


int get_lines_as_strings(FILE *, char **ptr);

снова фейл
классическая проблема Си: борьба со звездочками
Re[7]: C vs. C++
От: OZ1 Россия  
Дата: 12.09.12 14:49
Оценка: -1 :)))
Здравствуйте, A13x, Вы писали:

A>Здравствуйте, MasterZiv, Вы писали:



>>> С++ прост как палка.


A>По сравнению с чем?

A>По сравнению с С или Java это очень сильно не так, говорю исходя из собственного опыта, особенно вспоминая мой давний опыт windows программирования когда приходилось использовать COM компоненты в MFC приложении.

Вот как раз COM — это лучшее и самое чистое, что когда либо сделали из C++. Если посмотреть, что там осталось от C++, то какбы наводит на некоторые мысли. Вместе с тем, что тот же COM сервер можно и на C сделать.
Re: C vs. C++
От: Piko  
Дата: 11.09.12 13:12
Оценка: 1 (1) -2
Здравствуйте, igna, Вы писали:

I> Возможно с непривычки, а есть здесь те, кто предпочитает C?


http://www.rsdn.ru/forum/flame.comp/4784642.1.aspx
Автор: Piko
Дата: 19.06.12

Потому что очень много низкокачественных C++ программистов (перешедших с C), которые
верят в то, что C быстрее чем C++,
верят в void* и т.п.,
думают что C++ это раздутые OO-иерархии,
могли обжечься 20 лет назад об C++ и этот опыт имеет их до сих пор.
В результате, когда этот сброд слышит embedded, fast, system, kernel — они бездумно используют C.

На сегодняшний день я вижу только следующие места когда можно обоснованно использовать C, а не C++ :
1) Отсутствие компилятора C++
2) В API (причём это не сам C, а только C-style interfaces)
3) В распоряжении есть только программисты знающие C, но не C++
4) Необходимость ковыряться в уже написанном на C проекте

Re[6]: What's up, Doc?
От: Don Reba Канада https://stackoverflow.com/users/49329/don-reba
Дата: 11.09.12 13:25
Оценка: 1 (1) +1 :)
Здравствуйте, Qbit86, Вы писали:

Q>Какой ещё «дог»?


http://www.urbandictionary.com/define.php?term=dawg
Ce n'est que pour vous dire ce que je vous dis.
Re[4]: C vs. C++
От: SilentNoise  
Дата: 11.09.12 13:29
Оценка: :)))
Здравствуйте, Piko, Вы писали:

P>таки соптимизирует! http://eigen.tuxfamily.org/index.php?title=Benchmark

И не раздует при этом бинарник до космических размеров?

P>я хз что ты понимаешь под "ООП язык".

В гугл

здесь и ниже по ветке — взаимная пикировка с переходом на личности и прочим злом удалена. — Кодт
Re[10]: C vs. C++
От: Piko  
Дата: 11.09.12 15:49
Оценка: +3
Здравствуйте, Alexéy Sudachén, Вы писали:

P>>у тебя макросы запрятаны в yoyo lib, что мешает запрятать обвёртки C++ в либу, или даже использовать готовые?

AS>
AS>std::unique_ptr<MyySuperType> a(new MySuperType);
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, ни разу джигу не танцевал а у тебя?
Re[11]: C vs. C++
От: Alexéy Sudachén Чили  
Дата: 14.09.12 12:11
Оценка: -2 :)
AS>>Обработка ошибок зависит не от этого кода, а от того где и как он используется. Её вообще может и не быть как таковой.
MTD>Напиши код который открывает файл, читает и корректно его закрывает с учетом возникновения ошибок, тогда и поговорим.

На этом форуме уже писал и не раз, лично тебе чего-то доказывать смысла не вижу (как и кому бы то ни было вообще). Мне вот честно глубоко пофигу чего ты там считаешь относительно моего кода. Моё дело показать что можно и так, а уж нужно ли это ещё кому-то — мне глубоко фиолетово.

AS>>Консистентное с точки зрения контейнера, языка или контекста его использования?

MTD>С любой точки зрения.

Ошибаешься.

MTD>Напиши код который открывает файл, читает и корректно его закрывает с учетом возникновения ошибок, тогда и поговорим.


Вот только я не вижу смысла с тобой говорить. Кто ты такой — архитектор всия вселенной?! На твои вопросы по делу я ответил, играть же в игру 'а докажи' — мне не интересно. Более того, как бы очевидно как это работает, если тебе не, то может стоит немного поуменьшить ЧСВ?
Re[7]: C vs. C++
От: Piko  
Дата: 11.09.12 14:10
Оценка: 6 (1) +1
Здравствуйте, SilentNoise, Вы писали:

SN>>>>>Потому что очень много низкокачественных С++ программистов (перешедших с С), которые

SN>>>>>верят в то, что компилятор соптимизирует их монструозные конструкции на шаблонах,
P>>>>таки соптимизирует! http://eigen.tuxfamily.org/index.php?title=Benchmark
P>>>>и оптимизирует уже как минимум 14 лет http://www.osl.iu.edu/publications/prints/1998/siek98%3A_siamoo.pdf
P>>>>таки соптимизирует! http://eigen.tuxfamily.org/index.php?title=Benchmark
SN>>>И не раздует при этом бинарник до космических размеров?
P>>как минимум не больше рукопашная кодогенерация
P>>http://www.osl.iu.edu/publications/prints/1998/siek98%3A_siamoo.pdf
P>> As an example, to provide basic functionality for selected sparse matrix
P>> types, the NIST implementation of the Sparse BLAS [18] contains over 10,000 routines and
P>> a code generation system.
SN>Ага, но экспоненциально больше чем использование void* и функции.

во-первых, какие-либо тесты будут? или только "экспоненциальный" трёп? а то ведь это место скользкое — push/pop, frame stuff и т.п. может стоит больше по размеру чем инлайн малюсенькой функции.
во-вторых, мы вроде про оптимизацию говорим, и видимо по скорости, не? Ну а если нужна оптимизация по размеру — то и она получится лучше и безопасней на C++
Re[5]: C vs. C++
От: Трололоша  
Дата: 11.09.12 19:01
Оценка: 3 (1) +1
Здравствуйте, SilentNoise, Вы писали:

SN>Не будет, ибо те средства абстракции, которые есть в С++ но отсутствуют в С, сделаны так монструозно, что приносят больше проблем чем профита.


Автоматический вызов деструктора сделан пц как монструозно.
Ну а шаблонный враппер над указателем это просто нереальный монстр, да!
Жги ещё!
... << RSDN@Home >>
Да, йа зелёный тролль!
Re[9]: C vs. C++
От: Трололоша  
Дата: 11.09.12 19:01
Оценка: 3 (1) +1
Здравствуйте, SilentNoise, Вы писали:

SN>Виноват, совсем запутался Да, надо 3 звездочки.

SN>Но идею, думаю, Вы поняли.

Идея тут на самом деле простая: надо брать С++ и не морочить себе голову этими звёздочками и тем, как с ними потом работать.
... << RSDN@Home >>
Да, йа зелёный тролль!
Re[10]: C vs. C++
От: Трололоша  
Дата: 11.09.12 19:01
Оценка: 3 (1) +1
Здравствуйте, Alexey Sudachen, Вы писали:

AS>Как? Особенно если компилятор про C++11 не слышал.

И что? На стандарте 2003го года вполне можно писать вменяемый код.

AS>Я когда ПРАВИЛЬНЫЙ код на C++ вижу, у меня от этих бла::бла::бла< бла::бла<бла::бла> > в глазах рябит.

А с чего ты взял что то, что ты видел это был правильный код?
... << RSDN@Home >>
Да, йа зелёный тролль!
Re: C vs. C++
От: Vain Россия google.ru
Дата: 11.09.12 19:17
Оценка: 2 (1) :)
Здравствуйте, igna, Вы писали:

I>Есть тут кто-нибудь, кто предпочитает C вместо C++ хотя бы и для отдельных проектов?

А я вот где-то годик под чистыми сями писал. Сначало думал что буду плеваться, но был приятно удивлён обратной стороной сей. Можно сказать что за это время буквально часть мозга высвободилась из языкового оверхеда с++ под прикладные задачи. Ни шаблонов тебе, ни перегрузок, ни вложенных классов/скопов, ни виртуальных функций, ни исключений, ни горбатых стримов, ничего, красота..
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[3]: C vs. C++
От: SilentNoise  
Дата: 11.09.12 12:54
Оценка: -1 :)
Здравствуйте, igna, Вы писали:

I>Это действительно интересно, потому-что хочу задать более конкрентые вопросы. Например, если функция должна разместить массив строк и вернуть его, как ты это делаешь? Например:

I>или еще как?

Строго говоря, ни один из ваших вариантов не возвращает массив строк.
Я бы сделал как-то так:

int get_lines_as_strings(FILE *, char **ptr); // возвращает количество строк и устанавливает указатель на массив указателей на строки.
Re[6]: C vs. C++
От: SilentNoise  
Дата: 11.09.12 13:06
Оценка: -1 :)
Здравствуйте, SilentNoise, Вы писали:

Please disregard... конечно же вот так:

int get_lines_as_strings(FILE *, char **ptr);

...

char **strings;
int numlines = get_lines_as_strings(f, strings);
Re[8]: C vs. C++
От: SilentNoise  
Дата: 11.09.12 13:09
Оценка: :))
Здравствуйте, igna, Вы писали:

I>И каким будет значение strings после вызова get_lines_as_strings?

Виноват, совсем запутался Да, надо 3 звездочки.
Но идею, думаю, Вы поняли.
Re[4]: C vs. C++
От: SilentNoise  
Дата: 11.09.12 13:11
Оценка: :))
Здравствуйте, MasterZiv, Вы писали:

MZ>А теперь прочитай всё это, заменив С++ на С и наоборот.

MZ>Будет тоже всё верно!
Не будет, ибо те средства абстракции, которые есть в С++ но отсутствуют в С, сделаны так монструозно, что приносят больше проблем чем профита.
Re[3]: C vs. C++
От: Piko  
Дата: 11.09.12 13:24
Оценка: +1 -1
Здравствуйте, SilentNoise, Вы писали:

SN>Потому что очень много низкокачественных С++ программистов (перешедших с С), которые

SN>верят в то, что компилятор соптимизирует их монструозные конструкции на шаблонах,

таки соптимизирует! http://eigen.tuxfamily.org/index.php?title=Benchmark
и оптимизирует уже как минимум 14 лет http://www.osl.iu.edu/publications/prints/1998/siek98%3A_siamoo.pdf

SN>верят в const, строгую типизацию и т.п.


hallelujah!

SN>думают что С++ это ООП язык,


я хз что ты понимаешь под "ООП язык".
некоторые думают что ООП — это значит отсутствие free functions

SN>могли не осилить 20 лет назад указатели и этот опыт имеет их до сих пор.


о да! забавно слышать это от осилившего перца http://www.rsdn.ru/forum/cpp/4888436.1.aspx
Автор: SilentNoise
Дата: 11.09.12
Re[5]: C vs. C++
От: MasterZiv СССР  
Дата: 11.09.12 13:48
Оценка: +2
> Не будет, ибо те средства абстракции, которые есть в С++ но отсутствуют в С,
> сделаны так монструозно, что приносят больше проблем чем профита.

Чё? чего сретства ? С++ прост как палка.
Posted via RSDN NNTP Server 2.1 beta
Re[7]: C vs. C++
От: Alexéy Sudachén Чили  
Дата: 12.09.12 18:06
Оценка: :))
AS>>простота использования ставит C++ в какое-то непонятное положение
MTD>Заметно. И это мы еще до обработки ошибок не дошли (ее тут нет), когда окажется, что твой код сыпется как карточный домик.

MTD>
MTD>typedef std::vector<std::string> string_list;
MTD>void read_lines(std::istream& from, string_list& to)
MTD>    while (std::getline(from, buf))
MTD>


И что здесь она есть? Особенно при условии что я как-то не вижу включения обработки исключений для плюсовых потоков. Какое кстати состояние контейнера to в случае если исключения таки включены, и где-то по ходу произошла ошибка чтения? Можно ещё поинтересоваться — STL даёт возможность прочитать строчки с сети или с выхлопа чайлд-процесса? Или надо к нему ещё небольшого такого монстрика на выручку позвать?

MTD>
MTD>YO_ARRAY *Oj_Get_Lines(void *file) {
MTD>  while ((  S = Oj_Read_Line(file) )) Array_Push(__Retain(S));
MTD>  return arr;
MTD>


Ошибки здесь превосходно обрабатываются. Код автоматически устойчив к исключениям.
Re[21]: C vs. C++
От: Piko  
Дата: 14.09.12 23:37
Оценка: +2
Здравствуйте, Alexéy Sudachén, Вы писали:

P>>>я до этого не пользовался им

P>>кстати, продолжая рвать шаблон, я не пользуюсь ни facebook'ом, ни вконтакте, и ни разу в жизни не создавал там аккаунты.
P>>я что-то делаю не так?
AS>Не знаю. У меня есть, и бывают весьма и весьма полезны. Но у меня и интересы выходят за круг C++ и копьютеров, а люди с которыми я общаюсь живут по всему шарику. Может быть в этом дело?

с нужными людьми с поверхности шарика, общаюсь по e-mail, skype, и иногда linkedin — да.,
потребности в facebook'ах не испытываю
с теми кто в зоне часовой досягаемости, предпочитаю встречаться в реале.
Re[12]: C vs. C++
От: Piko  
Дата: 11.09.12 14:49
Оценка: 6 (1)
Здравствуйте, 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;
}
Re[3]: C vs. C++
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 11.09.12 13:41
Оценка: 1 (1)
Здравствуйте, igna, Вы писали:

I>Здравствуйте, Alexéy Sudachén, Вы писали:


AS>>Встречный вопрос, это для разжигания флейма, или действительно интересно?


I>Это действительно интересно, потому-что хочу задать более конкрентые вопросы. Например, если функция должна разместить массив строк и вернуть его, как ты это делаешь?


Зависит от того, где и как будет использоваться. Предложенные варианты вполне годятся. Равно как и

struct string_list
{
};

int string_list_create(struct string_list * restrict result, FILE * f);
void string_list_destroy(struct string_list * restrict this);
const char * string_list_next(struct string_list * restrict this);
...
Re[3]: C vs. C++
От: denisko http://sdeniskos.blogspot.com/
Дата: 11.09.12 13:51
Оценка: 1 (1)
Здравствуйте, igna, Вы писали:

I>Здравствуйте, Alexéy Sudachén, Вы писали:


AS>>Встречный вопрос, это для разжигания флейма, или действительно интересно?


I>Это действительно интересно, потому-что хочу задать более конкрентые вопросы. Например, если функция должна разместить массив строк и вернуть его, как ты это делаешь? Например:


I>
I>int get_lines_as_strings(FILE *, char const *const **); // возвращает количество строк
I>


I>или


I>
I>struct strings {
I>    int num; // количество строк
I>    char const *const *str;
I>};

I>void get_lines_as_strings(FILE *, struct strings *);
I>


I>или


I>
I>struct strings {
I>    int num; // количество строк
I>    char const *const *str;
I>};

I>struct string get_lines_as_strings(FILE *);
I>


I>или еще как?

Если писать быстро
void get_lines_as_strings(FILE *,char***);
char** get_lines_as_strings(FILE *);
strings* get_lines_as_strings(FILE *);

Если писать острожно и пытаться управлять памятью
void get_lines_as_strings(FILE *,char**, Allocator* al, int maxLength);

Можно писать как Алексей показал c общим менеджером объектов (компромисс лаконичного и разумного способов имхо)
char** get_lines_as_strings(FILE *)
{
//вызываем общий менеджер, управляющий память 
GodStruct* god = callMeGod();
char** result  = (char**)godAlloc();
...
result[i] = godPush(stringRead);
...
}

Можешь передавать свой (имхо наиболее разумный способ)
char** get_lines_as_strings(FILE *, GodStruct*)
{
}
<Подпись удалена модератором>
Re[5]: C vs. C++
От: denisko http://sdeniskos.blogspot.com/
Дата: 11.09.12 14:22
Оценка: 1 (1)
Здравствуйте, igna, Вы писали:

I>Здравствуйте, denisko, Вы писали:


I>Спасибо, а как сообщать об ошибке, если файл не прочитался или память не разместилась?

Поскольку я считаю, что ошибки априори достаточно редки то пишу так

backupState(god);
char** result = get_lines_as_strings(FILE * file, GodStruct* god, int* errorCode);
if(result == NULL)
{
  if(errorCode == FILE_READ_ERROR)
    reportFileNotRead(..);
  else if(errorCode == MEMORY_ALLOC_ERROR)
  {
    rollbackState(god);
    reportMemoryAllocError(god);
  }
}

Многие используют исключения на longjumpax, некоторые меняют местами errorCode и result
<Подпись удалена модератором>
Re[5]: C vs. C++
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 11.09.12 14:32
Оценка: 1 (1)
Здравствуйте, igna, Вы писали:

I>Но у меня есть еще один вопрос, как сообщать об ошибке, если файл не прочитался или память не разместилась? Менять сигнатуру функции? Просто вернуть нулевой указатель недостаточно, если нужно различать между двумя причинами ошибки.


errno обычно установлена соответственно
Re[7]: C vs. C++
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 11.09.12 14:41
Оценка: 1 (1)
Здравствуйте, igna, Вы писали:

I>Здравствуйте, Alexéy Sudachén, Вы писали:


AS>>Бросить разные исключения?


I>В C?


В C если кровь из носу нужны исключения, то обычно используется long jump. Там можно пробросить код при желании. Примерно так:

struct context * restrict ctx = allocate_context;
int error_code = setjmp(ctx->jmp_on_error);
if (error_code == 0)
  perform_context_caclulation(ctx);

if (error_code)
{
  printf("Was error %d\n", error_code);
  // Мы можем хранить расширенную информацию в самом контексте
  // printf("Message %s\n", ctx->error_msg);
}

free_context(ctx);
Re[10]: C vs. C++
От: Piko  
Дата: 11.09.12 14:43
Оценка: 1 (1)
Здравствуйте, igna, Вы писали:

SN>>Если тебе не очевидно, что при использовании шаблонов для эмуляции полиморфизма они будут развернуты с дублированием кода, то тут нечего добавить.

I>Вроде бы этого можно избежать, нет?:
I> void* f(void*);

тсс, ты главное не говори ему про Technical Report on C++ Performance

I> T* f(T* p) { return reinterpret_cast<T*>(impl_.f(p)); }


лучше static_cast...
Re[13]: C vs. C++
От: Piko  
Дата: 11.09.12 14:51
Оценка: 1 (1)
Здравствуйте, igna, Вы писали:

P>>и только при касте обратно, в T*

I>Так у меня только обратно и есть, нет?

да, но должен быть static_cast, иначе насколько я помню — UB
Re[7]: C vs. C++
От: night beast СССР  
Дата: 11.09.12 16:20
Оценка: 1 (1)
Здравствуйте, igna, Вы писали:

I>
NB>>1. array_type * get_lines_as_strings ( istream&, error_info * error = 0 );
I>


I>Что там такое после error похожее на значение аргумента по умолчанию?


он и есть
делается на макросах, но это не принципиально.
Re[5]: C vs. C++
От: night beast СССР  
Дата: 11.09.12 16:28
Оценка: 1 (1)
Здравствуйте, igna, Вы писали:

I>Но у меня есть еще один вопрос, как сообщать об ошибке, если файл не прочитался или память не разместилась? Менять сигнатуру функции? Просто вернуть нулевой указатель недостаточно, если нужно различать между двумя причинами ошибки.


по поводу ошибок почитай еще:
part 1
part 2
part 3
Re[8]: C vs. C++
От: MTD https://github.com/mtrempoltsev
Дата: 13.09.12 16:21
Оценка: 1 (1)
Здравствуйте, Alexéy Sudachén, Вы писали:

AS>В любой более менее сложной библиотеке есть свой словарь и свои концепции.


Хорошей библиотекой легко пользоваться правильно и тяжело неправильно. В твоем коде боюсь только ты разбираешься, да и то сомнительно — вон сколько сам ошибок понаделал
Re[4]: C vs. C++
От: igna Россия  
Дата: 11.09.12 12:59
Оценка: +1
Здравствуйте, SilentNoise, Вы писали:

SN>int get_lines_as_strings(FILE *, char **ptr); // возвращает количество строк и устанавливает указатель на массив указателей на строки.


Ты третью звездочку точно не забыл?
Re[7]: C vs. C++
От: igna Россия  
Дата: 11.09.12 13:08
Оценка: +1
Здравствуйте, SilentNoise, Вы писали:

SN>int get_lines_as_strings(FILE *, char **ptr);

SN>...

SN>char **strings;
SN>int numlines = get_lines_as_strings(f, strings);


И каким будет значение strings после вызова get_lines_as_strings?
Re[3]: C vs. C++
От: Alexéy Sudachén Чили  
Дата: 11.09.12 13:10
Оценка: -1
AS>>Встречный вопрос, это для разжигания флейма, или действительно интересно?
I>Это действительно интересно, потому-что хочу задать более конкрентые вопросы. Например, если функция должна разместить массив строк и вернуть его, как ты это делаешь? Например:
I>или еще как?

Дык, а как это обычно делается в С++? Используется соответствующий фреймворк/библиотека примитивов. Ну и я то же использую свой фреймворк. Возвращаю массив строк.

Условно говоря —

YO_ARRAY *Oj_Get_Lines(void *file) {
  YO_ARRAY *arr = Array_Pchars();
  char *S;
  while ((  S = Oj_Read_Line(file) )) Array_Push(__Retain(S));
  return arr;
}

YO_ARRAY *arr = Oj_Get_Lines(Cfile_Open("file","r"));

или

char lines[] = "line1\nline2\nline3";
YO_ARRAY *arr = Oj_Get_Lines(Memory_As_File(lines,strlen(lines)));

или с любого объекта который реализует протокол чтения строки.



Короче, https://github.com/alexeysudachen/libyoyo — там всё написано.
Re[8]: C vs. C++
От: SilentNoise  
Дата: 11.09.12 13:12
Оценка: :)
Здравствуйте, uzhas, Вы писали:

U>снова фейл

U>классическая проблема Си: борьба со звездочками
Да, есть такое.
Решается typedef`ами.
Re[4]: C vs. C++
От: Don Reba Канада https://stackoverflow.com/users/49329/don-reba
Дата: 11.09.12 13:18
Оценка: :)
Здравствуйте, Alexéy Sudachén, Вы писали:

AS>
AS>YO_ARRAY *Oj_Get_Lines(void *file) {
AS>  YO_ARRAY *arr = Array_Pchars();
AS>  char *S;
AS>  while ((  S = Oj_Read_Line(file) )) Array_Push(__Retain(S));
AS>  return arr;
AS>}

AS>YO_ARRAY *arr = Oj_Get_Lines(Cfile_Open("file","r"));

AS>или

AS>char lines[] = "line1\nline2\nline3";
AS>YO_ARRAY *arr = Oj_Get_Lines(Memory_As_File(lines,strlen(lines)));

AS>или с любого объекта который реализует протокол чтения строки.
AS>



AS>Короче, https://github.com/alexeysudachen/libyoyo — там всё написано.


Йоу, массив. Ой, возьми строчки. Ой, прочитал строку. Библиотека, йо, йо — вотс ап, дог?
Ce n'est que pour vous dire ce que je vous dis.
Re[5]: C vs. C++
От: Piko  
Дата: 11.09.12 13:39
Оценка: -1
Здравствуйте, SilentNoise, Вы писали:

SN>Здравствуйте, Piko, Вы писали:


P>>таки соптимизирует! http://eigen.tuxfamily.org/index.php?title=Benchmark

SN>И не раздует при этом бинарник до космических размеров?

как минимум не больше рукопашная кодогенерация
http://www.osl.iu.edu/publications/prints/1998/siek98%3A_siamoo.pdf

As an example, to provide basic functionality for selected sparse matrix
types, the NIST implementation of the Sparse BLAS [18] contains over 10,000 routines and
a code generation system.



SN>думают что С++ это ООП язык,

P>>я хз что ты понимаешь под "ООП язык".
P>>некоторые думают что ООП — это значит отсутствие free functions
SN>В гугл

http://lmgtfy.com/?q=oop+language
везде C++ упоминается.
я хз какое у тебе в голове понятие "ООП язык", поэтому попробуй его озвучить.
Re[6]: C vs. C++
От: Piko  
Дата: 11.09.12 13:41
Оценка: -1
Здравствуйте, Piko, Вы писали:

P>как минимум не больше чем рукопашная кодогенерация
Re[6]: C vs. C++
От: SilentNoise  
Дата: 11.09.12 13:48
Оценка: -1
Здравствуйте, Piko, Вы писали:

P>как минимум не больше рукопашная кодогенерация

Ага, но экспоненциально больше чем использование void* и функции.
Re: C vs. C++
От: Centaur Россия  
Дата: 11.09.12 14:14
Оценка: +1
Здравствуйте, igna, Вы писали:

I>Есть тут кто-нибудь, кто предпочитает C вместо C++ хотя бы и для отдельных проектов?


Писать на C не люблю*, но считаю необходимым уметь его читать. Потому что это lingua franca, общий знаменатель для взаимодействия всего со всем.

* Постоянно скатываюсь в плюсизмы — то переменную объявлю по месту использования, то void в аргументах функции забуду.

I>Использую libxml2, это библиотека на C, и решил из интереса попробовать и свой модуль, непосредственно использующий libxml2, написать на C.


Над libxml2 есть обёртка libxml++.
Re[5]: C vs. C++
От: Alexéy Sudachén Чили  
Дата: 11.09.12 14:32
Оценка: :)
AS>>Короче, https://github.com/alexeysudachen/libyoyo — там всё написано.
DR>Йоу, массив. Ой, возьми строчки. Ой, прочитал строку. Библиотека, йо, йо — вотс ап, дог?

Ты таки офигительно прав! Именно так. ))) Изначально это было что-то типа шутки. Первая версия эксперимента, кстати, вообще называлась junk. Но как-то так оказалось что в этой шутке, доля шутки уж больно микроскопическая, а простота использования ставит C++ в какое-то непонятное положение. От оно как бывает.
Re[9]: C vs. C++
От: Piko  
Дата: 11.09.12 14:38
Оценка: +1
Здравствуйте, SilentNoise, Вы писали:

P>во-первых, какие-либо тесты будут? или только "экспоненциальный" трёп? а то ведь это место скользкое — push/pop, frame stuff и т.п. может стоит больше по размеру чем инлайн малюсенькой функции.

P>во-вторых, мы вроде про оптимизацию говорим, и видимо по скорости, не? Ну а если нужна оптимизация по размеру — то и она получится лучше и безопасней на C++
SN>Если тебе не очевидно, что при использовании шаблонов для эмуляции полиморфизма они будут развернуты с дублированием кода, то тут нечего добавить.

если тебе не очевидно, что дублирование может оптимизироваться до суммарных размеров меньших чем с void*, а то и вообще до нулевых, то я

например, напиши void* аналог:
template<typename T>
inline const T& max(const T &a, const T &b)
{
    return (a<b) ? b : a;
}
Re[3]: C vs. C++
От: Трололоша  
Дата: 11.09.12 19:01
Оценка: +1
Здравствуйте, SilentNoise, Вы писали:

MZ>>С так ужо убого выглядит, что просто морально нельзя его терпеть.

SN>Вы это так говорите, будто С++ выглядит менее убого.

Ты не поверишь!
... << RSDN@Home >>
Да, йа зелёный тролль!
Re[2]: C vs. C++
От: Трололоша  
Дата: 11.09.12 19:51
Оценка: :)
Здравствуйте, Vain, Вы писали:

I>>Есть тут кто-нибудь, кто предпочитает C вместо C++ хотя бы и для отдельных проектов?

V>А я вот где-то годик под чистыми сями писал. Сначало думал что буду плеваться, но был приятно удивлён обратной стороной сей. Можно сказать что за это время буквально часть мозга высвободилась из языкового оверхеда с++ под прикладные задачи. Ни шаблонов тебе, ни перегрузок, ни вложенных классов/скопов, ни виртуальных функций, ни исключений, ни горбатых стримов, ничего, красота..

Напомнило: Проклятое сало
... << RSDN@Home >>
Да, йа зелёный тролль!
Re[6]: C vs. C++
От: MTD https://github.com/mtrempoltsev
Дата: 12.09.12 11:22
Оценка: +1
Здравствуйте, Alexéy Sudachén, Вы писали:

AS>Покажи чистый. Буду знать как надо писать правильно.



YO_ARRAY *Oj_Get_Lines(void *file) {
  YO_ARRAY *arr = Array_Pchars();
  char *S;
  while ((  S = Oj_Read_Line(file) )) Array_Push(__Retain(S));
  return arr;
}


1. Не понятно, что с ошибками. Обычно в C функции возвращают код ошибки, здесь мне не понятно, что будет если например вместо file передам 0.
2. Создали arr типа YO_ARRAY, где потом arr используется? Не понятно.
3. Что такое Pchars? Я еще пойму просто char или там utf32, но это
3. Oj_Read_Line, как я понял вернет нулевой указатель когда будет достигнут конец файла. Как определить, что это не конец, а ошибка файла?
4. Куда помещает строку Array_Push? Из кода не понятно.
5. Для чего нужно __Retain?
6. Почему местами YO, а местами Oj? Разные библиотеки?
7. Почему локальная переменная arr, но локальная переменная S?
Re[8]: C vs. C++
От: igna Россия  
Дата: 12.09.12 13:02
Оценка: +1
Здравствуйте, Piko, Вы писали:

P>зачем текстовая версия, в чём проблема посмотреть видео?


Я скорее всего не все пойму.
Долго.
Нельзя использовать поиск.
Надо одевать наушники.

Заколебали своими видеопрезентациями.
Re[11]: C vs. C++
От: Piko  
Дата: 12.09.12 13:36
Оценка: +1
Здравствуйте, igna, Вы писали:

P>>это просто пруфлинк — ты можешь не проверять

I>Проверять и не собирался, просто народ собрался интересный, хотел узнать, что они там еще говорят. Но нет, так нет.

там много чего ещё есть, например http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Interactive-Panel-Ask-Us-Anything- ,
http://channel9.msdn.com/Events/GoingNative/GoingNative-2012 , http://channel9.msdn.com/Events/Speakers/Herb-Sutter
ну и т.п.
язык там очень простой, школьного уровня должно хватить
Re[8]: C vs. C++
От: Трололоша  
Дата: 12.09.12 19:36
Оценка: +1
Здравствуйте, night beast, Вы писали:

NB>только вот не надо на доксиген гнать.

NB>капитанские комментарии и без него пишут.

Когда принудительно внедряют doxy, особенно если стоит при коммите автопроверка и коммит не проходит если нету комментария — вот тогда комменты от Кэпа валят сотнями.
... << RSDN@Home >>
Да, йа зелёный тролль!
Re[15]: C vs. C++
От: Alexéy Sudachén Чили  
Дата: 14.09.12 18:42
Оценка: :)
AS>>А-А-А-А, я не знаю что так можно писать switch!!! А-А-А-А, C не нужен, он рвёт мой шаблон!!!
P>ну если ты не помнишь, у меня претензии к твоему макродрочерству, появились ровно после твоих бравад о том как переход с С++ на C привёл, к цитирую:

Ну, по причине неадекватной сложности, ведущей к постоянной борьбе с языком, и постоянного вынужденного скатывания к [b]синтаксическому...


И. Данная специфика C++ активно обсуждалась на этом форуме, в те временя когда ты о нём и не знал ещё. Мне это ещё раз повторить? Что борьба с 'недоумками' имеющими наглость использовать таки С, в то время когда всё прогрессивное человечество давно тащится по C++ — как-то улучшило твоё понимание тривиальной языковой конструкции switch или отменило факт что в С макросы один из типичных инструментов? Однако мне льстит, что ты сравниваешь сложность нескольких моих макросов со сложностью типового кодирования на плюсах. Это даже как то бодрит и радует ))))
Re[16]: C vs. C++
От: Piko  
Дата: 14.09.12 19:26
Оценка: +1
Здравствуйте, Alexéy Sudachén, Вы писали:

AS>>>А-А-А-А, я не знаю что так можно писать switch!!! А-А-А-А, C не нужен, он рвёт мой шаблон!!!

P>>ну если ты не помнишь, у меня претензии к твоему макродрочерству, появились ровно после твоих бравад о том как переход с С++ на C привёл, к цитирую:
AS>

Ну, по причине неадекватной сложности, ведущей к постоянной борьбе с языком, и постоянного вынужденного скатывания к [b]синтаксическому...

AS>И. Данная специфика C++ активно обсуждалась на этом форуме, в те временя когда ты о нём и не знал ещё.

обсуждалось раньше 1999 года? ну может быть, не спорю, я хз когда rsdn появился
я в 99 был в 2:50X/Y.Z

AS> Однако мне льстит, что ты сравниваешь сложность нескольких моих макросов со сложностью типового кодирования на плюсах. Это даже как то бодрит и радует ))))


я не знаю что там тебе льстит, но конкретно эти макросы как раз и есть синтаксический онанизм, к которому тебе "приходилось" скатываться при использовании C++
C vs. C++
От: igna Россия  
Дата: 11.09.12 11:22
Оценка:
Есть тут кто-нибудь, кто предпочитает C вместо C++ хотя бы и для отдельных проектов?

Использую libxml2, это библиотека на C, и решил из интереса попробовать и свой модуль, непосредственно использующий libxml2, написать на C. Сначала оно было как бы неплохо, потом хуже. Возможно с непривычки, а есть здесь те, кто предпочитает C?

11.09.12 19:19: Перенесено модератором из 'C/C++' — Кодт
Re[2]: C vs. C++
От: MasterZiv СССР  
Дата: 11.09.12 11:47
Оценка:
> С более легкий для использования язык, который позволяет разработчику
> сосредоточиться на решении прикладных задач, а не копаться в сложностях самого
> языка.

Ага, сказочки всё это. Начнём например с постоянной необходимости понимать
конструкцию "ссылка (в виде указателя) на созданных в хипе объект, передаваемая
по ссылке, с возможностью изменения ссылки".
Это конечно постижимо, не rocket science, но всё же -- если на каждом шагу,
очень путает.
Posted via RSDN NNTP Server 2.1 beta
Re: C vs. C++
От: Alexéy Sudachén Чили  
Дата: 11.09.12 12:37
Оценка:
I>Есть тут кто-нибудь, кто предпочитает C вместо C++ хотя бы и для отдельных проектов?

Да.

I>Использую libxml2, это библиотека на C, и решил из интереса попробовать и свой модуль, непосредственно использующий libxml2, написать на C. Сначала оно было как бы неплохо, потом хуже. Возможно с непривычки, а есть здесь те, кто предпочитает C?


Да.

Встречный вопрос, это для разжигания флейма, или действительно интересно? Ведь задавать тут такой вопрос, это как в бочку с бензином спичку кинуть.
Re[2]: C vs. C++
От: igna Россия  
Дата: 11.09.12 12:49
Оценка:
Здравствуйте, Alexéy Sudachén, Вы писали:

AS>Встречный вопрос, это для разжигания флейма, или действительно интересно?


Это действительно интересно, потому-что хочу задать более конкрентые вопросы. Например, если функция должна разместить массив строк и вернуть его, как ты это делаешь? Например:

int get_lines_as_strings(FILE *, char const *const **); // возвращает количество строк


или

struct strings {
    int num; // количество строк
    char const *const *str;
};

void get_lines_as_strings(FILE *, struct strings *);


или

struct strings {
    int num; // количество строк
    char const *const *str;
};

struct string get_lines_as_strings(FILE *);


или еще как?
Re[3]: C vs. C++
От: MasterZiv СССР  
Дата: 11.09.12 13:08
Оценка:
On 09/11/2012 04:41 PM, Сыроежка wrote:

> Все это делает проекты на С++ более затратными.


А теперь прочитай всё это, заменив С++ на С и наоборот.
Будет тоже всё верно!
Posted via RSDN NNTP Server 2.1 beta
Re[9]: C vs. C++
От: igna Россия  
Дата: 11.09.12 13:12
Оценка:
Здравствуйте, SilentNoise, Вы писали:

SN>Но идею, думаю, Вы поняли.


Не понял, чем "идея" отличается от моего первого варианта.
Re[5]: What's up, Doc?
От: Qbit86 Кипр
Дата: 11.09.12 13:23
Оценка:
Здравствуйте, Don Reba, Вы писали:

DR>Библиотека, йо, йо — вотс ап, дог?


Какой ещё «дог»?
Глаза у меня добрые, но рубашка — смирительная!
Re[4]: C vs. C++
От: igna Россия  
Дата: 11.09.12 13:23
Оценка:
Здравствуйте, Alexéy Sudachén, Вы писали:

AS>Дык, а как это обычно делается в С++? Используется соответствующий фреймворк/библиотека примитивов. Ну и я то же использую свой фреймворк.


В C++ есть стандарный фреймворк. Поэтому нельзя сказать "тоже".

vector<string> get_lines_as_strings(istream&);


Но у меня есть еще один вопрос, как сообщать об ошибке, если файл не прочитался или память не разместилась? Менять сигнатуру функции? Просто вернуть нулевой указатель недостаточно, если нужно различать между двумя причинами ошибки.
Re: C vs. C++
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 11.09.12 13:31
Оценка:
Здравствуйте, igna, Вы писали:

I>Есть тут кто-нибудь, кто предпочитает C вместо C++ хотя бы и для отдельных проектов?


I>Использую libxml2, это библиотека на C, и решил из интереса попробовать и свой модуль, непосредственно использующий libxml2, написать на C. Сначала оно было как бы неплохо, потом хуже. Возможно с непривычки, а есть здесь те, кто предпочитает C?


Для себя пишу сейчас на C99, мне нравится. Отношение к С++ мое можно выразить словами: "лишний член --- жопе непонятка". Писать, конечно, можно. Но только большую часть возишься с архитектурой, а не с логикой. Да, С тавтологичен, но большого неудобства это не доставляет: раз скопировал и забыл. Сильно не напрягает.

По работе и С, и С++. Но С++ весьма ограничен (kernel mode).
Re[2]: C vs. C++
От: igna Россия  
Дата: 11.09.12 13:34
Оценка:
Здравствуйте, Mystic, Вы писали:

M>Для себя пишу сейчас на C99, мне нравится. Отношение к С++ мое можно выразить словами: "лишний член --- жопе непонятка".


Отлично, а можно попросить тебя тоже ответить на вопрос
Автор: igna
Дата: 11.09.12
?
Re[6]: C vs. C++
От: denisko http://sdeniskos.blogspot.com/
Дата: 11.09.12 13:56
Оценка:
Здравствуйте, MasterZiv, Вы писали:


>> Не будет, ибо те средства абстракции, которые есть в С++ но отсутствуют в С,

>> сделаны так монструозно, что приносят больше проблем чем профита.

MZ>Чё? чего сретства ? С++ прост как палка.

А кто сложен тогда?
<Подпись удалена модератором>
Re[6]: C vs. C++
От: A13x США  
Дата: 11.09.12 13:58
Оценка:
Здравствуйте, MasterZiv, Вы писали:


>> С++ прост как палка.


По сравнению с чем?
По сравнению с С или Java это очень сильно не так, говорю исходя из собственного опыта, особенно вспоминая мой давний опыт windows программирования когда приходилось использовать COM компоненты в MFC приложении.
Re[4]: C vs. C++
От: igna Россия  
Дата: 11.09.12 14:02
Оценка:
Здравствуйте, denisko, Вы писали:

Спасибо, а как сообщать об ошибке, если файл не прочитался или память не разместилась?
Re[8]: C vs. C++
От: SilentNoise  
Дата: 11.09.12 14:18
Оценка:
Здравствуйте, Piko, Вы писали:

P>во-первых, какие-либо тесты будут?

Если тебе не очевидно, что при использовании шаблонов для эмуляции полиморфизма они будут развернуты с дублированием кода, то тут нечего добавить.
Re[5]: C vs. C++
От: Alexéy Sudachén Чили  
Дата: 11.09.12 14:23
Оценка:
I>Но у меня есть еще один вопрос, как сообщать об ошибке, если файл не прочитался или память не разместилась? Менять сигнатуру функции? Просто вернуть нулевой указатель недостаточно, если нужно различать между двумя причинами ошибки.

Бросить разные исключения?
Re[4]: C vs. C++
От: ntp  
Дата: 11.09.12 14:27
Оценка:
Здравствуйте, Alexéy Sudachén, Вы писали:

AS>Условно говоря —

Грязный код..
Re[9]: C vs. C++
От: igna Россия  
Дата: 11.09.12 14:30
Оценка:
Здравствуйте, SilentNoise, Вы писали:

SN>Если тебе не очевидно, что при использовании шаблонов для эмуляции полиморфизма они будут развернуты с дублированием кода, то тут нечего добавить.


Вроде бы этого можно избежать, нет?:

class my_vector_impl {
    friend class my_vector;
    . . .
    void* f(void*);
    . . .
};

template <class T>
class my_vector {
    my_vector_impl impl_;
public:
    . . .
    T* f(T* p) { return reinterpret_cast<T*>(impl_.f(p)); }
    . . .
Re[6]: C vs. C++
От: igna Россия  
Дата: 11.09.12 14:32
Оценка:
Здравствуйте, Alexéy Sudachén, Вы писали:

AS>Бросить разные исключения?


В C?
Re[7]: C vs. C++
От: Alexéy Sudachén Чили  
Дата: 11.09.12 14:34
Оценка:
AS>>Бросить разные исключения?
I>В C?

Ну да, а что такого? Я довольно подробно тут как-то показывал как это сделать.
Re[5]: C vs. C++
От: Alexéy Sudachén Чили  
Дата: 11.09.12 14:35
Оценка:
AS>>Условно говоря —
ntp>Грязный код..

Покажи чистый. Буду знать как надо писать правильно.
Re[6]: C vs. C++
От: denisko http://sdeniskos.blogspot.com/
Дата: 11.09.12 14:38
Оценка:
Здравствуйте, Alexéy Sudachén, Вы писали:

AS>>>Короче, https://github.com/alexeysudachen/libyoyo — там всё написано.

DR>>Йоу, массив. Ой, возьми строчки. Ой, прочитал строку. Библиотека, йо, йо — вотс ап, дог?

AS>Ты таки офигительно прав! Именно так. ))) Изначально это было что-то типа шутки. Первая версия эксперимента, кстати, вообще называлась junk. Но как-то так оказалось что в этой шутке, доля шутки уж больно микроскопическая, а простота использования ставит C++ в какое-то непонятное положение. От оно как бывает.

А в чем именно _преимущества_ перед плюсами на обычных платформах, где размер кода роли не играет? Тебе по-любому придется часть вещей делать через макродрочество, которое заменяется на шаблоны с небольшим/большим распуханием по коду но делающими ровно тоже самое. Пользоваться своими менеджерами памяти объектов и ты в плюсах можешь.
<Подпись удалена модератором>
Re[11]: C vs. C++
От: igna Россия  
Дата: 11.09.12 14:46
Оценка:
Здравствуйте, Piko, Вы писали:

P>лучше static_cast...


Верно, но тогда надо не void*. Я просто хотел идею показать.
Re[11]: C vs. C++
От: Piko  
Дата: 11.09.12 14:46
Оценка:
Здравствуйте, Piko, Вы писали:

I>> T* f(T* p) { return reinterpret_cast<T*>(impl_.f(p)); }

P>лучше static_cast...

и только при касте обратно, в T*
Re[12]: C vs. C++
От: igna Россия  
Дата: 11.09.12 14:49
Оценка:
Здравствуйте, Piko, Вы писали:

P>и только при касте обратно, в T*


Так у меня только обратно и есть, нет?
Re[7]: C vs. C++
От: Alexéy Sudachén Чили  
Дата: 11.09.12 15:02
Оценка:
D>А в чем именно _преимущества_ перед плюсами на обычных платформах, где размер кода роли не играет? Тебе по-любому придется часть вещей делать через макродрочество, которое заменяется на шаблоны с небольшим/большим распуханием по коду но делающими ровно тоже самое. Пользоваться своими менеджерами памяти объектов и ты в плюсах можешь.

Теоретически да. Практически же макросов в рабочем коде почти нет. Чтобы добиться похожего результата, в С++ мне приходится писать кучу обёрток или использовать их. Причём явно и понимая как оно может взбрыкнуть и с какими последствиями. С учётом трейтсов и всяких других неявных стратегий это легко вырастает в серьёзную головную боль. В коде на С, я просто пишу код. Так называемое макродрочерство присутствует только в коде yoyo, в целевом коде его нет. Хотя фиг его знает что ты под этим понимаешь.

Фактически преимущество в том, что мне нужно меньше думать на тему как, и больше о том что именно и зачем я делаю. Но в общем-то вопрос привычки. Однако тезис о принципиальном превосходстве C++, и ущербности C — я рассматриваю уже как миф и не более.
Re[8]: C vs. C++
От: denisko http://sdeniskos.blogspot.com/
Дата: 11.09.12 15:12
Оценка:
Здравствуйте, Alexéy Sudachén, Вы писали:

D>>А в чем именно _преимущества_ перед плюсами на обычных платформах, где размер кода роли не играет? Тебе по-любому придется часть вещей делать через макродрочество, которое заменяется на шаблоны с небольшим/большим распуханием по коду но делающими ровно тоже самое. Пользоваться своими менеджерами памяти объектов и ты в плюсах можешь.


AS>Теоретически да. Практически же макросов в рабочем коде почти нет.

Ну я глянул пару файлов, они были, но в глаза особо не бросались.

AS>Чтобы добиться похожего результата, в С++ мне приходится писать кучу обёрток или использовать их. Причём явно и понимая как оно может взбрыкнуть и с какими последствиями. С учётом трейтсов и всяких других неявных стратегий это легко вырастает в серьёзную головную боль. В коде на С, я просто пишу код. Так называемое макродрочерство присутствует только в коде yoyo, в целевом коде его нет. Хотя фиг его знает что ты под этим понимаешь.

Это не плюсы виноваты, а мейнстримовый стиль написания (спасибо, майерсу и остальным). У него есть плюсы и минусы, основной минус — толстовство, т.е. алаконичность. Меня это не волнует, я печатаю быстро.


AS>Фактически преимущество в том, что мне нужно меньше думать на тему как, и больше о том что именно и зачем я делаю. Но в общем-то вопрос привычки. Однако тезис о принципиальном превосходстве C++, и ущербности C — я рассматриваю уже как миф и не более.

Современные программисты под то и под то уже эволюционировали так, чтобы писать код с примерной одинаковой скоростью и одинаковыми параметрами по качеству, производительности и.т.д. Но для тех, кто не эволюционировал, это более или менее правда. Например, студенческие поделки на ++ более управляемы, отлаживаемы и поддерживаемы, чем то же самое на голых сях.
<Подпись удалена модератором>
Re[8]: C vs. C++
От: Piko  
Дата: 11.09.12 15:15
Оценка:
Здравствуйте, Alexéy Sudachén, Вы писали:

D>>А в чем именно _преимущества_ перед плюсами на обычных платформах, где размер кода роли не играет? Тебе по-любому придется часть вещей делать через макродрочество, которое заменяется на шаблоны с небольшим/большим распуханием по коду но делающими ровно тоже самое. Пользоваться своими менеджерами памяти объектов и ты в плюсах можешь.


AS>Теоретически да. Практически же макросов в рабочем коде почти нет. Чтобы добиться похожего результата, в С++ мне приходится писать кучу обёрток или использовать их.


у тебя макросы запрятаны в yoyo lib, что мешает запрятать обвёртки C++ в либу, или даже использовать готовые?

AS>Причём явно и понимая как оно может взбрыкнуть и с какими последствиями. С учётом трейтсов и всяких других неявных стратегий это легко вырастает в серьёзную головную боль. В коде на С, я просто пишу код. Так называемое макродрочерство присутствует только в коде yoyo, в целевом коде его нет. Хотя фиг его знает что ты под этим понимаешь.


грабли есть и в yoyo подходе
http://www.rsdn.ru/forum/job/4877955.1.aspx
Автор: Piko
Дата: 02.09.12

http://www.rsdn.ru/forum/job/4877996.1.aspx
Автор: Piko
Дата: 03.09.12


В C++ никто не заставляет тебя использовать non-intrusive'ные traits.
Re[6]: C vs. C++
От: Piko  
Дата: 11.09.12 15:26
Оценка:
Здравствуйте, Alexéy Sudachén, Вы писали:

AS>>>Условно говоря —

ntp>>Грязный код..
AS>Покажи чистый. Буду знать как надо писать правильно.

ну мне он тоже кажется грязным — но это чисто субъективно, дело привычки, и не относится к языку.
я бы предпочёл:
Array *read_lines(void *file)
{
    Array *lines = Strings();
    char *line;
    while( (line = read_line(file)) )
        array_push(retain(line));
    return lines;
}

Array *lines = read_lines(open_file("file","r"));

или

char lines[] = "line1\nline2\nline3";
Array *lines = read_lines(memory_as_file(lines,strlen(lines)));

но опять же — чистый субъектив и привычка
Re[9]: C vs. C++
От: Alexéy Sudachén Чили  
Дата: 11.09.12 15:35
Оценка:
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++ и он у тебя работает и проходит все тесты — это совершенно не значит что при подключении к другому модулю он вдруг не начнёт отплясывать джигу.
Re: C vs. C++
От: ДимДимыч Украина http://klug.org.ua
Дата: 11.09.12 15:43
Оценка:
Здравствуйте, igna, Вы писали:

I>Есть тут кто-нибудь, кто предпочитает C вместо C++ хотя бы и для отдельных проектов?


Есть.
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
Re[6]: errno
От: igna Россия  
Дата: 11.09.12 15:45
Оценка:
Здравствуйте, Mystic, Вы писали:

M>errno обычно установлена соответственно


Что значит соответственно? В стандарте 3 значения, как можно определить свои?
Re[7]: C vs. C++
От: Alexéy Sudachén Чили  
Дата: 11.09.12 15:50
Оценка:
AS>>Покажи чистый. Буду знать как надо писать правильно.
P>ну мне он тоже кажется грязным — но это чисто субъективно, дело привычки, и не относится к языку.
P>я бы предпочёл:

Может ещё про расстановку скобочек поспорим. Когда я чужой код читаю, мне вот совершенно пофигу как стоят скобочки, как пишутся имена ... Свой стиль кодирования я здесь обсуждать не буду, могу только сказать что он выработан годами и всё в нём имеет объяснение. Опять же, как с тем for циклом, я пробовал много разных способов. То что я выбрал имеет совершенно конкретные причины. Однако, это мой личный стиль кодирования, и использую я его только в своих проектах.

Тут на самом деле важно другое, код то вообще-то хоть кто нить прочитал?! Я вообще-то ребёнка в садик собирал и потому особенно не проверял что пишу, то что в Array_Push, исходя из здравого смысла, аргумента не хватает так похоже никто и не заметил ))))
Re[2]: C vs. C++
От: igna Россия  
Дата: 11.09.12 15:50
Оценка:
Здравствуйте, ДимДимыч, Вы писали:

ДД>Есть.


И какой механизм используешь для сообщения об ошибке? В отсутствие исключений.
Re[7]: errno
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 11.09.12 15:52
Оценка:
Здравствуйте, igna, Вы писали:

I>Здравствуйте, Mystic, Вы писали:


M>>errno обычно установлена соответственно


I>Что значит соответственно? В стандарте 3 значения, как можно определить свои?


В стандарте POSIX больше значений. Среди них ENOMEM, ENOENT, ... Обычно эти значения уже вернут функции libc.
Re[11]: C vs. C++
От: Alexéy Sudachén Чили  
Дата: 11.09.12 15:56
Оценка:
P>а тебя не смущает что одним макросом
P>
P>#define while(x) /*BOOM Baby!*/
P>


Ровно так же как и в С++. Так что не считается. К тому же легко посмотреть что нарисовал препроцессор, а вот во что шаблоны развернулись....

AS>>Фактически когда ты пишешь модуль на C++ и он у тебя работает и проходит все тесты — это совершенно не значит что при подключении к другому модулю он вдруг не начнёт отплясывать джигу.

P>у меня при подключении модулей в production, ни разу джигу не танцевал а у тебя?

Танцевали. Но не в продакшене, а просто при сборке разных модулей. В диапазоне от резкого просада производительности до расстрела памяти. А с учётом что этот код написан на матёром двоеплюсии .... веселуха ещё та. Собственно из за матёрого двоеплюсия оно так и бывает.
Re[8]: errno
От: igna Россия  
Дата: 11.09.12 16:03
Оценка:
Здравствуйте, Mystic, Вы писали:

M>В стандарте POSIX больше значений. Среди них ENOMEM, ENOENT, ... Обычно эти значения уже вернут функции libc.


А под Windows что делать? Гарантий, что все работает так же нет никаких. В errno.h есть следующее "Conforms to the XENIX standard.", но это же старье.
Re[3]: C vs. C++
От: ДимДимыч Украина http://klug.org.ua
Дата: 11.09.12 16:07
Оценка:
Здравствуйте, igna, Вы писали:

I>И какой механизм используешь для сообщения об ошибке? В отсутствие исключений.


В большинстве случаев — возвращаемое значение и errno.
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
Re[4]: C vs. C++
От: igna Россия  
Дата: 11.09.12 16:09
Оценка:
Здравствуйте, ДимДимыч, Вы писали:

ДД>В большинстве случаев — возвращаемое значение и errno.


Свое значение errno можно определить?
Re[5]: C vs. C++
От: night beast СССР  
Дата: 11.09.12 16:13
Оценка:
Здравствуйте, igna, Вы писали:

AS>>Дык, а как это обычно делается в С++? Используется соответствующий фреймворк/библиотека примитивов. Ну и я то же использую свой фреймворк.


I>
I>vector<string> get_lines_as_strings(istream&);
I>


I>Но у меня есть еще один вопрос, как сообщать об ошибке, если файл не прочитался или память не разместилась? Менять сигнатуру функции? Просто вернуть нулевой указатель недостаточно, если нужно различать между двумя причинами ошибки.


вариантов несколько:
1. array_type * get_lines_as_strings ( istream&, error_info * error = 0 );
2. error_code get_lines_as_strings ( istream&, array_type * strings );
3. исключения через long_jmp
Re[5]: C vs. C++
От: ДимДимыч Украина http://klug.org.ua
Дата: 11.09.12 16:13
Оценка:
Здравствуйте, igna, Вы писали:

ДД>>В большинстве случаев — возвращаемое значение и errno.

I>Свое значение errno можно определить?

Технически можно, но не нужно. Зачем?
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
Re[6]: C vs. C++
От: igna Россия  
Дата: 11.09.12 16:17
Оценка:
Здравствуйте, night beast, Вы писали:

NB>1. array_type * get_lines_as_strings ( istream&, error_info * error = 0 );


Что там такое после error похожее на значение аргумента по умолчанию?
Re[6]: C vs. C++
От: igna Россия  
Дата: 11.09.12 16:19
Оценка:
Здравствуйте, ДимДимыч, Вы писали:

ДД>Технически можно


Как?
Re[2]: C vs. C++
От: azzx Россия  
Дата: 11.09.12 16:36
Оценка:
Здравствуйте, Alexéy Sudachén, Вы писали:

AS>Встречный вопрос, это для разжигания флейма, или действительно интересно? Ведь задавать тут такой вопрос, это как в бочку с бензином спичку кинуть.


Если бочка полная — спичка тупа погаснет, скорее всего.

Темка старовата для флейма. Сейчас, наверное, более актуально "плюсы не нужны" или "плюсы супротив питона".

А по теме топика — раньше писал немного. Сейчас вообще плюсы не нужны, а если надо будет что-то написать к тому же питону (или какой-то мелкий конвертор данных сам по себе, например) — плюсы не нужны совершенно для таких задач. А других у меня для него нет.
Re[7]: C vs. C++
От: ДимДимыч Украина http://klug.org.ua
Дата: 11.09.12 16:38
Оценка:
Здравствуйте, igna, Вы писали:

ДД>>Технически можно


I>Как?


Ну как. errno — это int, можно любое значение в пределах int присваивать.
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
Re[9]: errno
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 11.09.12 17:17
Оценка:
Здравствуйте, igna, Вы писали:

I>Здравствуйте, Mystic, Вы писали:


M>>В стандарте POSIX больше значений. Среди них ENOMEM, ENOENT, ... Обычно эти значения уже вернут функции libc.


I>А под Windows что делать? Гарантий, что все работает так же нет никаких. В errno.h есть следующее "Conforms to the XENIX standard.", но это же старье.


Тут еще проще, Microsoft последний стандарт Cи не поддерживает из принципа. Так что если брать вижуал, то там мои исходники в принципе не скомпилируются, проблема еще до POSIX.
Re[8]: C vs. C++
От: Piko  
Дата: 11.09.12 18:14
Оценка:
Здравствуйте, Alexéy Sudachén, Вы писали:

AS>>>Покажи чистый. Буду знать как надо писать правильно.

P>>ну мне он тоже кажется грязным — но это чисто субъективно, дело привычки, и не относится к языку.
P>>я бы предпочёл:
AS>Может ещё про расстановку скобочек поспорим.

я же говорю — субъективно

AS>Когда я чужой код читаю, мне вот совершенно пофигу как стоят скобочки, как пишутся имена ...


ну конечно, зачастую чужого кода переваривать нужно на порядки больше чем своего, но всё же свой стиль периваривается легче
например вот такой стиль:
if(condition)
    {
    stmt1;
    stmt2;
    ...
    }

мне с непривычки крышу немного сносит, да

AS>Тут на самом деле важно другое, код то вообще-то хоть кто нить прочитал?! Я вообще-то ребёнка в садик собирал и потому особенно не проверял что пишу, то что в Array_Push, исходя из здравого смысла, аргумента не хватает так похоже никто и не заметил ))))


ну да косяк, хотя семантику я не проверял, да и отмазка у меня тоже есть...
Re[6]: C vs. C++
От: Трололоша  
Дата: 11.09.12 19:01
Оценка:
Здравствуйте, Alexey Sudachen, Вы писали:

AS>а простота использования ставит C++ в какое-то непонятное положение.


Тут уже перетирали эту "простоту использования". Рукопашку на plain C несколько упрощает, но до С++ ему ещё ползти и ползти.
... << RSDN@Home >>
Да, йа зелёный тролль!
Re[4]: C vs. C++
От: uncommon Ниоткуда  
Дата: 12.09.12 02:34
Оценка:
Здравствуйте, Alexéy Sudachén, Вы писали:

AS>Короче, https://github.com/alexeysudachen/libyoyo — там всё написано.


Что, это кроме тебя кто-нибудь использует? Буду очень удивлен. В коде нет комментариев. Не просто очень мало, а вообще нет. Нуль полный. Что этот код делает? Кроме создателя никто не знает. И не дай бог узнает! Коммиты тоже не блещут выразительностью. "updated", "updated", "updated", опять "updated". Что трудно для себя хотя бы написать, что ты там изменил?
Re[4]: C vs. C++
От: MTD https://github.com/mtrempoltsev
Дата: 12.09.12 04:48
Оценка:
Здравствуйте, Alexéy Sudachén, Вы писали:

AS>Дык, а как это обычно делается в С++?


Если не брать обработку ошибок, которой у тебя кстати тоже нет, то примерно так:

typedef std::vector<std::string> string_list;

void read_lines(std::istream& from, string_list& to)
{
    std::string buf;
    while (std::getline(from, buf))
        to.push_back(buf);
}
Re[6]: C vs. C++
От: MTD https://github.com/mtrempoltsev
Дата: 12.09.12 04:57
Оценка:
Здравствуйте, Alexéy Sudachén, Вы писали:

AS>простота использования ставит C++ в какое-то непонятное положение


Заметно. И это мы еще до обработки ошибок не дошли (ее тут нет), когда окажется, что твой код сыпется как карточный домик.

typedef std::vector<std::string> string_list;

void read_lines(std::istream& from, string_list& to)
{
    std::string buf;
    while (std::getline(from, buf))
        to.push_back(buf);
}


YO_ARRAY *Oj_Get_Lines(void *file) {
  YO_ARRAY *arr = Array_Pchars();
  char *S;
  while ((  S = Oj_Read_Line(file) )) Array_Push(__Retain(S));
  return arr;
}
Re[8]: C vs. C++
От: igna Россия  
Дата: 12.09.12 05:53
Оценка:
Здравствуйте, ДимДимыч, Вы писали:

ДД>Ну как. errno — это int, можно любое значение в пределах int присваивать.


Любое точно нельзя. Вопрос в том, как выбрать значение, которое гарантировано не будет использовано в будущим стандарте.
Re[9]: C vs. C++
От: ДимДимыч Украина http://klug.org.ua
Дата: 12.09.12 09:40
Оценка:
Здравствуйте, igna, Вы писали:

I>Любое точно нельзя. Вопрос в том, как выбрать значение, которое гарантировано не будет использовано в будущим стандарте.


Поэтому я и говорю, что технически можно, но делать так не надо.
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
Re[10]: C vs. C++
От: igna Россия  
Дата: 12.09.12 10:40
Оценка:
Здравствуйте, ДимДимыч, Вы писали:

ДД>Поэтому я и говорю, что технически можно, но делать так не надо.


Во! То есть errno не для переносимых программ.
Re: C vs. C++
От: Pzz Россия https://github.com/alexpevzner
Дата: 12.09.12 11:29
Оценка:
Здравствуйте, igna, Вы писали:

I>Есть тут кто-нибудь, кто предпочитает C вместо C++ хотя бы и для отдельных проектов?


Ну я, например.

I>Использую libxml2, это библиотека на C, и решил из интереса попробовать и свой модуль, непосредственно использующий libxml2, написать на C. Сначала оно было как бы неплохо, потом хуже. Возможно с непривычки, а есть здесь те, кто предпочитает C?


libxml2 — это адъ и ужос!
Re[11]: C vs. C++
От: ДимДимыч Украина http://klug.org.ua
Дата: 12.09.12 11:31
Оценка:
Здравствуйте, igna, Вы писали:

I>Во! То есть errno не для переносимых программ.


Что имеется ввиду под "переносимыми программами"? В большинстве случаев достаточно errno со стандартными POSIX'овскими значениями ошибок. Если недостаточно, можно объявить аналогичную глобальную thread-safe переменную, или дополнительное поле в структуре контекста, и использовать по своему усмотрению.
Также можно возвращать код ошибки непосредственно из функции, если очень уж хочется (как сделано в pthreads).
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
Re[2]: C vs. C++
От: Pzz Россия https://github.com/alexpevzner
Дата: 12.09.12 11:31
Оценка:
Здравствуйте, MasterZiv, Вы писали:

MZ>Я бы только один проект писал на С -- ядро линукса. Остальные -- только на

MZ>плюсах. С так ужо убого выглядит, что просто морально нельзя его терпеть.

Непонятно как-то. Если C++ так хорош, то чем же он для ведра линуха не подходит? А если он не так уж хорош, то может есть и какие-то другие проекты, которым он не подходит?
Re[2]: C vs. C++
От: igna Россия  
Дата: 12.09.12 11:40
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>libxml2 — это адъ и ужос!


А что так?
Re[3]: C vs. C++
От: Piko  
Дата: 12.09.12 12:31
Оценка:
Здравствуйте, Pzz, Вы писали:

MZ>>Я бы только один проект писал на С -- ядро линукса. Остальные -- только на

MZ>>плюсах. С так ужо убого выглядит, что просто морально нельзя его терпеть.
Pzz>Непонятно как-то. Если C++ так хорош, то чем же он для ведра линуха не подходит? А если он не так уж хорош, то может есть и какие-то другие проекты, которым он не подходит?

если использовать C++ для ядра Linux — то
1. желательно многое переделать -> это уже будет не Linux
2. часть сообщества самовыпилится из-за не знания или отрицания C++, включая Линуса, новые члены заполнят вакуум не сразу.
3. такие потрясения нафиг никому не нужны

Что же касается использования C++ для ядер в общем, то процитирую Страуструпа, так как полностью согласен с ним:
http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Interactive-Panel-The-Importance-of-Being-Native
"Of course C++ is much better for kernel than C. I mean, who be stupid enough to say otherwise" 1:02:50
Re[4]: C vs. C++
От: igna Россия  
Дата: 12.09.12 12:41
Оценка:
Здравствуйте, Piko, Вы писали:

P>http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Interactive-Panel-The-Importance-of-Being-Native

P>"Of course C++ is much better for kernel than C. I mean, who be stupid enough to say otherwise" 1:02:50

В текстовом виде этого нет?
Re[5]: C vs. C++
От: Piko  
Дата: 12.09.12 12:45
Оценка:
Здравствуйте, igna, Вы писали:

P>>http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Interactive-Panel-The-Importance-of-Being-Native

P>>"Of course C++ is much better for kernel than C. I mean, who be stupid enough to say otherwise" 1:02:50
I>В текстовом виде этого нет?

не видел. там же есть html5 версия видео.
Re[6]: C vs. C++
От: igna Россия  
Дата: 12.09.12 12:51
Оценка:
Здравствуйте, Piko, Вы писали:

P>не видел. там же есть html5 версия видео.


Не понял.
Re[7]: C vs. C++
От: Piko  
Дата: 12.09.12 12:53
Оценка:
Здравствуйте, igna, Вы писали:

I>Не понял.


зачем текстовая версия, в чём проблема посмотреть видео?
Re[9]: C vs. C++
От: Piko  
Дата: 12.09.12 13:07
Оценка:
Здравствуйте, igna, Вы писали:

P>>зачем текстовая версия, в чём проблема посмотреть видео?

I>Долго.

я время указал — там 10минут всего

I>Нельзя использовать поиск.


зачем? там разговор про ядро минут 10

I>Надо одевать наушники.


беда

I>Заколебали своими видеопрезентациями.


это просто пруфлинк — ты можешь не проверять
Re[10]: C vs. C++
От: igna Россия  
Дата: 12.09.12 13:27
Оценка:
Здравствуйте, Piko, Вы писали:

P>зачем? там разговор про ядро минут 10


Ну поиском я мог бы поискать что-нибудь еще.

P>это просто пруфлинк — ты можешь не проверять


Проверять и не собирался, просто народ собрался интересный, хотел узнать, что они там еще говорят. Но нет, так нет.
Re[4]: C vs. C++
От: Pzz Россия https://github.com/alexpevzner
Дата: 12.09.12 14:07
Оценка:
Здравствуйте, Piko, Вы писали:

P>если использовать C++ для ядра Linux — то

P>1. желательно многое переделать -> это уже будет не Linux
P>2. часть сообщества самовыпилится из-за не знания или отрицания C++, включая Линуса, новые члены заполнят вакуум не сразу.
P>3. такие потрясения нафиг никому не нужны

Ээээ. Ну, если вы считаете, что ядро имеет смысл продолжать развивать на Си просто потому, что так исторически сложилось, непонятно, почему этот подход применяется только для ядра. Есть еще большие и ценные куски софтвария, исторически написанные на Си — те же иксы, гномий дектоп и т.п.

P>Что же касается использования C++ для ядер в общем, то процитирую Страуструпа, так как полностью согласен с ним:

P>http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Interactive-Panel-The-Importance-of-Being-Native
P>"Of course C++ is much better for kernel than C. I mean, who be stupid enough to say otherwise" 1:02:50

Страуструп никогда не умел изъясняться внятно
Re[3]: C vs. C++
От: Pzz Россия https://github.com/alexpevzner
Дата: 12.09.12 14:07
Оценка:
Здравствуйте, igna, Вы писали:

Pzz>>libxml2 — это адъ и ужос!


I>А что так?


Уровень сложности не соответствует уровню документированности, плюс слишком много "исторических наслоений".
Re[4]: C vs. C++
От: igna Россия  
Дата: 12.09.12 14:12
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Уровень сложности не соответствует уровню документированности, плюс слишком много "исторических наслоений".


А что использовать вместо libxml2 в качестве парсера HTML?
Re[5]: C vs. C++
От: Piko  
Дата: 12.09.12 16:30
Оценка:
Здравствуйте, Pzz, Вы писали:

P>>Что же касается использования C++ для ядер в общем, то процитирую Страуструпа, так как полностью согласен с ним:

P>>http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Interactive-Panel-The-Importance-of-Being-Native
P>>"Of course C++ is much better for kernel than C. I mean, who be stupid enough to say otherwise" 1:02:50
Pzz>Страуструп никогда не умел изъясняться внятно

хм, может дело не в Страуструпе?
например я его понимаю — всё достаточно внятно

P>>если использовать C++ для ядра Linux — то

P>>1. желательно многое переделать -> это уже будет не Linux
P>>2. часть сообщества самовыпилится из-за не знания или отрицания C++, включая Линуса, новые члены заполнят вакуум не сразу.
P>>3. такие потрясения нафиг никому не нужны
Pzz>Ээээ. Ну, если вы считаете, что ядро имеет смысл продолжать развивать на Си просто потому, что так исторически сложилось, непонятно, почему этот подход применяется только для ядра. Есть еще большие и ценные куски софтвария, исторически написанные на Си — те же иксы, гномий дектоп и т.п.

а вот как раз не внятно, можешь пояснить?
1. ты думаешь легко переделать всё ядро на C++ ?
2. Почему только для ядра? Если есть какое-либо другое дерьмо мамонта написанное на C, исправно выполняющее свои функции, то нахрена его переделывать на C++?
3. Гномий десктоп? да и хрен с ним — пусть живёт себе

В чём проблема-то?
Re[8]: C vs. C++
От: Piko  
Дата: 12.09.12 16:34
Оценка:
Здравствуйте, Радужный Пряник, Вы писали:

OZ1>Вот как раз COM — это лучшее и самое чистое, что когда либо сделали из C++. Если посмотреть, что там осталось от C++, то какбы наводит на некоторые мысли. Вместе с тем, что тот же COM сервер можно и на C сделать.


ты вообще о чём?

http://en.wikipedia.org/wiki/Component_Object_Model

Component Object Model (COM) is a binary-interface standard for software componentry introduced by Microsoft in 1993. It is used to enable interprocess communication and dynamic object creation in a large range of programming languages.

Re[5]: C vs. C++
От: Трололоша  
Дата: 12.09.12 17:45
Оценка:
Здравствуйте, Pzz, Вы писали:

P>>"Of course C++ is much better for kernel than C. I mean, who be stupid enough to say otherwise" 1:02:50

Pzz>Страуструп никогда не умел изъясняться внятно
Что именно тебе непонятно в этой фразе?
... << RSDN@Home >>
Да, йа зелёный тролль!
Re[7]: C vs. C++
От: Alexéy Sudachén Чили  
Дата: 12.09.12 17:50
Оценка:
MTD>1. Не понятно, что с ошибками. Обычно в C функции возвращают код ошибки, здесь мне не понятно, что будет если например вместо file передам 0.

Я обычно выбрасываю исключение. Это сильно упрощает обработку ошибок. В случае 0 должно быть исключение, но пока может и не быть, библиотека пока в стадии разработки и не все кейсы реализованы.

MTD>2. Создали arr типа YO_ARRAY, где потом arr используется? Не понятно.


Наверное там, откуда вызвали функцию.

MTD>3. Что такое Pchars? Я еще пойму просто char или там utf32, но это


В любой более менее сложной библиотеке есть свой словарь и свои концепции. Это один из элементов. В данном случае это массив с владением строками. То что строками, означает что он умеет корректно их удалять при разрушении, а также выполнять дополнительные операции, например сортировку или упорядоченную вставку.

MTD>3. Oj_Read_Line, как я понял вернет нулевой указатель когда будет достигнут конец файла. Как определить, что это не конец, а ошибка файла?


В случае ошибки будет выброшено исключение.

MTD>4. Куда помещает строку Array_Push? Из кода не понятно.


Это опечатка. Я собирал ребёнка в садик когда писал этот пример, так что проморгал. Array_Push(arr,S)

MTD>5. Для чего нужно __Retain?


Oj_Read_Line, как и большинство функций yoyo, возвращает строку жизненный цикл которой управляется авторелизпулом. __Retain снимает обьект с пула, по причине того что все контейнеры владеющие своим содержимым получают не только объект но и право владения над ним.

MTD>6. Почему местами YO, а местами Oj? Разные библиотеки?


YO_ очевидно почему, Oj_ префикс абстрактного протокола. Если объект не поддерживает протокол, будет выброшено исключение.

MTD>7. Почему локальная переменная arr, но локальная переменная S?


Элемент стиля кодирования. S — строчный объект. То есть последовательность чего бы то ни было.
Re[5]: C vs. C++
От: Alexéy Sudachén Чили  
Дата: 12.09.12 17:59
Оценка:
U>Что, это кроме тебя кто-нибудь использует? Буду очень удивлен. В коде нет комментариев. Не просто очень мало, а вообще нет. Нуль полный. Что этот код делает? Кроме создателя никто не знает. И не дай бог узнает! Коммиты тоже не блещут выразительностью. "updated", "updated", "updated", опять "updated". Что трудно для себя хотя бы написать, что ты там изменил?

Без понятия. Но скорее всего нет, я пока про эту либу кроме как на КЫВТ нигде не писал. Во-первых ещё несколько сыровато, во-вторых слишком сильно ещё всё меняется, в-третьих — я это для себя пишу, а не для кого-то.

Коммиты синхра с fossil репозиторием, другими они не будут. Да и смысла особого в стадии активного развития писать портянки о том что именно изменилось? К тому же для самого себя. Чисто для истории разве что. Слишком много чего меняется.

Кстати, про пожелания — спасибо. Надеюсь что люди не умеющие читать код, никогда этой либой пользоваться не будут. ) Потому комментарием и доки в духе доксигена там в жизни не будет.
Re[6]: C vs. C++
От: Piko  
Дата: 12.09.12 18:25
Оценка:
Здравствуйте, Alexéy Sudachén, Вы писали:

AS>Кстати, про пожелания — спасибо. Надеюсь что люди не умеющие читать код, никогда этой либой пользоваться не будут. ) Потому комментарием и доки в духе доксигена там в жизни не будет.


надо придумать некую карательную процедуру за использование комментариев типа:
/*
   Does some shit.
   Return value type - int.
   first arguments name - arg1, type double
   second arguments name - arg2, type char
*/
int do_some_shit(double arg1,char arg2){...}

у меня в уме не укладывается, как люди с более чем 10ю годами опыта могут рожать такое гуанно. а главное, как они удерживаются на своих стульях?
Re[7]: C vs. C++
От: night beast СССР  
Дата: 12.09.12 19:13
Оценка:
Здравствуйте, Piko, Вы писали:


AS>>Кстати, про пожелания — спасибо. Надеюсь что люди не умеющие читать код, никогда этой либой пользоваться не будут. ) Потому комментарием и доки в духе доксигена там в жизни не будет.


P>надо придумать некую карательную процедуру за использование комментариев типа:

P>...
P>у меня в уме не укладывается, как люди с более чем 10ю годами опыта могут рожать такое гуанно. а главное, как они удерживаются на своих стульях?

только вот не надо на доксиген гнать.
капитанские комментарии и без него пишут.
Re[9]: C vs. C++
От: night beast СССР  
Дата: 13.09.12 03:56
Оценка:
Здравствуйте, Трололоша, Вы писали:

NB>>только вот не надо на доксиген гнать.

NB>>капитанские комментарии и без него пишут.

Т>Когда принудительно внедряют doxy, особенно если стоит при коммите автопроверка и коммит не проходит если нету комментария — вот тогда комменты от Кэпа валят сотнями.


это не проблема доксигена.
при желании и молотком можно голову разбить.
Re[10]: C vs. C++
От: Трололоша  
Дата: 13.09.12 12:07
Оценка:
Здравствуйте, night beast, Вы писали:

Т>>Когда принудительно внедряют doxy, особенно если стоит при коммите автопроверка и коммит не проходит если нету комментария — вот тогда комменты от Кэпа валят сотнями.

NB>это не проблема доксигена.

Отчасти да, но Doxy тут срабатывает как катализатор.
... << RSDN@Home >>
Да, йа зелёный тролль!
Re[8]: C vs. C++
От: MTD https://github.com/mtrempoltsev
Дата: 13.09.12 16:18
Оценка:
Здравствуйте, Alexéy Sudachén, Вы писали:

AS>>>простота использования ставит C++ в какое-то непонятное положение

MTD>>Заметно. И это мы еще до обработки ошибок не дошли (ее тут нет), когда окажется, что твой код сыпется как карточный домик.

AS>И что здесь она есть?


Да.

AS>Особенно при условии что я как-то не вижу включения обработки исключений для плюсовых потоков.


Если хочешь об этом поговорить — напиши свой код с обработкой ошибок, потом напишу я.

AS>Какое кстати состояние контейнера to в случае если исключения таки включены, и где-то по ходу произошла ошибка чтения?


Консистентное.

AS>Можно ещё поинтересоваться — STL даёт возможность прочитать строчки с сети или с выхлопа чайлд-процесса? Или надо к нему ещё небольшого такого монстрика на выручку позвать?


А С дает?

AS>Ошибки здесь превосходно обрабатываются. Код автоматически устойчив к исключениям.


А если я 0 в функцию передам? А что будет если при чтении из файла будет ошибка?
Re[9]: C vs. C++
От: Alexéy Sudachén Чили  
Дата: 13.09.12 17:00
Оценка:
AS>>И что здесь она есть?
MTD>Да.

Да что ты говоришь!? Ну ладно, допустим что это даже будет работать. (в том смысле что исключения для IOstreams включены).

AS>>Особенно при условии что я как-то не вижу включения обработки исключений для плюсовых потоков.

MTD>Если хочешь об этом поговорить — напиши свой код с обработкой ошибок, потом напишу я.

Обработка ошибок зависит не от этого кода, а от того где и как он используется. Её вообще может и не быть как таковой.

AS>>Какое кстати состояние контейнера to в случае если исключения таки включены, и где-то по ходу произошла ошибка чтения?

MTD>Консистентное.

Консистентное с точки зрения контейнера, языка или контекста его использования?

AS>>Можно ещё поинтересоваться — STL даёт возможность прочитать строчки с сети или с выхлопа чайлд-процесса? Или надо к нему ещё небольшого такого монстрика на выручку позвать?

MTD>А С дает?

Хм, С как и С++ ни кому не даёт, а только берёт ))) Но, однако, моя игрушечная библиотека позволяет это сделать элементарно.

AS>>Ошибки здесь превосходно обрабатываются. Код автоматически устойчив к исключениям.

MTD>А если я 0 в функцию передам? А что будет если при чтении из файла будет ошибка?

Исключение вылетит. Причём исключения будут разные при разных ошибках. А там уж как тебе по контексту нужно ошибки обрабатывать, то и делаешь. И да, память и системные ресурсы не утекут, а корректно освободятся при броске исключения. Ужас да?
Re[9]: C vs. C++
От: Alexéy Sudachén Чили  
Дата: 13.09.12 17:01
Оценка:
AS>>В любой более менее сложной библиотеке есть свой словарь и свои концепции.
MTD>Хорошей библиотекой легко пользоваться правильно и тяжело неправильно. В твоем коде боюсь только ты разбираешься, да и то сомнительно — вон сколько сам ошибок понаделал

О! Каких если не секрет?!
Re[10]: C vs. C++
От: MTD https://github.com/mtrempoltsev
Дата: 14.09.12 04:34
Оценка:
Здравствуйте, Alexéy Sudachén, Вы писали:

AS>Да что ты говоришь!? Ну ладно, допустим что это даже будет работать. (в том смысле что исключения для IOstreams включены).


Это будет работать, а вот будет ли работать твой код для меня вопрос.

AS>Обработка ошибок зависит не от этого кода, а от того где и как он используется. Её вообще может и не быть как таковой.


Напиши код который открывает файл, читает и корректно его закрывает с учетом возникновения ошибок, тогда и поговорим.

AS>Консистентное с точки зрения контейнера, языка или контекста его использования?


С любой точки зрения.

AS>Хм, С как и С++ ни кому не даёт, а только берёт ))) Но, однако, моя игрушечная библиотека позволяет это сделать элементарно.


Моя тоже, при этом я не смогу в данный код сунуть непонятно что — он типизирован. В твоем коде работать компилятором — проверять допустимость типов, должен пользователь.

AS>Исключение вылетит. Причём исключения будут разные при разных ошибках. А там уж как тебе по контексту нужно ошибки обрабатывать, то и делаешь. И да, память и системные ресурсы не утекут, а корректно освободятся при броске исключения. Ужас да?


Напиши код который открывает файл, читает и корректно его закрывает с учетом возникновения ошибок, тогда и поговорим.
Re[10]: C vs. C++
От: Piko  
Дата: 14.09.12 10:27
Оценка:
P>>во-первых, какие-либо тесты будут? или только "экспоненциальный" трёп? а то ведь это место скользкое — push/pop, frame stuff и т.п. может стоит больше по размеру чем инлайн малюсенькой функции.
P>>во-вторых, мы вроде про оптимизацию говорим, и видимо по скорости, не? Ну а если нужна оптимизация по размеру — то и она получится лучше и безопасней на C++
SN>>Если тебе не очевидно, что при использовании шаблонов для эмуляции полиморфизма они будут развернуты с дублированием кода, то тут нечего добавить.

http://www.stroustrup.com/abstraction-and-machine.pdf

The performance of this code depends on inlining of function calls. It has correctly been observed that inlining can lead to code bloat when a large function is inlined many times (either for many different calls or for a few calls but with different template arguments).
However, that argument does not apply to small functions (such as, the += and + defined for complex) where the actual operation is smaller and faster than the function preamble and value return. In such cases, inlining provides improvements in both time and space compared with ordinary functions and ordinary function calls. In fact, a popular use of class objects and inline function is to implement parameterization where the parameter can be a single machine instruction, such as <



P>если тебе не очевидно, что дублирование может оптимизироваться до суммарных размеров меньших чем с void*, а то и вообще до нулевых, то я

P>например, напиши void* аналог std::max
Re[12]: C vs. C++
От: Трололоша  
Дата: 14.09.12 12:47
Оценка:
Здравствуйте, Alexey Sudachen, Вы писали:

MTD>>Напиши код который открывает файл, читает и корректно его закрывает с учетом возникновения ошибок, тогда и поговорим.


AS>На этом форуме уже писал и не раз, лично тебе чего-то доказывать смысла не вижу (как и кому бы то ни было вообще). Мне вот честно глубоко пофигу чего ты там считаешь относительно моего кода. Моё дело показать что можно и так, а уж нужно ли это ещё кому-то — мне глубоко фиолетово.


Слился.

AS>Вот только я не вижу смысла с тобой говорить. Кто ты такой — архитектор всия вселенной?! На твои вопросы по делу я ответил, играть же в игру 'а докажи' — мне не интересно. Более того, как бы очевидно как это работает, если тебе не, то может стоит немного поуменьшить ЧСВ?


Значит нельзя у тебя это вменяемо реализовать.
... << RSDN@Home >>
Да, йа зелёный тролль!
Re[13]: C vs. C++
От: Alexéy Sudachén Чили  
Дата: 14.09.12 14:56
Оценка:
Т>Слился.

Любитель туалета? Как хочешь назови, мене фиолетово. Аффтор топика, на который я отвечал, даже проблем с типичным плюсовым кодом не видит, смысл играть с ним в игру 'докажи мне что ...'. Это будет скучно и нудно.

AS>>Вот только я не вижу смысла с тобой говорить. Кто ты такой — архитектор всия вселенной?! На твои вопросы по делу я ответил, играть же в игру 'а докажи' — мне не интересно. Более того, как бы очевидно как это работает, если тебе не, то может стоит немного поуменьшить ЧСВ?

Т>Значит нельзя у тебя это вменяемо реализовать.

Сырки доступны, взял да посмотрел. Ты смотрел?

Однако тут зарыт серьёзный проблемс. Многие 'типа C++ профессионалы' код-то толком читать не умеют. Впрочем, я уже здесь (на форуме) это всё показывал, с весьма подробными объяснениями. Если не осилил, так и скажи. Видимо потому я так и не увидел ни одного серьёзного комментария. Всё в духе ... А-А-А-А, у него макросы!!! А-А-А-А, я не знаю что так можно писать switch!!! А-А-А-А, C не нужен, он рвёт мой шаблон!!! А-А-А-А-А я тоже тролль!!!! И ничего по существу. Там ведь реально есть что по существу нужно переделать и улучшить, но это же код нужно уметь читать.

Ведь мы же все знаем что уметь читать и понимать чужой код — плохо. ))) С таким навыком тебя стопроцентно посадЮт разбираться к копролите мамонта доставшемся компании от предыдущих мастеров клавиатуры. Ну его нафиг развивать такой навык, ага?
Re[14]: C vs. C++
От: Piko  
Дата: 14.09.12 16:33
Оценка:
Здравствуйте, Alexéy Sudachén, Вы писали:

AS>А-А-А-А, я не знаю что так можно писать switch!!! А-А-А-А, C не нужен, он рвёт мой шаблон!!!


ну если ты не помнишь, у меня претензии к твоему макродрочерству, появились ровно после твоих бравад о том как переход с С++ на C привёл, к цитирую:

AS>>Ну, по причине неадекватной сложности, ведущей к постоянной борьбе с языком, и постоянного вынужденного скатывания к синтаксическому онанизму. Плюс к тому ещё и высокая сложности разбора крешей в случае использования 'правильных' либ.
AS>>Привело к серьёзному упрощению кода, который теперь можно понять не изучая в течении нескольких лет методы высокой магии и прорицания в пространствах синтаксических подсластителей.

http://www.rsdn.ru/forum/cpp/4735144.1
Автор: Piko
Дата: 12.05.12

Re[14]: C vs. C++
От: Трололоша  
Дата: 14.09.12 17:14
Оценка:
Здравствуйте, Alexey Sudachen, Вы писали:

AS>Сырки доступны, взял да посмотрел. Ты смотрел?

Раз ты сам отказываешься показать как это выглядит — значит не тривиально.
Посылаешь читать твой же код — значит хочешь чтоб отстали.
... << RSDN@Home >>
Да, йа зелёный тролль!
Re[15]: C vs. C++
От: Alexéy Sudachén Чили  
Дата: 14.09.12 18:32
Оценка:
AS>>Сырки доступны, взял да посмотрел. Ты смотрел?
Т>Раз ты сам отказываешься показать как это выглядит — значит не тривиально.
Т>Посылаешь читать твой же код — значит хочешь чтоб отстали.

Я вообще-то уже показывал. ) В данном случае персонажа не интересует как это делается, равно как и тебя.
Re[16]: C vs. C++
От: Трололоша  
Дата: 14.09.12 19:41
Оценка:
Здравствуйте, Alexey Sudachen, Вы писали:

AS>Я вообще-то уже показывал. ) В данном случае персонажа не интересует как это делается, равно как и тебя.


Ты погоди кипеть и булькать.
Приведи плз целиком кусок кода с чтением и обработкой ошибок. А то твоё "показывал" почему то по веткам не находится а из отдельных фраз что то нецензурное получается.
... << RSDN@Home >>
Да, йа зелёный тролль!
Re[17]: C vs. C++
От: Alexéy Sudachén Чили  
Дата: 14.09.12 22:25
Оценка:
P>обсуждалось раньше 1999 года? ну может быть, не спорю, я хз когда rsdn появился
P>я в 99 был в 2:50X/Y.Z

Круто, да. А чего ж у тебя аккаунт такой новый?

P>я не знаю что там тебе льстит, но конкретно эти макросы как раз и есть синтаксический онанизм, к которому тебе "приходилось" скатываться при использовании C++


Ага-ага, что там было в недавних обсуждениях? Куда уж моим сирым маросом до shared_ptr'а по простоте, логичности и количеству строк кода. ))) Ах да я забыл, это ж типа стандартная либа, она нулевого размера, и аксиоматична по природе, не зависимо от размера граблей и толщины мануала.
Re[18]: C vs. C++
От: Трололоша  
Дата: 14.09.12 22:44
Оценка:
Здравствуйте, Alexey Sudachen, Вы писали:

AS>Круто, да. А чего ж у тебя аккаунт такой новый?

Потому что политика модерирования тут бывает забавная.
... << RSDN@Home >>
Да, йа зелёный тролль!
Re[18]: C vs. C++
От: Piko  
Дата: 14.09.12 22:59
Оценка:
Здравствуйте, Alexéy Sudachén, Вы писали:

P>>обсуждалось раньше 1999 года? ну может быть, не спорю, я хз когда rsdn появился

P>>я в 99 был в 2:50X/Y.Z
AS>Круто, да. А чего ж у тебя аккаунт такой новый?

на RSDN?
я до этого не пользовался им

P>>я не знаю что там тебе льстит, но конкретно эти макросы как раз и есть синтаксический онанизм, к которому тебе "приходилось" скатываться при использовании C++

AS>Ага-ага, что там было в недавних обсуждениях? Куда уж моим сирым маросом до shared_ptr'а по простоте, логичности и количеству строк кода. ))) Ах да я забыл, это ж типа стандартная либа, она нулевого размера, и аксиоматична по природе, не зависимо от размера граблей и толщины мануала.

мой поинт том, что ты говоришь, что на C++ приходится скатываться к синтаксическому анонизму, ай-ай-ай.
говоришь что использование C привело к упрощению, хотя по факту используешь как минимум не меньший анонизм, который к тому же, не смотря на меньший размер языка C, не все крупные компиляторы могут прожевать.
какие-то двойные стандарты, не находишь?
Re[19]: C vs. C++
От: Piko  
Дата: 14.09.12 23:08
Оценка:
Здравствуйте, Piko, Вы писали:

P>>>обсуждалось раньше 1999 года? ну может быть, не спорю, я хз когда rsdn появился

P>>>я в 99 был в 2:50X/Y.Z
AS>>Круто, да. А чего ж у тебя аккаунт такой новый?
P>на RSDN?
P>я до этого не пользовался им

кстати, продолжая рвать шаблон, я не пользуюсь ни facebook'ом, ни вконтакте, и ни разу в жизни не создавал там аккаунты.
я что-то делаю не так?
Re[19]: C vs. C++
От: Alexéy Sudachén Чили  
Дата: 14.09.12 23:12
Оценка:
P>мой поинт том, что ты говоришь, что на C++ приходится скатываться к синтаксическому анонизму, ай-ай-ай.
P>говоришь что использование C привело к упрощению, хотя по факту используешь как минимум не меньший анонизм, который к тому же, не смотря на меньший размер языка C, не все крупные компиляторы могут прожевать.
P>какие-то двойные стандарты, не находишь?

Нет не нахожу. Как бы я вижу разницу между несколькими макросами используемыми весьма и ваесьма редко, и целой кучей разнородных граблей вкупе с правильным подходом и сопутствующей религией.

Прежёвывают ВСЕ компиляторы. Конкретно в Intel'е был баг. Настоящий махровый баг. Исправили они его или нет, я не знаю. Не пользуюсь. Но таки, да, проверю.
Re[19]: C vs. C++
От: Alexéy Sudachén Чили  
Дата: 14.09.12 23:13
Оценка:
AS>>Круто, да. А чего ж у тебя аккаунт такой новый?
Т>Потому что политика модерирования тут бывает забавная.

И в чём же её забавность?!
Re[20]: C vs. C++
От: Alexéy Sudachén Чили  
Дата: 14.09.12 23:16
Оценка:
P>>я до этого не пользовался им
P>кстати, продолжая рвать шаблон, я не пользуюсь ни facebook'ом, ни вконтакте, и ни разу в жизни не создавал там аккаунты.
P>я что-то делаю не так?

Не знаю. У меня есть, и бывают весьма и весьма полезны. Но у меня и интересы выходят за круг C++ и копьютеров, а люди с которыми я общаюсь живут по всему шарику. Может быть в этом дело?
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.