Re[2]: И снова про ц++
От: okman Беларусь https://searchinform.ru/
Дата: 03.02.12 07:59
Оценка: 7 (3) -2 :))) :))) :)))
Здравствуйте, x-code, Вы писали:

XC>Ужасная система #include и препоцессора, отсутствие нормальной модульной системы


А яблоня лучше электрического фонаря, потому что дает яблоки.

XC>Отсутствие вложенных блочных комментариев


Яблоня растет сама, а фонарь нужно сделать, вкопать, подвести провода и электрический ток.

XC>Имя массива является адресом первого элемента массива (нелогично! со структурами же не так)


Яблоня не ломается.

XC>Отсутствие низкоуровневых возможностей: sizeof( ) от функции и блока кода, goto на переменные метки (в gcc есть, но это нестандартно)


Яблоня каждую осень сбрасывает листья, а весной цветет. Красиво !

XC>Невозможность передачи массивов в фигурных скобках "как есть" в функции Foo({1,2,3});


На фонарь нельзя залезть — нет веток и может убить током.

XC>Отсутствие именованных блоков кода, соответственно невозможность сделать break и continue на именованный блок/из блока


Фонарь не укроет в дождливый день...

XC>Отсутствие методов-расширений, отсутствие возможности обращаться к методу класса как к статическому с явной (ручной) передачей this


...и не защитит от солнца.

XC>Отсутствие системы сообщений как в ObjectiveC, встроенной системы сигналов и слотов как в QT


Никто не лазает в чужой огород тырить яблоки с фонарей. А с яблонь — да.

XC>Невозможность создания namespace внутри класса (вспомните хотя-бы "главные оконные классы" разных библиотек — CWnd, QWidget... сотни методов, там разделение не помешало бы)


Яблони бывают разных видов — антоновка, например. А фонари почти везде одинаковые.

XC>Отсутсвие вложенных функций (даже в турбо паскале вроде были), а лямбды в C++11 на редкость кривые


У яблонь не перегорает и не разбивается лампочка.

XC>Отсутствие замыканий, простого объявления функциональных типов (int=>int)


Яблони не ставят на тротуарах, поэтому в них почти никогда не врезаются автомобили.

XC>Отсутствие кортежей, групповых операций над кортежами, невозможность вернуть из функции несколько значений напрямую


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

XC>Отсутствие опциональной возможности структуной типизации


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

XC>Оператор :: вместо точки (некрасиво)


Яблоня более красива, чем фонарь.

XC>Ужасно громоздкая система шаблонов (каждый раз писать template), и тенденция использования шаблонов не по назеначению (метапрограммирование на них)


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

XC>При этом отсутсивие полноценной системы метапрограммирования (типа как в Nemerle, хотя я бы сделал еще лучше)


Многие фонари светят почему-то не белым, а каким-то желтым или фиолетовым светом. Я бы сделал лучше.

XC>Отсутствие полноценной рефлексии и атрибутов (как в C#)


С яблони можно сорвать ветку и отбиться ею от напавшей собаки или хулиганов.
Проектировщики фонаря такой возможности в нем не предусмотрели.

XC>Отсутствие встроенной параллельности и каналов (как в Go)


Если поставить рядом две яблони, яблок будет больше.
А если два фонаря — света останется столько же.

XC>Отсутствие свойств (properties) как в C# (хотя и в C# можно еще кое-что улучшить)


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

XC>Да еще много чего, сразу все и не вспомнить...


У фонаря еще много-много недостатков, на самом-то деле...
Re: И снова про ц++
От: x-code  
Дата: 03.02.12 05:22
Оценка: 2 (1) +2 :))) :))) :)))
Здравствуйте, Sheridan, Вы писали:

S>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++? Указатели? Да фигня это, на пару граблей наступить и рефлекс появится. Зато более шустрый софт получается.

S>Так все же?

Ужасная система #include и препоцессора, отсутствие нормальной модульной системы
Отсутствие вложенных блочных комментариев
Имя массива является адресом первого элемента массива (нелогично! со структурами же не так)
Отсутствие низкоуровневых возможностей: sizeof( ) от функции и блока кода, goto на переменные метки (в gcc есть, но это нестандартно)
Невозможность передачи массивов в фигурных скобках "как есть" в функции Foo({1,2,3});
Отсутствие именованных блоков кода, соответственно невозможность сделать break и continue на именованный блок/из блока
Отсутствие методов-расширений, отсутствие возможности обращаться к методу класса как к статическому с явной (ручной) передачей this
Отсутствие системы сообщений как в ObjectiveC, встроенной системы сигналов и слотов как в QT
Невозможность создания namespace внутри класса (вспомните хотя-бы "главные оконные классы" разных библиотек — CWnd, QWidget... сотни методов, там разделение не помешало бы)
Отсутсвие вложенных функций (даже в турбо паскале вроде были), а лямбды в C++11 на редкость кривые
Отсутствие замыканий, простого объявления функциональных типов (int=>int)
Отсутствие кортежей, групповых операций над кортежами, невозможность вернуть из функции несколько значений напрямую
Отсутствие опциональной возможности структуной типизации
Оператор :: вместо точки (некрасиво)
Ужасно громоздкая система шаблонов (каждый раз писать template), и тенденция использования шаблонов не по назеначению (метапрограммирование на них)
При этом отсутсивие полноценной системы метапрограммирования (типа как в Nemerle, хотя я бы сделал еще лучше)
Отсутствие полноценной рефлексии и атрибутов (как в C#)
Отсутствие встроенной параллельности и каналов (как в Go)
Отсутствие свойств (properties) как в C# (хотя и в C# можно еще кое-что улучшить)

Да еще много чего, сразу все и не вспомнить...
Re[3]: И снова про ц++
От: Andrey.V.Lobanov  
Дата: 03.02.12 08:44
Оценка: 1 (1) +3 -2 :)
Здравствуйте, Sheridan, Вы писали:

S>>>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++?

AVL>>слабая маркетинговая составляющая
S>Каким боком маркетинг относится к языку программирования?
да напрямую. ц++ старый, следовательно немодный/беспонтовый/ненужный и т.д.
массовым погромистам гораздо проще развешивать лапшу прикрываясь всякими С# 100500 / мета- / фукнциональное программирование / лямбды / монады / linq / макросы / прочая фигня. а да, виртуальные машины забыл, тоже модная тема.
Re[14]: namespace'ы в классах
От: Mamut Швеция http://dmitriid.com
Дата: 05.02.12 09:49
Оценка: 1 (1) +5 :)
M>>И вообще, все написано тут: http://rsdn.ru/forum/janus/3486216.1.aspx
Автор: Anton Batenev
Дата: 30.07.09

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

Могу сказать ровно одно: слава богу, что в опенсорсе таких идиотов подавляющее меньшинство. Иначе опенсорса не существовало бы, как класс.


dmitriid.comGitHubLinkedIn
Re[12]: И снова про ц++
От: okman Беларусь https://searchinform.ru/
Дата: 04.02.12 05:46
Оценка: +6 -1
Здравствуйте, Cyberax, Вы писали:

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


S>>Да ладно? У строки есть метод sendtoserver? Пример крайне неудачен.

C>Нет, есть extension-метод SendToServer.

Ну вот если вдуматься, такой метод у строки (пусть и extension) — это нормально ?
По-моему, это пример плохо продуманного дизайна.
А если SendToServer занимает продолжительное время и ее надо будет использовать асинхронно ?
Что дальше — лепим туда еще и мьютекс, рабочий поток, нотификаторы и механизм отмены ?
Re[2]: И снова про ц++
От: jazzer Россия Skype: enerjazzer
Дата: 03.02.12 06:55
Оценка: 4 (3) +2 -1
Здравствуйте, x-code, Вы писали:

Тут уже ответили в основном, так что фрагментарно:

XC>Отсутствие системы сообщений как в ObjectiveC, встроенной системы сигналов и слотов как в QT

Boost.Signal

XC>Отсутсвие вложенных функций (даже в турбо паскале вроде были), а лямбды в C++11 на редкость кривые

в чем кривость лямбд по сравнению с локальными функциями?

XC>Отсутствие замыканий, простого объявления функциональных типов (int=>int)

std::function<int(int)>

XC>Отсутствие кортежей, групповых операций над кортежами, невозможность вернуть из функции несколько значений напрямую

std::tuple, auto, decltype

XC>Отсутствие опциональной возможности структуной типизации

Boost.MPL

XC>Отсутствие полноценной рефлексии и атрибутов (как в C#)

XC>Отсутствие встроенной параллельности и каналов (как в Go)
XC>Отсутствие свойств (properties) как в C# (хотя и в C# можно еще кое-что улучшить)

XC>Да еще много чего, сразу все и не вспомнить...

Давай подскажу: отсутствие монад как в Хаскеле, отсутствие зависимых типов как в Агда-2, отсутствие eval как в Перле, отсутствие значимых отступов как в Питоне... ну и далее по списку
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[5]: И снова про ц++
От: Философ Ад http://vk.com/id10256428
Дата: 03.02.12 09:08
Оценка: +3 -2 :)
Здравствуйте, Sheridan, Вы писали:

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


M>>>>А так: C++ можно не любить хотя бы за отсутсвие вменяемых строк. Хотя твой мозг отказывается понимать, что строки — это не последовательность char'ов, это так.

S>>>std::string чем невменяемо?
M>>Мультибайтные кодировки.
S>std::wstring?

нелюблю C++
строки должны быть единственными
а тут только в std уже 2 варианта
Всё сказанное выше — личное мнение, если не указано обратное.
Re[2]: И снова про ц++
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.02.12 06:39
Оценка: 1 (1) +4
Здравствуйте, x-code, Вы писали:

S>>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++? Указатели? Да фигня это, на пару граблей наступить и рефлекс появится. Зато более шустрый софт получается.

S>>Так все же?
XC>Ужасная система #include и препоцессора,

Для своих задач препроцессор вполне адекватен. С другой стороны, ничто не мешает при необходимости сделать над ним что-то своё. Например, на m4, не к ночи будь сказано (но всё равно для мелких задач начинают выбор с него) или на любом другом макропроцессоре, какой понравится.
Qt использует moc фактически как препроцессор. При наличии нормально управляемой автоматизированной системы сборки проекта (которую в общем случае сделать в Unix в разы легче, чем в конкурентах) это совершенно перестаёт быть проблемой.

XC> отсутствие нормальной модульной системы


Если речь про схему в стиле Вирта (тут interface, а тут implementation), то несложно заметить, что почему-то она не прижилась в промышленности и не была принята ни в одном языке, начатом "с нуля", заведомо позже массового распространения Паскаля. Например, она не была принята ни в Java ни в C#. Зато подход с заголовочными описаниями распространяется практически на все языки. Я думаю, у "нормальной модульной системы" всё-таки есть какой-то фатальный недостаток.

XC>Отсутствие вложенных блочных комментариев


Блочных — это потоковых или блоками целых строк? Первое — сомнительное удовольствие, потому что чревато ошибками при комментировании, а для второго #if 0 ... #endif работает достаточно неплохо.
Я бы ещё как-то понял вариант вложения с двумя разными ограничителями комментариев, один из которых рекомендуется для собственно многострочных комменатриев, а второй — для блочного выключения кода. Но если блочно выключается именно код, то тот же #if 0 достаточен (и сам он гарантированно вкладывается с достаточным для практически значимых случаев уровнем).

XC>Имя массива является адресом первого элемента массива (нелогично! со структурами же не так)


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

XC>Отсутствие низкоуровневых возможностей: sizeof( ) от функции и блока кода, goto на переменные метки (в gcc есть, но это нестандартно)


sizeof() функции не должно быть, потому что эта операция в принципе некорректна. Функция может быть разорвана на несколько частей. Точка входа не обязательно находится в начале функции (типично в случае оптимизации при наличии цикла в самом начале). Функция может использовать дополнительные поля констант, которые размещаются на фиксированном смещении от её тела (этот стиль рекомендуется для нескольких архитектур, таких, как x86-64 (адресация от %rip), mips, arm, s390), и они фактически являются тоже элементами функции. Хвосты кода или поля констант нескольких функций могут быть объединены. Чего именно размер в этом случае будем брать?

XC>Невозможность передачи массивов в фигурных скобках "как есть" в функции Foo({1,2,3});


Константный массив лечит эту проблему.

XC>Отсутствие именованных блоков кода, соответственно невозможность сделать break и continue на именованный блок/из блока


С этим я согласен — фишка была бы очень полезной.

XC>Отсутствие методов-расширений, отсутствие возможности обращаться к методу класса как к статическому с явной (ручной) передачей this


Что такое методы-расширения я не понял.
Вызов метода как статического — а зачем? Если он невиртуальный, то имя класса известно, а если виртуальный, то квалификатора const достаточно, чтобы не влиять на текущий объект. Конечно, в чём-то было бы удобнее показать, что метод в принципе не использует данных реального объекта, кроме VMT, но всё равно реальный объект нужен ради той же VMT со ссылкой на метод.

XC>Отсутствие системы сообщений как в ObjectiveC, встроенной системы сигналов и слотов как в QT


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

XC>Невозможность создания namespace внутри класса (вспомните хотя-бы "главные оконные классы" разных библиотек — CWnd, QWidget... сотни методов, там разделение не помешало бы)


В принципе согласен. Более того, система namespace неудобна.
Постоянно хочется решений в стиле питоновского import X.Y.Z as W.

XC>Отсутсвие вложенных функций (даже в турбо паскале вроде были),


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

XC> а лямбды в C++11 на редкость кривые

XC>Отсутствие замыканий,

Вот для замыканий неплохо бы было увидеть библиотеку в стиле boost, но для C.
Чтобы умела хотя бы для основных платформ генерировать замыкания.
Glib не предлагать — может, функционально и неплоха, но от её стиля меня тошнит, и задачу сделать замыкание, видимое просто как указатель на функцию, она всё равно не решает.

XC> простого объявления функциональных типов (int=>int)


Ну это уже Вы сурово разогнались.

XC>Отсутствие кортежей, групповых операций над кортежами, невозможность вернуть из функции несколько значений напрямую


Да, было бы неплохо.

XC>Отсутствие опциональной возможности структуной типизации


?

XC>Оператор :: вместо точки (некрасиво)


Согласен, но непринципиально.

XC>Ужасно громоздкая система шаблонов (каждый раз писать template), и тенденция использования шаблонов не по назеначению (метапрограммирование на них)


+100.

XC>При этом отсутсивие полноценной системы метапрограммирования (типа как в Nemerle, хотя я бы сделал еще лучше)

XC>Отсутствие полноценной рефлексии и атрибутов (как в C#)

Это очень дорого и смысл сомнителен.

XC>Отсутствие встроенной параллельности и каналов (как в Go)


Это возлагается на библиотеки.

XC>Отсутствие свойств (properties) как в C# (хотя и в C# можно еще кое-что улучшить)


Да, было бы неплохо.

XC>Да еще много чего, сразу все и не вспомнить...


The God is real, unless declared integer.
Re: Подытожим?
От: Sheridan Россия  
Дата: 06.02.12 04:46
Оценка: 1 (1) +2 -2
Чтож, печально все. Основным минусом плюсов, как выясняется, является его мощность и универсальность.
Программисты боятся
а) дефайнов
б) указателей
Также программистам неудобно программировать на плюсах ввиду отсутствия в нем некоторых ништяков, к которым они привыкли.
Обе первые болезни вполне успешно лечатся изучением самого языка и предметной области более плотно. А также выделением на первых порах большего времени на поиски багов. Третья болезнь иногда может вылечиться реализацией отсутствующего функционала самостоятельно. Но чаще всего это просто некая привычка.
Как говорил товарищь Прутков — "зри в корень". И то и другое и третье имеют общий корень и имя ему — "лень"
Matrix has you...
Re[6]: И снова про ц++
От: okman Беларусь https://searchinform.ru/
Дата: 03.02.12 10:08
Оценка: +3 -1 :)
Здравствуйте, Философ, Вы писали:

Ф>строки должны быть единственными

Ф>а тут только в std уже 2 варианта

Спорно.
Допустим, для какой-то задачи мне нужны очень компактные, пусть и не быстрые, строки.
Стандартная std::string не подходит, так как на 32-битных системах весит "аж" 24 байта.
Зато есть CString (MFC), QString (Qt) и всякие велосипеды, при желании можно найти или
собрать реализацию с объектами размером в указатель.
Прелесть в том, что C++ позволяет выбирать.
Re: И снова про ц++
От: Artifact  
Дата: 03.02.12 17:28
Оценка: 1 (1) +2 -1
Здравствуйте, Sheridan, Вы писали:

В С++ очень много чего понапихано. В руках профессионала-одиночки или группы профессионалов это всё зашибись. Но в большом коллективе надо вводить жёсткие правила, по тому что как и где писать и использовать, чего конечно никто не делает, поэтому получаем кучу непонятного, неподдерживаемого кода на выходе. В Джаве, например, всегда можно как-то худо бедно жить даже с самым дерьмовым кодом, потому как код там везде однородный, но не в С++.

Вобщем плох он для быдлокодеров.

На мой взгляд С++ это не готовый язык, это такой набор "Сделай сам", отсюда все и жалобы — мол я хотел уже что-то готовое. Извините, на что вы лично способны, то в результате и получите. Однако людям, то, на самом деле нужен язык вроде Делфи, а не С++, а покупатель всегда прав. С++ слишком сложен — заявляют они. С++ не делает выбор за человека, он не направляет его в единственно правильное и возможное русло и это фактически всё. Если вы уже умеете программировать, то у вас не должно возникнуть проблем с С++. Ну будете ныть, что вам не хватает фишки из языка Х, а в целом будете писать такой же код как вы писали раньше. Если вы программировать ещё не умеете, то С++ вас оному не научит, никто вас не освобождает от необходимости знать зачем, что и как в этом языке устроено, начиная фактически с азов, прежде чем тупо копи-пастить какой-нибудь код из туториала.
__________________________________
Не ври себе.
Re[3]: И снова про ц++
От: Artifact  
Дата: 03.02.12 20:59
Оценка: 1 (1) -1 :))
Здравствуйте, hattab, Вы писали:

H>Не хочешь ли ты сказать, что та же дельфя делает какой-то выбор, куда-то направляет?


Я хочу сказать, что в том же Дельфи, если вы даёте незнакомому человеку задание, вы приблизительно догадываетесь какой именно код он напишет. C++ в этом плане непредсказуем.
__________________________________
Не ври себе.
Re[27]: И снова про ц++
От: jazzer Россия Skype: enerjazzer
Дата: 08.02.12 13:59
Оценка: 1 (1) +2 -1
Здравствуйте, _d_m_, Вы писали:

___>И сколько этого ансейфа в реальной жизни? Много лет пишу на шарпе еще ни разу не использовал — нет необходимости.


Вот почему-то когда нечто такое говорит шарпер — ему полагается верить.
А если какой-нть плюсовик-затейник (например, я) скажет, что уже и не вспомнит, когда последний раз писал явный delete и/или возился с расстрелом памяти, то кто ж ему поверит, кроме таких же плюсовиков
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re: И снова про ц++
От: InfoPilot  
Дата: 03.02.12 20:15
Оценка: +2 -1 :)
Здравствуйте, Sheridan, Вы писали:

S>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++? Указатели? Да фигня это, на пару граблей наступить и рефлекс появится. Зато более шустрый софт получается.

S>Так все же?

С++ как высшая математика, не каждый его понимает и не каждому она доступна по умственному потенциалу, но с помощью него делаются реальные вещи.
Re: И снова про ц++
От: Young yunoshev.ru
Дата: 03.02.12 20:22
Оценка: -2 :))
Здравствуйте, Sheridan, Вы писали:

S>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++? Указатели? Да фигня это, на пару граблей наступить и рефлекс появится. Зато более шустрый софт получается.

S>Так все же?

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

Это же лепота — присвоил переменной значение — и уверен что ее никто уже не поменяет, вызвал функцию — и уверен, что она ни на что не повлияет.

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

Неее, такое нам не нужно. Нам логических ошибок хватает....
Re[13]: namespace'ы в классах
От: Sheridan Россия  
Дата: 05.02.12 09:32
Оценка: -4
Здравствуйте, Mamut, Вы писали:

M>>>- ты не согласовал свои изменения с другими членами команды

S>>Так вот почему разработка всегда затягивается — бюрократия везде, ага.
M>Нет. Без согласования работы всегда будет бардак. Потому что каждый будет делать то, что ему интересно, а не то, что нужно для проекта.
Вот когда мне будут за код платить деньги — я буду делать то что надо. До тех пор я буду делать то, что мне интересно.

M>>>- вместо инекрементальных изменений ты все вывалил в кучу одним скопом, который невозможно смерджить в основную ветку без лома и такой-то матери

S>>Ну да, мне надо было конечно делать полторы сотни коммитов, которые невозможно смержить вместо одного такого. Ты заметил, что изменения крупные, можно сказать кардинальные я сделал или нет? Какие твои предложения на предмет безгемморного внесения таких изменений?
M>Согласовать их с другими членами команды в первую очередь. И после согласования и определения приоритетов будет понятно, что, куда и — главное — как надо двигаться
На приоритеты мне посрать до тех пор пока мне за код не платят деньги.


M>>>- попутно ты поломал ключевой функционал и отказался его чинить

S>>Не лги. Починил. http://www.rsdn.ru/forum/janus/3488009.1.aspx
Автор: Sheridan
Дата: 31.07.09


M>Дададада. Буквально следующее сообщение. http://www.rsdn.ru/forum/janus/3489032.aspx
Автор: cencio
Дата: 31.07.09
. Ну, не говоря о том, что такой поломки вообще произойти не должно было (читаем исходную проблему
Автор: Sheridan
Дата: 31.07.09
— кодировка поломана, код не компилится).

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


S>>А вот ты помогать отказывался
Автор: Mamut
Дата: 24.08.09
.

M>Именно. Я указал причины
Автор: Mamut
Дата: 24.08.09
и не стал лезть что-либо ломать. В отличие от.

ойойой. Как благородно прикрыта лень.

M>И вообще, все написано тут: http://rsdn.ru/forum/janus/3486216.1.aspx
Автор: Anton Batenev
Дата: 30.07.09

Мне повторить про движущие силы? Могу с подробностями.
Пробудить во мне помочь какому либо проекту меня могуд два фактора. Во первых я могу сам увидеть и понять что мне интересно чтото реализовать в нем. В этом случае я сажусь и реализовываю то что мне интересно. В данном случае мне поплевать на проблемы остальных участников. Тем более если в репозиторий коммиты идуд дай бог если раз в пару дней. Для меня это значит что над проектом практически не работают и у меня вообще развязаны руки. И только после реализации того что мне интересно и починки возникших в там багов я буду браться за то, что не получается реализовать у других изза отсутствия у них времени\знаний\опыта.
И второй фактор, как то не банально, деньги. Платите мне и говорите что в проекте делать.
Matrix has you...
Re[2]: Подытожим?
От: blackhearted Украина  
Дата: 07.02.12 16:12
Оценка: +2 :))
Здравствуйте, Sheridan, Вы писали:

S>Чтож, печально все. Основным минусом плюсов, как выясняется, является его мощность и универсальность.

Не-а.
Основной минус плюсов — это то, что на нём писать лезут ребята, которым, по-хорошему, больше скриптов конфигурирования ничего писать нельзя.
А т.к. они упорные Линуксоиды и их любимый дистр написан на сях(что != C++, но похоже), то java — в болото, .net — sucks ибо МС.
Поэтому они "прошаривают" указатели и периодически вбрасывают свои бредни, а когда сливают — тихонько продолжают "обсуждение" в других подветках.
Re[15]: И снова про ц++
От: blackhearted Украина  
Дата: 09.02.12 09:30
Оценка: +3 -1
Здравствуйте, Sheridan, Вы писали:

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


S>Да ладно? Ты действительно не понимаешь, что "Если мне интересно — буду писать как хочу" работает до тех пор, пока "мне за код не платят деньги"?


Не понимаю.
Зачем ты тогда лезешь в бесплатные проекты, если тебе пофиг на остальную команду?
Форкай его весь себе, если это разрешено, и показывай как нужно сделать.
А то выходит, что ты лезешь в командный репо, всё там "делаешь как надо", а когда с тебя начинают спрашивать говоришь "не платите — пишу как хочу" и потом удивляешься, что твои "изменения" не принимают.
Re[7]: namespace'ы в классах
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 14.02.12 08:19
Оценка: +3 :)
Здравствуйте, Sheridan, Вы писали:

P>>А прикинь, как математики измельчали. Не хотят почему-то использовать римские цифры при записи чисел. Перешли на позиционные системы счисления. И теперь любой школьник выполняет арифметические действия без особых проблем. Не хотят разбираться в римских цифрах, считают их источником ошибок и тратой времени.

S>Ой передергиваешь. Римские цифры от арабских отличаются только при письме. Считать надо ровно также уметь.

Даже если считаешь в уме в десятичных, но пишешь и читаешь в римских — будет масса тривиальных ошибок из-за конверсии. А теперь расскажи, как ты будешь умножение или деление столбиком делать в римских цифрах? Каким образом из логики следует, что CCXXII * II == CDXLIV?
Признайся, что ты это написал не подумав более трёх секунд.

S> И если математика попросить римскими цифрами писать — он недельку привыкать будет, а потом обратно в колею войдет.


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

S>А вот ежели шарпея например или там заводчиков земноводных вдруг за ц++ посадить — ВНЕЗАПНО окажется что ой. Не хватает в головах и надо доучиваться.


Тут в целом согласен, что переход сложен. Но твои акценты сомнительны. В случае C++ сложность заметно другая. Если сейчас "шарпей" пересядет на C++, из того, что он потеряет и заметит это, будет в первую очередь Linq, во вторую делегаты и замыкания — эти фичи отсутствуют совсем на C++ или очень тяжело эмулируются. А ведь это средства уровнем выше, чем любые штатные средства C++. Да, он получит весь арсенал C вплоть до прямого ассемблера, но нужно ли это было ему для прежних задач?
The God is real, unless declared integer.
Re[9]: И снова про ц++
От: Mamut Швеция http://dmitriid.com
Дата: 06.02.12 21:43
Оценка: 6 (3)
S>>>>>std::wstring?

M>>>>И в любом случае они, в основном, позволяют хранить и выводить текст, но не позволяют других манипуляций. Не говоря уже о «удобстве» иметь два набора функций для манипуляции типа strlen и wcslen и т.п.


J>>>если ты юзаешь (w)string, то надо просто позвать у него метод size(), никаких двух наборов тут нет


M>>То есть strlen и ecslen мне приснились?


J>Да, в горячечном сишном бреду.


Да, ошибся, признаю


dmitriid.comGitHubLinkedIn
Re[3]: И снова про ц++
От: Философ Ад http://vk.com/id10256428
Дата: 03.02.12 07:37
Оценка: 2 (1) -1 :)
Здравствуйте, LaptevVV, Вы писали:

LVV>Здравствуйте, x-code, Вы писали:


XC>>Имя массива является адресом первого элемента массива (нелогично! со структурами же не так)

LVV>ИМХО для С это было самое то! Но для С++, который позиционируется как язык более высокого уровня, — это анахронизм.

Это хорошая демонстрация корявости синтаксиса.

Если ЦПП позиционируется как язык более высокого уровня, то в нём вообще не должно быть даже намёка на strlen/strcpy (а так же calloc/malloc/memcpy).
C отдельно, ЦПП отдельно (так же как асм отделили от ЯВУ).

По какой-то странной причине от специалиста по C не требуют знаний асма, а вот с ЦПП — наоборот.
Солидная часть вопросов на собеседованиях по ЦПП по сути являются вопросами по C, о чем это говорит?

ЗЫ: ЦПП — мутант переходного периода.
Всё сказанное выше — личное мнение, если не указано обратное.
Re[8]: И снова про ц++
От: ambel-vlad Беларусь  
Дата: 03.02.12 17:44
Оценка: 2 (2) -1
Здравствуйте, Философ, Вы писали:

Ф>>>строки должны быть единственными

Ф>>>а тут только в std уже 2 варианта

O>>32-битных системах весит "аж" 24 байта.



Ф>ржал аки конь


Ага, еще больше ржать будешь когда будешь упираться в ограничения 32bit и надо будет считать каждый байтик.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[3]: И снова про ц++
От: Хвост  
Дата: 04.02.12 23:33
Оценка: 1 (1) +2
Здравствуйте, trop, Вы писали:

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

IP>>С++ как высшая математика, не каждый его понимает и не каждому она доступна по умственному потенциалу, но с помощью него делаются реальные вещи.

T>тем не менее в серъезных областях его испольщуют минимаьлно или не используют

похоже что Lockheed-Martin об этом не знает.
Lockheed Martin F-35 Lightning II
Unlike previous aircraft, such as the F-22, all software for the F-35 is written in C++ for faster code development.
People write code, programming languages don't.
Re: однако Sheridan - троль 80 уровня :) (-)
От: Философ Ад http://vk.com/id10256428
Дата: 03.02.12 08:19
Оценка: +2 -1
Всё сказанное выше — личное мнение, если не указано обратное.
Re[3]: И снова про ц++
От: jazzer Россия Skype: enerjazzer
Дата: 03.02.12 08:52
Оценка: +3
Здравствуйте, Sheridan, Вы писали:

S>Здравствуйте, Andrey.V.Lobanov, Вы писали:


S>>>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++?

AVL>>слабая маркетинговая составляющая
S>Каким боком маркетинг относится к языку программирования?
Гы. Ты считаешь, у жабы и шарпа был бы хоть один процент их нынешнего успеха, если бы за ними не стояли сан и мелкософт?
Вон Немерле — хороший язык, и где он? А если мелкософт его попиарит в стиле "больше шарпа не будет, следующий шарп — это Немерле" — угадай, насколько вырастет его доля через год-два, и на какой строчке он будет в каком-нть ТИОБЕ.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[7]: И снова про ц++
От: Mamut Швеция http://dmitriid.com
Дата: 03.02.12 10:16
Оценка: +1 -1 :)
Ф>>строки должны быть единственными
Ф>>а тут только в std уже 2 варианта

O>Спорно.

O>Допустим, для какой-то задачи мне нужны очень компактные, пусть и не быстрые, строки.
O>Стандартная std::string не подходит, так как на 32-битных системах весит "аж" 24 байта.
O>Зато есть CString (MFC), QString (Qt) и всякие велосипеды, при желании можно найти или
O>собрать реализацию с объектами размером в указатель.
O>Прелесть в том, что C++ позволяет выбирать.

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

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


dmitriid.comGitHubLinkedIn
Re[7]: И снова про ц++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.02.12 15:47
Оценка: -3
Здравствуйте, okman, Вы писали:

O>Допустим, для какой-то задачи мне нужны очень компактные, пусть и не быстрые, строки.

O>Стандартная std::string не подходит, так как на 32-битных системах весит "аж" 24 байта.
O>Зато есть CString (MFC), QString (Qt) и всякие велосипеды, при желании можно найти или
O>собрать реализацию с объектами размером в указатель.
O>Прелесть в том, что C++ позволяет выбирать.

Попроси что бы ктото убил тебя. Понавыбираете а потом интеграция превращается в переписывание.
Re[3]: namespace'ы в классах
От: Mamut Швеция http://dmitriid.com
Дата: 03.02.12 16:19
Оценка: +2 :)
S>
S>gate ~ # g++ example.cpp -o example
S>gate ~ # ./example
S>Hi, 123!
S>Hi, 123! This is other namespace :))
S>


S>Другое дело что на ненавистных местными дефайнах.... Ну уж это я считаю что они ими пользоваться не умеют...


Когда ты прекратишь слушать голоса в своей голове? То, что ты «нарисовал» — это страшный страх и ужасный ужас со всех сторон — от читаемости до поддержки в будущем


dmitriid.comGitHubLinkedIn
Re[10]: И снова про ц++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 03.02.12 21:10
Оценка: +3
Здравствуйте, x-code, Вы писали:

XC>Для меня — полная совместимость всех строк и их "абстрактность".

XC>Я хочу, чтобы строка в кавычках была просто объектом.

Почему именно объектом?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[11]: И снова про ц++
От: Mamut Швеция http://dmitriid.com
Дата: 04.02.12 19:54
Оценка: -3
M>>Ну и да, количество реализаций строк для С++ намекает на то, что в консерватории что-то не так.

O>Эдак можно прийти к выводу, что linux тоже в глубоком ауте из-за разнообразия версий.

O>А на самом деле обилие реализаций всего лишь отражает широту круга задач, которые ими решаются.

Нет, не отражают. Отражает только ровно один факт: в С++ нет нормального способа работать со строками. Все эти QString/CString/*string'и процентов на 80-90 ублируют функцинальность друг друга.


dmitriid.comGitHubLinkedIn
Re[13]: namespace'ы в классах
От: Mamut Швеция http://dmitriid.com
Дата: 04.02.12 23:49
Оценка: +2 -1
S>>>Отлично читается и не вижу проблем в поддержке отлаженного однажды кода. Может у вас нет опыта работы с подобным? Ну так это не мои проблемы.

M>>К выделенному, повторю вопрос:

M>>

M>>Ты хоть раз участвовал в проектах, в которых был больше, чем один программист, и как долго?

S>Пойдем по кругу? Ну раз хочешь — давай.
S>Никак не могу понять как связан опыт работы в команде и возможности языка.
S>Могу добавить только еще вот что: если у тебя или у кого то еще возникают трудности с прочтением такого кода — то это лишь говорит о вашем малом опыте работы с таким кодом, только и всего. Отсюда вывод: вы не используете целиком возможности языка, предпочитая его ругать и поносить. Позиция ваша вполне ясна: "мне лень".

Позиция наша вообще-то очень понятна. Всем, кроме тебя.

Здесь сейчас речь идет не о возможностях языка, а том кошмаре, что ты набросал, их используя.
То, что ты набросал, является кошмаром с точки зрения читаемости кода и его поддержки в дальнейшем для любого неигрушечного проекта, над которым работает больше, чем один человек, больше, чем полгода. Повторю для тупых танкистов: проблема не в самих возможностях языка, а том, как ты их используешь.

Поэтому, когда ты говоришь следующее: "Отлично читается и не вижу проблем в поддержке отлаженного однажды кода" сразу возникает вопрос: "Ты хоть раз участвовал в проектах, в которых был больше, чем один программист, и как долго?"


dmitriid.comGitHubLinkedIn
Re[30]: И после препроцессора, кстати...
От: FR  
Дата: 10.02.12 02:54
Оценка: +2 :)
Здравствуйте, Sheridan, Вы писали:


FR>>Пара десятков подобных дефайнов намного хуже.


S>Тоесть до тебя не доходит что пара десятков дефайнов может использоваться в паре тысяч мест например и исправлением одного дефайна можно изменить весь тот остальной код?


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

S>Данная конкретная разминка для мозгов — чем плоха? Сравни код с дефайнами и код без дефайнов. Представь что таких классов — полсотни. Я пошлю все нафиг, если меня попросят такое поддерживать.


Как разминка для мозгов вполне, как код в реальном проекте, к тому же на C++ а не Си, нафиг.
Поддерживать как раз будет проще без дефайнов. Вот представь какой-то нехороший человек нагородил раз в десять
больше и сложнее чем у тебя макросов, ты в первый раз жизни видишь этот код, тебе практически приходится изучить
тот DSL который он наваял и который наверняка глобален для проекта. При этом тебе обычно надо сделать небольшое
локальное исправление, а ошибка в макросе, самое веселое это когда в половине мест использования этого макроса
надо править ошибку а в половине код уже завязан на эту багофичу. И вместо правки небольшого локального участка
у тебя гемморой.

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

S>Не, ну правда, какието ну вообще идионты дефайны наверно писали, да? А другие идиоты все никак из стандарта не уберт, ага.


Ну в общем да, полумеры какие-то, вообще стыд какой-то, если сравнить с макросами хотя бы из макроассемблеров
не говоря уже скажем про camlp4. Ладно для Си простительно, а Страуструп куда смотрел?
Re[25]: Наследование
От: Erop Россия  
Дата: 10.02.12 16:19
Оценка: :)))
Здравствуйте, _d_m_, Вы писали:


___>Мда... Как сильно я отвык от ц++... Это не код, это какой-то брэйнфак.


Не, просто это не С++ а S++ А может и S--...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[7]: namespace'ы в классах
От: Tanker  
Дата: 14.02.12 08:06
Оценка: -2 :)
Здравствуйте, Sheridan, Вы писали:

P>>А прикинь, как математики измельчали. Не хотят почему-то использовать римские цифры при записи чисел. Перешли на позиционные системы счисления. И теперь любой школьник выполняет арифметические действия без особых проблем. Не хотят разбираться в римских цифрах, считают их источником ошибок и тратой времени.

S>Ой передергиваешь. Римские цифры от арабских отличаются только при письме. Считать надо ровно также уметь. И если математика попросить римскими цифрами писать — он недельку привыкать будет, а потом обратно в колею войдет.
S>А вот ежели шарпея например или там заводчиков земноводных вдруг за ц++ посадить — ВНЕЗАПНО окажется что ой. Не хватает в головах и надо доучиваться.

Когда шарпей садится за с++ все что нужно это вспомнить указатели и забыть про вкусные фичи. А вот когда ц++ садится за чтото посильнее, начинается ОЙ — не хватает знаний по ООП, Дизайну.
ц++ путают ссылки с указателями, кричат на каждом углу "александреску не нужен" и продолжают рожать монстров еще страшнее тех что у александреску. Твои макросы именно такие
The animals went in two by two, hurrah, hurrah...
Re[12]: namespace'ы в классах
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 06.02.12 08:45
Оценка: 4 (2)
Здравствуйте, Privalov, Вы писали:

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


N>>При наличии SCM (её использовании как держателя кода проекта) и при её использовании участниками автор кода был бы найден сразу, также опознано, соответствует ли изменение содержанию комментария коммита, и если да — то логике. И тогда вопрос был бы не "Кто это сделал и зачем?", а "Ш-н, объясни, зачем это и откуда?"


P>Вопрос был задан 12.03.05. Ответ пришел 14.03.05. За это время любой вменяемый разработчик способен вспомнить, что и зачем он делал.


Категорически не согласен. Когда вопрос был задан — не имеет значения. Имеет значение, когда вопрос был прочтён и начат к разбору по существу (в данном случае этот юридический термин подходит лучше всего). Более того, если учесть, что 12-е — суббота, а 14-е — понедельник (Вы бы в календарь-то заглянули), то очень вероятно, что почта в это время вообще не читалась.
Когда у нас всё "горит", я могу неделями на RSDN не заглядывать, и что — это потом будет значить, что я по две неделю ищу ответ на простой вопрос (или ночами не сплю, думая, как бы извернуться и прищучить собеседника, если начался спор с вывертами)?
Если нет суровой обязанности отвечать в течение определённого времени и посвящать кусок времени на разбор входящей почты, то отсутствие ответа — это всего лишь отсутствие ответа.

P> Так что ответ "Но что я там и как делал даже для меня теперь тайна на сей день" неприемлем даже здесь.


Я тоже думаю, что он неприемлем, но совсем по другой причине: ответ был сформулирован как окончательный и при этом неконструктивный. Такого рода отношение к проекту, в котором участвуешь, неприемлемо как для меня, независимо от того, он платный, бесплатный, открытый, или какой-то ещё. Исключение — сверхчёткая формализация ролей и методов взаимодействий (армия или очень толстая структура), но здесь явно не тот случай.
The God is real, unless declared integer.
Re[8]: И снова про ц++
От: jazzer Россия Skype: enerjazzer
Дата: 06.02.12 21:34
Оценка: 3 (1) +1
Здравствуйте, Mamut, Вы писали:

S>>>>std::wstring?


M>>>И в любом случае они, в основном, позволяют хранить и выводить текст, но не позволяют других манипуляций. Не говоря уже о «удобстве» иметь два набора функций для манипуляции типа strlen и wcslen и т.п.


J>>если ты юзаешь (w)string, то надо просто позвать у него метод size(), никаких двух наборов тут нет


M>То есть strlen и ecslen мне приснились?


Да, в горячечном сишном бреду.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[11]: И снова про ц++
От: blackhearted Украина  
Дата: 07.02.12 11:33
Оценка: 3 (1) +1
Здравствуйте, Sheridan, Вы писали:

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


S>>>А с каких это пор мощность и универсальность языка ВНЕЗАПНО стала недостатком?

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

S>Ну так надо не языком ограничивать а правилами проекта.


Так тебе ж на них пофигу.
"Если мне интересно — буду писать как хочу".
Или это бы не ты?
Re[6]: И снова про ц++
От: enji  
Дата: 05.02.12 08:28
Оценка: 2 (2)
Здравствуйте, Young, Вы писали:

Y>А давайте допустим у нас нету массива — есть списки, кортежи и т.п. А массива нет.

Y>Сильно хуже будет?

Ну как-бы да. Список не дает быстрого доступа по индексу, кортеж — это фиксированное кол-во элементов разнотипных элементов.
Вообще странное утверждение. Предположим у нас есть только яблоки и груши, но нет апельсинов — сильно хуже будет?
Или вы намекаете на функциональное программирование? Тогда при чем тут С++? Чисто функциональные языки сейчас далеко не мейнстрим...

Y>Знаете, лет 15 назад я бы разделил вашу печаль..

Y>Но в текущий момент я (занимаясь разработкой игр под мобильные платформы замечу) — не могу представить себе реальной ситуации, в которой при размере массива в 26 ячеек мне было бы дело до того — есть там проверки или нету там проверок.

А я занимаюсь микропроцессорами и вполне эту печаль разделяю К тому ж мобильные платформы — это сейчас несколько ядер и гигагерцы А возьмите какую-нить микроволновку или девайс с требованиями по электропотреблению — все сразу станет по другому...

А иногда например, экономия пары баксов на процессоре при миллионных тиражах окупает даже разработку на голом асме. И такое бывает

Y>Более, того — я предпочту чтобы проверки были — ибо все мы знаем насколько меняются требования — и вполне возможно, что там будут не только символы английского английского алфавита по каким либо внешним причинам (опять же сайд эффекты — изменения в другой части программы могут привести к тому, что на вход нам подадут не символы английского алфавита).


Ключевая особенность С++ — не платишь за то, что не используешь. Нужны проверки — не вопрос, vector.at() или собственная обертка над массивом с проверками.
Re[3]: И снова про ц++
От: jazzer Россия Skype: enerjazzer
Дата: 03.02.12 07:00
Оценка: 1 (1) +1
Здравствуйте, netch80, Вы писали:

N>В принципе согласен. Более того, система namespace неудобна.

N>Постоянно хочется решений в стиле питоновского import X.Y.Z as W.
чем не устраивает
namespace W = X::Y::Z;

jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[4]: И снова про ц++
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.02.12 07:59
Оценка: 1 (1) +1
Здравствуйте, Философ, Вы писали:

XC>>>Имя массива является адресом первого элемента массива (нелогично! со структурами же не так)

LVV>>ИМХО для С это было самое то! Но для С++, который позиционируется как язык более высокого уровня, — это анахронизм.
Ф>Это хорошая демонстрация корявости синтаксиса.
Ф>Если ЦПП позиционируется как язык более высокого уровня, то в нём вообще не должно быть даже намёка на strlen/strcpy (а так же calloc/malloc/memcpy).

C++ позиционируется — в нормальном варианте — не как язык высокого уровня, а как многоуровневый язык. А что такое Ваше "язык более высокого уровня", известно только Вам. Насколько более высокого? На миллиметр, километр, 3 слоя или ровно на одну морковку?

Ф>По какой-то странной причине от специалиста по C не требуют знаний асма, а вот с ЦПП — наоборот.


Это где такие странные требователи? Сколько я видел, требовался или одинаковый уровень знаний "асма" от специалистов по C и C++, или для C требовался более высокий уровень (а в C++ выносились уже более высокоуровневые аспекты реализации).

Ф>Солидная часть вопросов на собеседованиях по ЦПП по сути являются вопросами по C, о чем это говорит?


О многоуровневости C++. Ваш К.О.

Ф>ЗЫ: ЦПП — мутант переходного периода.


Вполне возможно. Но я пока что вижу несколько обратную тенденцию: проекты, которые требуют низкоуровневость в отдельных деталях реализации, но высокоуровневость в концепциях, всё больше пишутся на C++, хотя раньше их насильно загоняли в рамки C. Текущий процесс (последние лет 10) можно охарактеризовать тем, что чисто прикладной софт мигрирует с C++ на языки управляемых сред (Java, C#, Python, ещё пару десятков кандидатов), а системный заметно расширяется в сторону C++.
Те же атомарные операции в C++ — хороший пример такого расползания C++ "вниз".
The God is real, unless declared integer.
Re[11]: И снова про ц++
От: Cyberax Марс  
Дата: 03.02.12 20:27
Оценка: 1 (1) :)
Здравствуйте, Sheridan, Вы писали:

S>Да ладно? У строки есть метод sendtoserver? Пример крайне неудачен.

Нет, есть extension-метод SendToServer.

S>Впрочем мысль понятна. Все зависит от мощности используемой библиотеки. Кутэ приближается к описанному тобой.

QT ограничен языком.
Sapienti sat!
Re[12]: И снова про ц++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 04.02.12 23:31
Оценка: 1 (1) +1
Здравствуйте, Cadet, Вы писали:

S>>Да ладно? У строки есть метод sendtoserver? Пример крайне неудачен.

C>Ну дык вылазь в реальный мир из своих грез. Такой код вполне реальность не в плюсах. И в плюсах мог бы быть реальностью.

S>>Не вижу разницы. Одинаково понятно.

C>Ага, в плюсах этого нет, значит этого не надо . А вообще забавно смотреть, как плюсовики, ранее кричавшие про ненужность var в шарпе к примеру, резко полюбили auto с выходом С++ 11. Это же не var, это auto, разница огромна .

Объясню, почему так происходит. Потому что те, кто "активно голосует за var" и прочие нововведения параллельно с этим продвигают следующую цепочку рассуждений: если нет var, то C++ — плохой, если C++ плохой, то и те, кто на нём программируют — плохие, если они плохие... Дальше фантазия безгранична. Поэтому "сиплюсники" (© Ikemefula, ему, видимо, лень писать полное название) вынуждены "отбиваться" всеми доступными способами. Это забавно, разумеется, но конструктива в таких срачах чуть менее нуля. Но, простите, а что делать-то? Атакуют-то людей, а не язык, вот люди и отвечают, а что вы хотели?

Поэтому складывается впечатление, что программисты на C++ какие-то дремучие консерваторы, хотя объективно это совсем не так. Но такая картина вполне объяснима, коль скоро обсуждение недостатков C++ немедленно превращается в "борьбу со стереотипами", "открой для себя" и прочую муть псевдопсихологической направленности. Раз уж заговорили о психологии и "мотивациях", в которой почти никто не разбирается, то вполне закономерно в разговор заползают химеры. Право слово, я не знаю, что движет хулителями C++. Мне вот, почему-то, не приходит в голову ругать "паскалистов" (сиречь — "дельфятников"), хотя мне Паскаль не скажу, что нравится. Не знаю, комплекс у них, что ли, какой-то?

Отсюда вывод, что твоё "удивление" по поводу: "резко полюбили auto с выходом С++ 11" вызвано к жизни, по сути, досужими выдумками тех, кто по каким-то причинам резко и активно невзлюбил C++. То есть сначала они выдумали некоторую реакцию отторжения, потом её всеми силами разрекламировали, а потом "удивились", что с выходом C++11 её не случилось. А на самом деле, это нивелирует рассуждения о консервативности "плюсовиков" и удивляться здесь нужно тому, как взрослые (наверное?) люди в такую ахинею вообще поверили.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[7]: namespace'ы в классах
От: Mamut Швеция http://dmitriid.com
Дата: 05.02.12 00:06
Оценка: 1 (1) +1
C>>Да в данном месте наплакал конечно. А в реальном проекте, с исходниками мегабайт ну скажем 5, один так наплакал в одном месте, другой в другом, третий в третьем. А потом ты рыдаешь, когда продираешься через это в поисках ошибки.
S>То есть ты предлагаешь не использовать целый огромный пласт возможностей языка, ссылаясь на лень? Ну-ну...

Шеридан, когда мы с тобой разговаривали про Калпу, я тебя попросил не ломиться отвечать сразу, а сделать хотя бы минимальное усилие над собой и попытаться понять, что тебе люди пишут. Выделенное != лень. Если ты не способен этого понять, пожалуйста, перестань вообще что-либо писать про программирование, умоляю.


dmitriid.comGitHubLinkedIn
Re[4]: И снова про ц++
От: enji  
Дата: 05.02.12 06:15
Оценка: 1 (1) +1
Здравствуйте, Философ, Вы писали:

Ф>Если ЦПП позиционируется как язык более высокого уровня,

C++ позиционируется как надмножество С, и позволяет компилировать код С, а также мешать код С и С++.

Ф>то в нём вообще не должно быть даже намёка на strlen/strcpy (а так же calloc/malloc/memcpy).

Ф>C отдельно, ЦПП отдельно (так же как асм отделили от ЯВУ).
Ф>По какой-то странной причине от специалиста по C не требуют знаний асма, а вот с ЦПП — наоборот.
Ф>Солидная часть вопросов на собеседованиях по ЦПП по сути являются вопросами по C, о чем это говорит?
Ответ на все эти вопросы — С++ — надмножество С. В тоже время С не является надмножеством асма...

Ф>ЗЫ: ЦПП — мутант переходного периода.

Это да, но иначе он бы не выжил. Это была (имхо правильная) позиция его создателей.
Re[6]: И снова про ц++
От: okman Беларусь https://searchinform.ru/
Дата: 05.02.12 07:37
Оценка: 1 (1) +1
Здравствуйте, Young, Вы писали:

Y>А давайте допустим у нас нету массива — есть списки, кортежи и т.п. А массива нет.

Y>Сильно хуже будет?

Хуже.
Потому что и списки, и кортежи, для каких-то задач избыточны.
Но Вы этого не желаете понять, поэтому продолжать бессмысленно.

Y>Знаете, лет 15 назад я бы разделил вашу печаль..

Y>Но в текущий момент я (занимаясь разработкой игр под мобильные платформы замечу) — не могу представить себе реальной ситуации, в которой при размере массива в 26 ячеек мне было бы дело до того — есть там проверки или нету там проверок.

Вот именно — не можете представить. А кто-то может.
Поэтому одни пишут на Шарпах, а другие на Плюсах.

Y>Более, того — я предпочту чтобы проверки были — ибо все мы знаем насколько меняются требования — и вполне возможно, что там будут не только символы английского английского алфавита по каким либо внешним причинам (опять же сайд эффекты — изменения в другой части программы могут привести к тому, что на вход нам подадут не символы английского алфавита).


А давайте туда еще синхронизацию влепим — вдруг требования изменятся ?
Re[3]: namespace'ы в классах
От: neFormal Россия  
Дата: 07.02.12 05:41
Оценка: 1 (1) +1
Здравствуйте, Sheridan, Вы писали:

XC>>Невозможность создания namespace внутри класса (вспомните хотя-бы "главные оконные классы" разных библиотек — CWnd, QWidget... сотни методов, там разделение не помешало бы)

S>Ну если очень надо — можно и нарисовать, благо нетрудно. У меня — не программиста — ушло гдето минут 10...

руки! руки оторвать за такое!

S>Другое дело что на ненавистных местными дефайнах.... Ну уж это я считаю что они ими пользоваться не умеют...


скорее это ты не умеешь.. абсолютно..

собеседование ты не пройдёшь
...coding for chaos...
И снова про ц++
От: Sheridan Россия  
Дата: 03.02.12 04:51
Оценка: :))
Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++? Указатели? Да фигня это, на пару граблей наступить и рефлекс появится. Зато более шустрый софт получается.
Так все же?
Matrix has you...
Re: И снова про ц++
От: blackhearted Украина  
Дата: 03.02.12 06:29
Оценка: +2
Здравствуйте, Sheridan, Вы писали:

S>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++? Указатели? Да фигня это, на пару граблей наступить и рефлекс появится. Зато более шустрый софт получается.

S>Так все же?

Рассуждения админа, который вручную делает new/delete, пишет только сам и помнит весь проект, о С++.
Взял попкорн.
Re[4]: И снова про ц++
От: blackhearted Украина  
Дата: 03.02.12 10:36
Оценка: +1 :)
Здравствуйте, Mamut, Вы писали:

S>>>>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++?

D>>>учи дальше плюсы.
S>>Чем дальше вникаю тем больше нравится.

M>Пока что ты даже близко не начал вникать. Потому что Qt, который, как кто-то правильно сказал, это дотнет для бедных
Автор: Mamut
Дата: 23.07.08


Но дядя Линус же писал на С, значит земноводные и прочие дотнеты сосудожны умереть в болоте.
Re[4]: И снова про ц++
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.02.12 12:16
Оценка: +1 -1
Здравствуйте, gegMOPO4, Вы писали:

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

N>>Здравствуйте, x-code, Вы писали:
XC>>>Ужасная система #include и препоцессора,
N>>Для своих задач препроцессор вполне адекватен. С другой стороны, ничто не мешает при необходимости сделать над ним что-то своё. Например, на m4, не к ночи будь сказано (но всё равно для мелких задач начинают выбор с него) или на любом другом макропроцессоре, какой понравится.
MOP>Проблема в том, что это слишком неформальная, свободная система, трудно автоматизировать построение зависимостей, особенно с учётом макроопределений. Поэтому для каждого нового набора опций сборки нужно отдельное дерево, и выгоды раздельной компиляции всё чаще идут лесом, и ошибиться легко, собрав несовместимые объектники.

Да, неформальная и свободная. Но для Си в общем-то другая и не пойдёт. Более того, постоянно возникает необходимость аналогичных средств к другим языкам — например, к Питону.
На сейчас приходится при необходимости выбирать реализацию на старте заниматься хаками типа вынести зависимое от внешних условий в мелкие функции и вызывать их по ссылке из основного кода. А это может заметно тормозить выполнение программы. При препроцессоре стиля Си условная компиляция с самого начала помогла бы сэкономить на этом.

А описанные тобой ужасы, конечно, имеют место, но пока что в основном перекрываются выгодами.

XC>>> отсутствие нормальной модульной системы

N>>Если речь про схему в стиле Вирта (тут interface, а тут implementation), то несложно заметить, что почему-то она не прижилась в промышленности и не была принята ни в одном языке, начатом "с нуля", заведомо позже массового распространения Паскаля. Например, она не была принята ни в Java ни в C#. Зато подход с заголовочными описаниями распространяется практически на все языки. Я думаю, у "нормальной модульной системы" всё-таки есть какой-то фатальный недостаток.
MOP>Где ещё, кроме C/C++ (и нескольких непродуманных язычков вроде PHP) используется «модульность» на основе #include? Как раз в Java отдельный файл — отдельный класс, единица трансляции, пространство имён, единица организации кода.

Не-а. Нормальная модульность была бы, если бы можно было отделить объявления от того, что их реализует. Например, есть модуль — вот вам список функций в нём, а сами функции где-то в другом месте. Никакая Java такого не умеет и не собирается, хочешь взять определения откуда-то — изволь принести полную реализацию. А заголовочные файлы для C/C++ хоть и бардачны, но позволяют именно это — в них только объявления функций, определения констант и enum'ов и тому подобное.

MOP>Есть два преимущества системы C — раздельная компиляция и совместимость со старым кодом на ассемблере и Фортране. Первое сейчас не критично, в память влазит полностью и файл-исходник, и выход,


При чём тут влезает или не влезает в память? Есть куча причин не компилировать всё вместе. Только для студенческой песочницы годится требовать всё одним скопом, и то — ОС сюда уже никто не включает.

XC>>>Невозможность создания namespace внутри класса (вспомните хотя-бы "главные оконные классы" разных библиотек — CWnd, QWidget... сотни методов, там разделение не помешало бы)

N>>В принципе согласен. Более того, система namespace неудобна.
N>>Постоянно хочется решений в стиле питоновского import X.Y.Z as W.

MOP>
MOP>namespace W = X::Y::Z;
MOP>


Я уже давно объяснил в соседних сообщениях, что эта ерунда не имеет ничего общего с тем, что я хотел.
Читай с конца, не будешь повторять уже пережёванное.
The God is real, unless declared integer.
Re[7]: И снова про ц++
От: x-code  
Дата: 03.02.12 12:57
Оценка: +2
Здравствуйте, Sheridan, Вы писали:

S>aaa.h

S>
S>#ifndef aaa
S>#define aaa
S>// пишем, не имея проблем с циклическими инклудами. Любая иде так делает сразу.
S>#endif aaa
S>


Любую программу можно написать на ассемблере. Но надо ли это делать?

Красота языка определяется отсутствием таких вот обходных путей (а это именно обходной путь!). Да, в данном случае обойти просто... но это в данном случае, вполне могут быть случаи и посложнее. Мне нужен язык, в котором вообще ничего не нужно обходить.
Re: И снова про ц++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.02.12 15:04
Оценка: +1 :)
Здравствуйте, Sheridan, Вы писали:

S>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++? Указатели? Да фигня это, на пару граблей наступить и рефлекс появится. Зато более шустрый софт получается.

S>Так все же?

Авторы библии FDG так и пишут — большинство людей не имеет опыта с указателями.

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

Соответсвенно многим тупо жалко времени на это долбление, тк. можно взять какой Питон и в пять строчек написать то же самое, что взлетит на раз.
Re[3]: И снова про ц++
От: Young yunoshev.ru
Дата: 04.02.12 09:48
Оценка: -1 :)
Здравствуйте, okman, Вы писали:

O>Здравствуйте, Young, Вы описывали какие-то ужасы.

O>Как то:

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


Y>>Это же лепота — присвоил переменной значение — и уверен что ее никто уже не поменяет, вызвал функцию — и уверен, что она ни на что не повлияет.


O>Можете пояснить, каким боком тут всеми любимый С++ ?

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

Не понял.... Собственно речь как раз и идет о том, что язык должен обеспечивать невозможность сайд-эффектов.

Y>>А ц++, что — каждый чих потенциально может изменить логику программы в любом месте.


O>Для этого давно придумали разделение ответственности и инкапсуляцию.


О! А как ответственность и инкапсуляция поможет мне при использовании сторонней функции которая тупо гадит в память?

В ц++ вызов любой функция может потенциально иметь сайд-эффекты на все остальные данные. И как следствие об этом нужно всегда думать.
А не хочется.
Re[9]: И снова про ц++
От: Философ Ад http://vk.com/id10256428
Дата: 04.02.12 13:21
Оценка: -2
Здравствуйте, okman, Вы писали:

O>Здравствуйте, Философ, Вы писали:


Ф>>ржал аки конь


O>Расскажи, что смешного — я тоже поржать люблю.


struct StringStruct
{
System.Int32 size;
System.IntPtr dataPointer;
System.IntPtr vtable;
}

StringStruct *str1;
sizeof(str1) + sizeof(StringStruct) == 16 байт

Фантастический оверхэд у вас!
целых 24 байта против самых минимальных 16
Всё сказанное выше — личное мнение, если не указано обратное.
Re[7]: namespace'ы в классах
От: Sheridan Россия  
Дата: 04.02.12 22:13
Оценка: -1 :)
Здравствуйте, Cadet, Вы писали:

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


M>>Ты хоть раз участвовал в проектах, в которых был больше, чем один программист, и как долго?


C>Помнится участвовал в Авалоне, был быстро с треском изгнан . Из-за стиля работы "пишу как хочу и класть мне на остальную команду".

Я привел ту зловонную свалку в порядок. Но этисамые к грязи привыкли. И не захотели жить в чистоте. Я на них не обижаюсь, такие сущности, что поделаешь. Доступ к репозиторию у меня емнип не забрали, перенесли мой код в отдельную ветку, развели грязь обратно. Их право.
Matrix has you...
Re[4]: И снова про ц++
От: Cadet  
Дата: 05.02.12 06:47
Оценка: :))
Здравствуйте, Хвост, Вы писали:

Х>похоже что Lockheed-Martin об этом не знает.

Х>Lockheed Martin F-35 Lightning II
Х>Unlike previous aircraft, such as the F-22, all software for the F-35 is written in C++ for faster code development.

То-то я думаю, отчего же это вдруг:

По мнению ряда экспертов, самолёт не соответствует большому числу требований к истребителю пятого поколения и является истребителем поколения 4+ из-за невозможности полета на сверхзвуковой скорости без использования форсажа, низкой тяговооруженности, сравнительно высокой ЭПР, а также низкой живучести и маневренности.

На разработку этого самолёта на апрель 2011 г. уже затрачено свыше 56 млрд долларов США.

(Lockheed Martin F-35 Lightning II)

Оказывается они для него софт на ЦПП пишут, теперь понятно.
... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
Re[7]: И снова про ц++
От: Философ Ад http://vk.com/id10256428
Дата: 05.02.12 07:06
Оценка: :))
Здравствуйте, Sheridan, Вы писали:

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


S>>>Дело в том, что ц++ переживет и земноводных и немерле с хаскелями, как уже пережил вижуалбэйсик например.

J>>Ну так и лисп с фортраном успешно всех переживают, и даже кобол, прости господи
S>Возможно. Только ц++ всетаки популярнее...

пока, к сожалению
Всё сказанное выше — личное мнение, если не указано обратное.
Re[5]: И снова про ц++
От: Ночной Смотрящий Россия  
Дата: 05.02.12 09:16
Оценка: +2
Здравствуйте, FR, Вы писали:

FR>Y–комбинаторы рулят:


FR>
FR>fib = lambda n : (lambda func, n : func(n, func))(lambda x, rec : x < 2 and 1 or rec(x-1, rec) + rec(x-2, rec), n)
FR>


Они может и рулят, но тебе не кажется что вариант с локальной функцией будет читаться намного проще?
Re[7]: И снова про ц++
От: Young yunoshev.ru
Дата: 05.02.12 11:05
Оценка: -1 :)
Здравствуйте, enji, Вы писали:

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


Y>>А давайте допустим у нас нету массива — есть списки, кортежи и т.п. А массива нет.

Y>>Сильно хуже будет?

E>Ну как-бы да. Список не дает быстрого доступа по индексу, кортеж — это фиксированное кол-во элементов разнотипных элементов.

E>Вообще странное утверждение. Предположим у нас есть только яблоки и груши, но нет апельсинов — сильно хуже будет?
E>Или вы намекаете на функциональное программирование? Тогда при чем тут С++? Чисто функциональные языки сейчас далеко не мейнстрим...

Бррр....вообще какой то старный выверт разговора. А причем тут мейнстрим или не мейнстрим?
Вот есть лисп — если смешать в кучу все его диалекты — то за все время получится обьем кода точно не меньший чем на ц++ (заметье мы ц++ обьсуждаем, а не ц). Но он таки не мейнстрим — и что?

Изначально что спросили откуда такая нелюбовь. Я ответил — что нелюбовь от того, что при разработке на ц++ — и особенно при поддеживании чужого кода мы будем скорее решать технические проблемы связананные с выстрелами по памяти, порчей стека и т.п. — чем логические. А хочеться технические проблемы не решать и забыть о них.

И мне ей богу странно что с этим спорят. Что прет решать технические проблемы???

Y>>Знаете, лет 15 назад я бы разделил вашу печаль..

Y>>Но в текущий момент я (занимаясь разработкой игр под мобильные платформы замечу) — не могу представить себе реальной ситуации, в которой при размере массива в 26 ячеек мне было бы дело до того — есть там проверки или нету там проверок.

E>А я занимаюсь микропроцессорами и вполне эту печаль разделяю К тому ж мобильные платформы — это сейчас несколько ядер и гигагерцы А возьмите какую-нить микроволновку или девайс с требованиями по электропотреблению — все сразу станет по другому...


E>А иногда например, экономия пары баксов на процессоре при миллионных тиражах окупает даже разработку на голом асме. И такое бывает


Бывает, да. Только зачем вам в случае микропроцессоров ц++? Чем вам ц99 не хватает то — если вы боритесь за производительность?

Y>>Более, того — я предпочту чтобы проверки были — ибо все мы знаем насколько меняются требования — и вполне возможно, что там будут не только символы английского английского алфавита по каким либо внешним причинам (опять же сайд эффекты — изменения в другой части программы могут привести к тому, что на вход нам подадут не символы английского алфавита).


E>Ключевая особенность С++ — не платишь за то, что не используешь. Нужны проверки — не вопрос, vector.at() или собственная обертка над массивом с проверками.


Да елки-палки. Что значит не платишь — платишь, платишь потом сложными багами в чужих проектах, та же случайная, раз в месяц работы программы стрельба по памяти, приводящая не к крашу, а изменению данных.
Re[14]: И снова про ц++
От: enji  
Дата: 06.02.12 04:56
Оценка: +2
Здравствуйте, Cadet, Вы писали:

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


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


Y>>>Начиная от произвольного дефайна (#define true false // happy debug)

S>>Найти по истории репозитория автора, спросить у ОК его адрес, приехать и набить морду.

C>Да-да. Ты еще найди такую пасхалку в большом проекте. Она к примеру может хитро использоваться совместно с макросом __DATE__, и стрельнуть примерно через полгода после коммита.


Вы серьезно обсуждаете, что минус С++ — в том, что кто-то может написать #define true false? И скомбинировать это с макросом DATE?
Что мешает мне написать какую-нить пакость в обычном коде на яве/питоне/шарпе, без использования препроцессора? И скомбинировать это с DateTime.Now или rand?
Re[2]: Подытожим?
От: aloch Россия  
Дата: 06.02.12 18:15
Оценка: +1 :)
Здравствуйте, Sheridan, Вы писали:

>... имеют общий корень и имя ему — "лень"\


Зачастую именно ЛЕНЬ — это двигатель прогресса...


Re[8]: Подытожим?
От: Mamut Швеция http://dmitriid.com
Дата: 06.02.12 20:46
Оценка: +2
M>>Откуда у тебя появится знание об именах?

S>А как еще можно относиться к фразе "это трудно поддерживается"?


Так и относится: в production и тем более в командную рзработку такое пускать нельзя.

S>Вот смотри: Поддерживается? Да, поддерживается, но трудно. Нелегко. То есть поддерживается при условии более усердного труда.


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

Знаешь, чем я занимался вчера? Я писал ровно три строчки кода. Для того, чтобы написать я эти три строчки я две недели ковырял базу кода на 400 000 (четыреста тысяч) строчек кода. Именно потому, что повсюду — вот такие вот "простые, отлаженные участки кода" (с). Их взаимодействие, зависимость друг от друга и влияние на другие участки кода известны только тем, кто их написал: один уволился, второй сломал руку, третий на parental leave.

А так — да, конечно, код отлажен, прост, я ленив, и должен желать тратить свое время не на полезные дела, а на поиски неизвестно чего в хаосе.

Сейчас всю эту базу рефакторят с целью разбить ее на независимые друг от друга приложения. Вместо того, чтобы это сделать за две недели (вполне реально), работа ведется уже четвертый месяц. Поому что местные шериданы успели понапихать "простые, отлаженные участки кода".

Но это просто лень — не хотеть тратить 4 месяца на работу, на которую можно потратить 2 недели. Ведь нулевая производительность для человека — это так полезно.

Так что ты говоришь про свой опыт разработки?


dmitriid.comGitHubLinkedIn
Re[15]: namespace'ы в классах
От: Cadet  
Дата: 07.02.12 05:05
Оценка: +2
Здравствуйте, Sheridan, Вы писали:

P>>Целая толпа народу пытается объяснить это мсье д'Артаньяну черт знает сколько времени.

S>А Дарт Аньян все никак не может донести толпе, что работать в сторону интереса намного продуктивнее, нежели работать в сторону необходимости.

Как раз таки нет, потому что ты часок поработаешь в сторону интереса, а потом другой человек 5 часов твои говна наваленые разбирает. В целом для проекта это гораздо хуже, чем работа по плану, выработанному тимлидом.
... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
Re[8]: Подытожим?
От: neFormal Россия  
Дата: 07.02.12 05:35
Оценка: +1 :)
Здравствуйте, Sheridan, Вы писали:

M>>Откуда у тебя появится знание об именах?

S>А как еще можно относиться к фразе "это трудно поддерживается"?

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

S>Ты можешь возразить — "нооо каааакже, тут не лень, а стремление сделать больше за освободившееся время!!" и будешь прав где то процентов на 20. Остальные 80 — лень. Просто природа человека такая.


ты мне вот кого напомнил:
http://henri-spb.livejournal.com/317731.html
...coding for chaos...
Re[17]: namespace'ы в классах
От: Privalov  
Дата: 07.02.12 11:41
Оценка: +1 -1
Здравствуйте, Sheridan, Вы писали:

Ты в самом деле не понимаешь?

S>>>>Когда люди чего-то не понимают — они от этого стараются избавиться.


Ты — человек. Значит, если ты чего-то не понимаешь, ты от этого стараешься избавиться. Элементарное рассуждение. Дедукция называется. 1-й семестр.

Тогда "пересиливаю и осиливаю" — ложно, поскольку противоречит правилу вывода.

А если второе утверждение верно, вот это:

S>>Первое желание конечно — забить нафиг и забыть. Но как правило пересиливаю и осиливаю.


тогда незачем обобщать. Т. е. первое высказывание ложно. Лекцции по матлогике прогуливать не надо было.
Re[13]: И снова про ц++
От: blackhearted Украина  
Дата: 07.02.12 13:13
Оценка: +2
Здравствуйте, Sheridan, Вы писали:

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


S>>>Ну так надо не языком ограничивать а правилами проекта.

B>>Так тебе ж на них пофигу.
B>>"Если мне интересно — буду писать как хочу".
B>>Или это бы не ты?

S>Ты "случайно" забыл еще одну мою цитату добавить.


Тебе всё сообщение скопировать?

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

здесь
Автор: Sheridan
Дата: 05.02.12

ОбосрСлил?
Re[15]: И снова про ц++
От: b-3 Россия  
Дата: 07.02.12 20:24
Оценка: +1 -1
Здравствуйте, Sheridan, Вы писали:

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


S>Да ладно? Ты действительно не понимаешь, что "Если мне интересно — буду писать как хочу" работает до тех пор, пока "мне за код не платят деньги"?


Я лично не разумею, какое отношение имеет способность программиста думать с точки зрения "пользы для проекта" к уровню его достатка. Может быть, надо слова мне за код платят деньги заменить на меня контролируют и карают за все косяки? Иначе непонятно, что $0 / час, что $20 / час — всё равно фиксед рейт, и никакой внутренний ограничитель не мешает лепить что попало
Забанен с формулировкой "клинический дисидент".
Re[24]: Наследование
От: _d_m_  
Дата: 09.02.12 11:28
Оценка: +2
Здравствуйте, Sheridan, Вы писали:

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


H>>Есть результат?

S>Полчаса поковырялся. Буквально на коленке сделал. Можно еще попробовать причесать конечно, но вот рабочее:

...

Мда... Как сильно я отвык от ц++... Это не код, это какой-то брэйнфак.
Re[4]: namespace'ы в классах
От: Sheridan Россия  
Дата: 11.02.12 08:34
Оценка: :))
Здравствуйте, landerhigh, Вы писали:

L>У нас, программистов, такой "код" на код ревью летит в помойку, а его аффтар отправляется в ссылку править баги в быдлокоде.

Измельчали программисты, измельчали. Очень наглядно сказывается понижение порога — в профессию лезут недоучки и их все больше. И все бы ничего, но эти самые недоучки начинают своей массой (не умом) выдавливать нормальных людей из профессии, попутно объявляя используемые более старшими программистами инструменты источником ошибок и тратой времени. Хотя на самом деле эти недоучки лишь не могут разобраться в этих инструментах, не знают с какого края подходить и соответственно не имеют опыта работы с ними.
Плохо. Очень плохо.
Я очень надеюсь что производительность компов упрется в потолок и наконецто придется писать нормальный софт, не надеясь на мощность компьютеров.
Matrix has you...
Re[25]: namespace'ы в классах
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.02.12 16:17
Оценка: +1 :)
Здравствуйте, Sheridan, Вы писали:

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


S>>>А в шарпах энумы тоже числа?

C>>Да уж, мужик. Нет слов даже.
S>Ок. Я написал излишне объемный код вместо компактного. Можно я отрежу себе ухо?

S>Но у меня появляются два вопроса:

S>1. Почему этот код не переписал сам АВК, а предпочел спихнуть это на меня?

Потому что если за тобой постоянно подчищать, то ты никогда не научишься писать.

S>2. Почему эту мелочь вспоминают до сих пор, по истечении шести(?) лет?


это типичный пример.
Re[7]: namespace'ы в классах
От: Privalov  
Дата: 05.02.12 07:14
Оценка: 3 (1)
Здравствуйте, Cadet, Вы писали:

C>Помнится участвовал в Авалоне, был быстро с треском изгнан . Из-за стиля работы "пишу как хочу и класть мне на остальную команду".


Сдается мне, он участвовал не только в Авалоне. В свое время весьма доставил этот
Автор: AndrewVK
Дата: 12.03.05
диалог.
Re[17]: namespace'ы в классах
От: Mamut Швеция http://dmitriid.com
Дата: 06.02.12 20:23
Оценка: 3 (1)
M>> Что предложил jazzer?
M>>

M>> Продемонстрируй решение проблемы "автокомплит по группам методов" на других языках


M>> Каким образом вопрос jazzer'а относится к предыдущим двум цитатам?


H>Это вообще-то не джаззер предложил, это икс-код свою мысль развил
Автор: x-code
Дата: 03.02.12
:

H>

Не. У меня есть объект конкретного класса, у которого внутри сотни методов, полученных ЛЮБЫМ путем, может быть — длинная цепочка наследования, может быть все сразу объявлены, неважно. Я в IDE пишу "obj." и мне автокомплит выдает ПРОСТЫНЮ из методов, отсортированных тупо в алфавитном порядке. А я хочу, чтобы мне выдавалось около 10 внутренних неймспейсов, между которыми методы разгруппированы ПО СМЫСЛУ. Кстати, кроме иерархических неймспейсов можно ввести и "теги", правда это я еще не обдумывал.


Аааа. Ну это я даже не видел Особенно в контексте этой подветки.

Тогда хз. Это, по-моему, вообще мало где реализуемо


dmitriid.comGitHubLinkedIn
Re[8]: namespace'ы в классах
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 05.02.12 07:45
Оценка: 2 (1)
Здравствуйте, Privalov, Вы писали:

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


C>>Помнится участвовал в Авалоне, был быстро с треском изгнан . Из-за стиля работы "пишу как хочу и класть мне на остальную команду".


P>Сдается мне, он участвовал не только в Авалоне. В свое время весьма доставил этот
Автор: AndrewVK
Дата: 12.03.05
диалог.


Мнэээ... спасибо, посмеялся — больше с AndrewVK и RSDN'овцев, чем с Шеридана. Ибо подобные вопросы при нормальном ведении проекта через сколь-нибудь внятную SCM//VCS (которых 6 лет назад уже было пруд пруди) в принципе не возникли бы. Особенно при распределённой разработке публичного проекта — в центр бы всё попадало только через pull request, при котором код хотя бы приблизительно проверяется глазами на внятность изменений и на соответствие им commit messages, и просто случайно зацепить файл, в котором чего-то корячил и не доработал, не получится.

А без SCM, конечно, уже через полгода забудешь, что делал и почему, при том, что часто смотришь на код годовой давности и думаешь "под какими веществами я был, когда писал это?" Так что jIMHO этот пример Шеридану только в плюс
The God is real, unless declared integer.
Re[12]: namespace'ы в классах
От: jazzer Россия Skype: enerjazzer
Дата: 06.02.12 02:33
Оценка: 2 (1)
Здравствуйте, Mamut, Вы писали:

S>>>>К тому, что в сторону ц++ высказываются в похожем стиле.

M>>>Ну, если ты неспособен понять, что тебе пишут, то да, конечно, именно так и высказываются

S>>До сих пор никто не смог повторить на других языках реализацию нэймспейсов в классах. Да, конечно, мне не понять, ага.


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


Не вопрос. Продемонстрируй решение проблемы "автокомплит по группам методов" на других языках, в которых есть понятие "класс", раз в Эрланге его нет
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[16]: namespace'ы в классах
От: hattab  
Дата: 06.02.12 20:21
Оценка: 2 (1)
Здравствуйте, Mamut, Вы писали:

M> Что предложил jazzer?

M>

M> Продемонстрируй решение проблемы "автокомплит по группам методов" на других языках


M> Каким образом вопрос jazzer'а относится к предыдущим двум цитатам?


Это вообще-то не джаззер предложил, это икс-код свою мысль развил
Автор: x-code
Дата: 03.02.12
:

Не. У меня есть объект конкретного класса, у которого внутри сотни методов, полученных ЛЮБЫМ путем, может быть — длинная цепочка наследования, может быть все сразу объявлены, неважно. Я в IDE пишу "obj." и мне автокомплит выдает ПРОСТЫНЮ из методов, отсортированных тупо в алфавитном порядке. А я хочу, чтобы мне выдавалось около 10 внутренних неймспейсов, между которыми методы разгруппированы ПО СМЫСЛУ. Кстати, кроме иерархических неймспейсов можно ввести и "теги", правда это я еще не обдумывал.

avalon 1.0rc3 build 428, zlib 1.2.3
Re[2]: И снова про ц++
От: LaptevVV Россия  
Дата: 03.02.12 06:41
Оценка: 1 (1)
Здравствуйте, x-code, Вы писали:

S>>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++? Указатели? Да фигня это, на пару граблей наступить и рефлекс появится. Зато более шустрый софт получается.

S>>Так все же?

XC>Ужасная система #include и препоцессора, отсутствие нормальной модульной системы

Абсолютно согласен!
XC>Отсутствие вложенных блочных комментариев
Это мелочь
XC>Имя массива является адресом первого элемента массива (нелогично! со структурами же не так)
ИМХО для С это было самое то! Но для С++, который позиционируется как язык более высокого уровня, — это анахронизм.
XC>Отсутствие низкоуровневых возможностей: sizeof( ) от функции и блока кода, goto на переменные метки (в gcc есть, но это нестандартно)
Зачем?
XC>Невозможность передачи массивов в фигурных скобках "как есть" в функции Foo({1,2,3});
Если бы массивы были полноценные объекты — это было бы самое то!
XC>Отсутствие именованных блоков кода, соответственно невозможность сделать break и continue на именованный блок/из блока
Это мелочь. Особенно ghyb наличии goto/ Если goto убрать, то да.
XC>Отсутствие методов-расширений, отсутствие возможности обращаться к методу класса как к статическому с явной (ручной) передачей this
Сильно напрягает?
XC>Отсутствие системы сообщений как в ObjectiveC, встроенной системы сигналов и слотов как в QT
А где такое еще есть?
XC>Невозможность создания namespace внутри класса (вспомните хотя-бы "главные оконные классы" разных библиотек — CWnd, QWidget... сотни методов, там разделение не помешало бы)
ИМХО сотни методов — это проблема реализации. И следствие отсутствия нормальной модульности.
Но вообще да, не помешало бы сделать пространство имен возможным на любом уровне, хоть в функциях.
XC>Отсутсвие вложенных функций (даже в турбо паскале вроде были), а лямбды в C++11 на редкость кривые

XC>Отсутствие замыканий, простого объявления функциональных типов (int=>int)
А надо?
XC>Отсутствие кортежей, групповых операций над кортежами, невозможность вернуть из функции несколько значений напрямую
Напрямую — это как?
В новом стандарте разве нет таплов в STL?
XC>Отсутствие опциональной возможности структуной типизации
XC>Оператор :: вместо точки (некрасиво)
Точка — локально, 4 точки — глобально?
XC>Ужасно громоздкая система шаблонов (каждый раз писать template), и тенденция использования шаблонов не по назеначению (метапрограммирование на них)
Это — да-да-да!!!!
XC>При этом отсутсивие полноценной системы метапрограммирования (типа как в Nemerle, хотя я бы сделал еще лучше)
Полезная весчь — метапрограммирование.
XC>Отсутствие полноценной рефлексии и атрибутов (как в C#)
Согласен.
XC>Отсутствие встроенной параллельности и каналов (как в Go)
Удивляет, что до сих пор не реализовали. Хоря в стандарт новый включили.
XC>Отсутствие свойств (properties) как в C# (хотя и в C# можно еще кое-что улучшить)
Я как-то обхожусь. Но в некоторых реализациях С++ бывает
XC>Да еще много чего, сразу все и не вспомнить...
Короче, хотелось бы всего...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[3]: И снова про ц++
От: Mamut Швеция http://dmitriid.com
Дата: 03.02.12 10:12
Оценка: 1 (1)
S>>>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++?
D>>учи дальше плюсы.
S>Чем дальше вникаю тем больше нравится.

Пока что ты даже близко не начал вникать. Потому что Qt, который, как кто-то правильно сказал, это дотнет для бедных
Автор: Mamut
Дата: 23.07.08


dmitriid.comGitHubLinkedIn
Re[4]: И снова про ц++
От: Sheridan Россия  
Дата: 03.02.12 20:41
Оценка: 1 (1)
Здравствуйте, jazzer, Вы писали:

J>Вон Немерле — хороший язык, и где он? А если мелкософт его попиарит в стиле "больше шарпа не будет, следующий шарп — это Немерле" — угадай, насколько вырастет его доля через год-два, и на какой строчке он будет в каком-нть ТИОБЕ.

Дело в том, что ц++ переживет и земноводных и немерле с хаскелями, как уже пережил вижуалбэйсик например.
Matrix has you...
Re[8]: И снова про ц++
От: hattab  
Дата: 04.02.12 05:29
Оценка: 1 (1)
Здравствуйте, Artifact, Вы писали:

A> H>О-о-о... Аргументы что надо На дельфях это тоже можно изобразить не меньшим числом вариантов


A> По крайней мере на один меньше. Едва ли это считается нормальным в Дельфи выводить строку в консоль при помощи перегруженного оператора сдвига влево (если это вообще возможно).


Делать так, разумеется, никто не станет, хотя это возможно.

A> Суть в том, что в других языках нет такого большого разброса в стилях как в C++.


Это есть в любом языке с длинной историей.

A> Вы можете писать в стиле Си с классами, а можете в стиле "я тоже сам себе Александреску", а можете вообще писать как на Си — разница как между небом и землёй. Плюс вы будете использовать библиотеки, стили которых тоже будут отличаться.


И на дельфях народ пишет очень поразному. Кто-то пользуется рудиментарными Objects и строят на ни целые библиотеки (KOL тому пример). Кто-то использует только процедурное программирование, кто-то использует смесь из процедурного с объектно ориентированным. Кто-то пользуется файловыми потоками, кто-то функциями RTL для чтения файлов. О каком единстве можно говорить

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


Ну это вообще не правда. Уж в чем в чем, а в правилах форматирования кода единства нет нигде, кроме случаев, когда оные определяются сверху.
avalon 1.0rc3 build 428, zlib 1.2.3
Re[10]: И снова про ц++
От: FR  
Дата: 04.02.12 15:06
Оценка: 1 (1)
Здравствуйте, Cadet, Вы писали:


C>Смысл именно в том, что нет нужного метода, но ты можешь написать внешнюю функцию, которая при вызове будет выглядешь как метод. К примеру:

C>
C>var fileContent = File.Read()...
C>fileContent.RemoveDuplicates().Compress().ToBase64().SendToServer();
C>

C>ИМХО выглядит сильно читабельнее чем

Используя это http://www.boost.org/doc/libs/1_48_0/libs/range/doc/html/range/reference/adaptors/introduction.html
выглядеть будет не менее читабельно примерно так:

auto fileContent = File.Read() | fileContent | RemoveDuplicates() | Compress() | ToBase64() | SendToServer();


И весьма похоже на OCaml/F#
let fileContent = File.Read |> fileContent |> RemoveDuplicates |> Compress |> ToBase64 |> SendToServer;
Re[8]: И снова про ц++
От: enji  
Дата: 05.02.12 08:11
Оценка: 1 (1)
Здравствуйте, Artifact, Вы писали:

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


H>>О-о-о... Аргументы что надо На дельфях это тоже можно изобразить не меньшим числом вариантов


A>По крайней мере на один меньше. Едва ли это считается нормальным в Дельфи выводить строку в консоль при помощи перегруженного оператора сдвига влево (если это вообще возможно).

В 2007 уже можно так сделать
A>Суть в том, что в других языках нет такого большого разброса в стилях как в C++. Вы можете писать в стиле Си с классами, а можете в стиле "я тоже сам себе Александреску", а можете вообще писать как на Си — разница как между небом и землёй.
Да ладно. На дельфи можно тоже писать в куче стилей. Можно в классическом паскале, можно с ооп... Можно с кучей глобальных переменных, можно нет...
A>Плюс вы будете использовать библиотеки, стили которых тоже будут отличаться. Ну и в довесок С++ просто чемпион по количеству способов форматирования кода.
Вы не поверите, но есть куча способов форматирования кода на любом языке, кроме может быть тех, где стиль форматирования — требование компилятора. Почитайте макконелла к примеру — там куча вариантов и нет указания языка.
A>В других языках люди как-то незаметно для себя учаться придерживаться одного, фактически официального стиля, но только не в С++.
Обычно придерживаешься стиля главной либы, которой пользуешься. В С++ с этим разброс — есть либы в стиле с, есть в стиле шарпа\явы, есть венгерская нотация... Ну так язык старый и вобрал в себя много всего.
Re[4]: И снова про ц++
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 05.02.12 08:24
Оценка: 1 (1)
Здравствуйте, Ночной Смотрящий, Вы писали:

N>>Если речь про схему в стиле Вирта

НС>Думаю, речь про модульность, а не про "схему в стиле Вирта". Которая присутствует и в джаве и в дотнете.

Плюнь в глаза каждому, кто скажет, что в C или C++ нет модульности. Потому что она есть. Разные части кода можно раздельно компилировать, группировать в подключаемые библиотеки, описывать для них интерфейсы. Это и есть модульность. То, что в Java или C# описание объявлений обязательно "впечатывается" в скомпилированный модуль, не увеличивает модульность, а уменьшает её — за счёт невозможности физически отделить описание интерфейса от содержания реализации.

N>>Зато подход с заголовочными описаниями распространяется практически на все языки.

НС>"Все языки" это С++ что ли?

Я сталкивался с заголовочными файлами, отдельными от собранных модулей, в: C, C++ (очевидно), ассемблерах, Fortran, Erlang — это только те, что с ходу вспомнились и для которых есть штатное применение по стандарту или в распространённых средах. Думаю, я знаю менее 1/3 от полного списка примеров. Но я вообще-то имел в виду не то — не те языки, где оно заложено изначально, а те, на которые оно может быть относительно легко распространено (пусть и внешним проходом через препроцессор).

XC>>>Отсутствие методов-расширений, отсутствие возможности обращаться к методу класса как к статическому с явной (ручной) передачей this

N>>Что такое методы-расширения я не понял.
НС>Это синтаксический сахар для вызова статических методов (и, видимо, свободных функций в случае С++)

Тогда непринципиально.

N>>Вызов метода как статического — а зачем?

НС>Нет — вызов статического метода. Автоматическая замена такого выражения:
НС>
НС>X.A(Y.B(Z.C()))
НС>

НС>На такое:
НС>
НС>X.A().B().C();
НС>

НС>Весьма помогает в ряде сценариев, например при использовании всяких монадных штук.

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

XC>>>Отсутствие системы сообщений как в ObjectiveC, встроенной системы сигналов и слотов как в QT

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

Хм, неужели недостаточно какого-нибудь hash<> в одном из полей класса и одного метода с простым лукапом?

XC>>>Отсутсвие вложенных функций (даже в турбо паскале вроде были),

N>>Суровой необходимости не вижу, если не считать те же замыкания.
НС>Но очень удобно.

В целом согласен.

XC>>> а лямбды в C++11 на редкость кривые

XC>>>Отсутствие замыканий,
N>>Вот для замыканий неплохо бы было увидеть библиотеку в стиле boost, но для C.
N>>Чтобы умела хотя бы для основных платформ генерировать замыкания.
НС>Без поддержки со стороны языка это будет очередной уродец.

Оно просто будет платформенно-зависимо. Например, для i386 AKA x86-32 для стандартных конвенций вызова просто будет сгенерирован (при исполнении) код, который добавляет одно или несколько слов на стек между адресом возврата и первым параметром и делает переход на заданный адрес. Для других может быть сложнее (например, для amd64 придётся двигать регистры), но тоже беспроблемно реализуемо. (Кстати, gcc именно так и поступает со вложенными функциями, если на них берётся указатель.) В остальном оно будет не корявее STL. Хотя если для тебя это уродец, то мне возразить нечего.

XC>>>Отсутствие опциональной возможности структуной типизации

N>>?
НС>Это, видимо, утиная типизация имеется в виду.

Сомневаюсь, но послушаем исходного оратора. Слай-ды! (tm)

XC>>>Отсутствие встроенной параллельности и каналов (как в Go)

N>>Это возлагается на библиотеки.
НС>Но поддержка со стороны языка была бы весьма пользительна. Хотя бы в виде шарповских async/await.

Забавный сахар, мне на первый взгляд понравился. Теперь бы послушать критику...
The God is real, unless declared integer.
Re[22]: namespace'ы в классах
От: Sheridan Россия  
Дата: 05.02.12 13:22
Оценка: 1 (1)
Здравствуйте, Mamut, Вы писали:

M>>>Итак, повторяю вопрос: нахрена тебе что-то объяснять, если ты не знаешь и знать не хочешь?

S>>Примеры будут? Или слив засчитаем таки? Код покажешь или продолжишь воздух сотрясать?

M>Сотрясает воздух здесь ровно один человек: ты.


M>Миксины: http://en.wikipedia.org/wiki/Mixin

M>Extension methods: http://msdn.microsoft.com/en-us/library/bb383977.aspx
M>Partial classes and methods: http://msdn.microsoft.com/en-us/library/wa80x488.aspx

M>Но тебе эти ссылки будут бесполезны: ты не способен понять, о чем в них говорится


Во всех трех так или иначе говорится о расширении существующего функционала классов, я правильно понимаю?

В любом случае я нацеливался на следующее поведение:
Если я изначально понял задачу — была жалоба на отсутствие неймспейсов внутри класса и вследствии этого неудобство использования данных классов, ежели в них over9k методов изза отсутствия возможности объединения схожих.
То что я реализовал — позволит разбить методы на группы и каждую группу положить в свой неймспейс, что потом при автокомплите не ковыряться, а сначала выбирать неймспейс, затем метод. Например widget->orientation->setPos() или socket->exchange->send() или database->query->execute()
И насколько я понимаю — чтото похожее на неймспейсы классов реализуется только в Partial classes and methods. И то — мне интересно как будет себя вести автокомплит в данном случае.
Matrix has you...
Re[23]: Наследование
От: Sheridan Россия  
Дата: 09.02.12 10:28
Оценка: 1 (1)
Здравствуйте, hattab, Вы писали:

H>Есть результат?

Полчаса поковырялся. Буквально на коленке сделал. Можно еще попробовать причесать конечно, но вот рабочее:

gate ~ # cat example.cpp

#include <iostream>
using namespace std;

#define C_NAMESPACE_BASE(_base) m_##_base
#define C_NAMESPACE_BEGIN(_ns, _base) \
public: class class##_ns \
  { \
    protected: \
      _base *C_NAMESPACE_BASE(_base); \
    public: \
      class##_ns(_base *v_##_base) { C_NAMESPACE_BASE(_base) = v_##_base; };

#define C_NAMESPACE_BEGIN_INHERITS(_ns, _base, _parent) \
public: class class##_ns : public _parent::class##_ns\
  { \
    protected: \
      _base *C_NAMESPACE_BASE(_base); \
    public: \
      class##_ns(_base *v_##_base) : _parent::class##_ns(v_##_base) {};

#define C_NAMESPACE_END(_ns) \
  }; \
  public: class##_ns *_ns;

#define C_NAMESPACE_INIT(_ns) _ns = new class##_ns(this);
#define C_NAMESPACE_DELETE(_ns) delete _ns;
#define C_NAMESPACE_PATH(_ns, _base) _base::class##_ns

class Parent
{
  C_NAMESPACE_BEGIN(SubNS, Parent)
  void f();
  C_NAMESPACE_END(SubNS)

  C_NAMESPACE_BEGIN(OtherNameSpace, Parent)
  void f();
  void other();
  C_NAMESPACE_END(OtherNameSpace)

  public:
  Parent() { C_NAMESPACE_INIT(SubNS) C_NAMESPACE_INIT(OtherNameSpace) }
  ~Parent() { C_NAMESPACE_DELETE(SubNS) C_NAMESPACE_DELETE(OtherNameSpace) }
  int c() { return 123; }
};

void C_NAMESPACE_PATH(SubNS, Parent)::f()
{
  cout << "Hi, " << C_NAMESPACE_BASE(Parent)->c()  << " from base!" << endl;
}

void C_NAMESPACE_PATH(OtherNameSpace, Parent)::other()
{
  cout << "Hi from base other!" << endl;
}

void C_NAMESPACE_PATH(OtherNameSpace, Parent)::f()
{
  cout << "Hi, " << C_NAMESPACE_BASE(Parent)->c()  << "! This is other namespace :))" << endl;
}

// -----------------------------------------------------------------------------------------------------------------------------
class Child : public Parent
{
  C_NAMESPACE_BEGIN_INHERITS(SubNS, Child, Parent)
  void foo();
  C_NAMESPACE_END(SubNS)

  public:
  Child() { C_NAMESPACE_INIT(SubNS) }
  ~Child() { C_NAMESPACE_DELETE(SubNS) }
};

void C_NAMESPACE_PATH(SubNS, Child)::foo()
{
  cout << "Hi, " << C_NAMESPACE_BASE(Child)->c()  << " from child foo!" << endl;
}
// -----------------------------------------------------------------------------------------------------------------------------
class Deeper : public Child
{
  C_NAMESPACE_BEGIN_INHERITS(SubNS, Deeper, Child)
  void bar();
  C_NAMESPACE_END(SubNS)

  C_NAMESPACE_BEGIN_INHERITS(OtherNameSpace, Deeper, Child)
  void other();
  C_NAMESPACE_END(OtherNameSpace)

  public:
  Deeper() { C_NAMESPACE_INIT(SubNS) C_NAMESPACE_INIT(OtherNameSpace) }
  ~Deeper() { C_NAMESPACE_DELETE(SubNS) C_NAMESPACE_DELETE(OtherNameSpace) }
};

void C_NAMESPACE_PATH(SubNS, Deeper)::bar()
{
  cout << "Hi, " << C_NAMESPACE_BASE(Deeper)->c()  << " from Deeper bar!" << endl;
}

void C_NAMESPACE_PATH(OtherNameSpace, Deeper)::other()
{
  cout << "Hi from Deeper other!" << endl;
}

// -----------------------------------------------------------------------------------------------------------------------------
int main ()
{
  Parent *p = new Parent();
  p->SubNS->f();
  p->OtherNameSpace->other();
  p->OtherNameSpace->f();
  delete p;
  cout << "-------------------------" << endl;
  Child *c = new Child();
  c->SubNS->foo();
  c->SubNS->f();
  delete c;
  cout << "-------------------------" << endl;
  Deeper *d = new Deeper();
  d->SubNS->bar();
  d->SubNS->foo();
  d->SubNS->f();
  d->OtherNameSpace->other();
  delete d;
}



gate ~ # ./example
Hi, 123 from base!
Hi from base other!
Hi, 123! This is other namespace :))
-------------------------
Hi, 123 from child foo!
Hi, 123 from base!
-------------------------
Hi, 123 from Deeper bar!
Hi, 123 from child foo!
Hi, 123 from base!
Hi from Deeper other!
Matrix has you...
Re: И снова про ц++
От: denisko http://sdeniskos.blogspot.com/
Дата: 03.02.12 06:36
Оценка: -1
Здравствуйте, Sheridan, Вы писали:

S>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++?

учи дальше плюсы.
S>Указатели? Да фигня это, на пару граблей наступить и рефлекс появится.
Это к плюсам вообще не имеет отношения.
S>Зато более шустрый софт получается.
По сравнению с чем?
<Подпись удалена модератором>
Re[5]: И снова про ц++
От: jazzer Россия Skype: enerjazzer
Дата: 03.02.12 07:25
Оценка: +1
Здравствуйте, netch80, Вы писали:

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


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


N>>>В принципе согласен. Более того, система namespace неудобна.

N>>>Постоянно хочется решений в стиле питоновского import X.Y.Z as W.
J>>чем не устраивает
J>>
J>>namespace W = X::Y::Z;
J>>

J>>

N>Это давно появилось? Я такого ещё не видел.

Всегда было, см. 7.3.2 [namespace.alias] в С++98.

N>Оно действует на полные символы или только на пространства?

Я не очень понял, в чем вопрос.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[6]: И снова про ц++
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.02.12 08:26
Оценка: -1
Здравствуйте, Философ, Вы писали:

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

N>>Здравствуйте, Философ, Вы писали:
Ф>>Здравствуйте, LaptevVV, Вы писали:

LVV>>>>ИМХО для С это было самое то! Но для С++, который позиционируется как язык более высокого уровня


N>>А что такое Ваше "язык более высокого уровня", известно только Вам. Насколько более высокого? На миллиметр, километр, 3 слоя или ровно на одну морковку?


Ф>адресатом ошибся


Нет, не ошибся. Фраза "Если ЦПП позиционируется как язык более высокого уровня, то в нём вообще не должно быть даже намёка на strlen/strcpy (а так же calloc/malloc/memcpy)." — Ваша, а не Лаптева.
Лаптева я спрошу отдельно.
The God is real, unless declared integer.
Re[5]: И снова про ц++
От: x-code  
Дата: 03.02.12 09:11
Оценка: +1
Здравствуйте, LaptevVV, Вы писали:

XC>>>>Отсутствие вложенных блочных комментариев

LVV>>>Это мелочь
XC>>Из мелочей состоит все. И красота языка программирования именно в мелочах. Я кстати придумал третий совершенно новый и очень удобный вид комментариев (кроме блочных и однострочных).
LVV>Покажь! Мы в свой язык и среду добавим — со ссылкой на автора.

Комментарии лексически корректного блока.
rem if(x>0) { 
  // ...
  while(b) {
      // ...
      for(int i=0; i<n; i++)
       {
          // ...
       }
  }
  x = y;
  // ...
}

Можно закомментировать целый блок, к такому блоку применяется только лексический анализ и базовое построение AST, без проверки всего остального. То есть если у блока корректно расставлены скобки, то неважно что там внутри (несуществующие переменные и т.д.) — его можно закомментировать. В простейших случаях можно сымитировать, подставляя в блоки невыполнимые условия "if(0)" и т.п. Но если сделать это отдельным ключевым словом, то получим кучу преимуществ — это воспринимается как осмысленное действие, а не как случайная ошибка программиста; в IDE поялвяется возможность подсветки; ну и упрощенный парсинг кода позволит не ругаться на возможных ошибках.

XC>>Если возможность может быть, она ДОЛЖНА быть.

LVV>Не согласен. Тут чувство меры разработчика большую рояль играет.
LVV>Иначе вместо языка получим большую кучу сами знаете чего.

Ну это мое личное ИМХО. Мне нравятся языки возможностей, а не языки ограничений. А большую кучу можно получить из чего угодно, достаточно просто захотеть от языка немного больше того, на что он рассчитан. Пример — С++ с шаблонами и попытками метапрограммирования на них.
Был бы в С++ вместо препроцессора макропроцессор, работающий с AST, с грамотно спроектированным синтаксисом — никто бы даже не полез на шаблонах что-то такое делать...

XC>>>>Невозможность создания namespace внутри класса (вспомните хотя-бы "главные оконные классы" разных библиотек — CWnd, QWidget... сотни методов, там разделение не помешало бы)

LVV>>>ИМХО сотни методов — это проблема реализации. И следствие отсутствия нормальной модульности.
XC>>Да пусть у меня всего 4 метода в классе, но я хочу разделить их в две группы, что не имею права?
LVV>А два класса написать с общим абстрактным предком — не?

Не. У меня есть объект конкретного класса, у которого внутри сотни методов, полученных ЛЮБЫМ путем, может быть — длинная цепочка наследования, может быть все сразу объявлены, неважно. Я в IDE пишу "obj." и мне автокомплит выдает ПРОСТЫНЮ из методов, отсортированных тупо в алфавитном порядке. А я хочу, чтобы мне выдавалось около 10 внутренних неймспейсов, между которыми методы разгруппированы ПО СМЫСЛУ. Кстати, кроме иерархических неймспейсов можно ввести и "теги", правда это я еще не обдумывал.

XC>>Код должен быть простым. Если я хочу объявить аргумент "функцию, принимающую на вход int и возвращающую int", я хочу сделать это максимально простым и естественным способом: "int=>inf f" и передавать туда что угодно — метод класса, глобальную функцию, лямбду, функтор с перегруженным operator() и т.д. Это должно работать без шаблонов, если я хочу без шаблонов.

LVV>Вот насчет "передавать что угодно" я сильно против. Зачем тогда тип указывать? Пусть принимает any и возвращает any...
Что угодно, удовлетворяющее условию "принимает int и возвращает int". Any — это тоже хорошо, но не в данном случае.
Re[6]: И снова про ц++
От: jazzer Россия Skype: enerjazzer
Дата: 03.02.12 09:32
Оценка: +1
Здравствуйте, x-code, Вы писали:

XC>Не. У меня есть объект конкретного класса, у которого внутри сотни методов, полученных ЛЮБЫМ путем, может быть — длинная цепочка наследования, может быть все сразу объявлены, неважно. Я в IDE пишу "obj." и мне автокомплит выдает ПРОСТЫНЮ из методов, отсортированных тупо в алфавитном порядке. А я хочу, чтобы мне выдавалось около 10 внутренних неймспейсов, между которыми методы разгруппированы ПО СМЫСЛУ. Кстати, кроме иерархических неймспейсов можно ввести и "теги", правда это я еще не обдумывал.


Ну так это проблема IDE, а не проблема языка.
Решается, например, доксигеном, в котором можно объединять члены в именованные группы — просто надо сделать, чтоб IDE их понимал.

XC>>>Код должен быть простым. Если я хочу объявить аргумент "функцию, принимающую на вход int и возвращающую int", я хочу сделать это максимально простым и естественным способом: "int=>inf f" и передавать туда что угодно — метод класса, глобальную функцию, лямбду, функтор с перегруженным operator() и т.д. Это должно работать без шаблонов, если я хочу без шаблонов.

LVV>>Вот насчет "передавать что угодно" я сильно против. Зачем тогда тип указывать? Пусть принимает any и возвращает any...
XC>Что угодно, удовлетворяющее условию "принимает int и возвращает int". Any — это тоже хорошо, но не в данном случае.

еще раз: чем тебя не устраивает std::function<int(int)>?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[9]: И снова про ц++
От: Mamut Швеция http://dmitriid.com
Дата: 03.02.12 10:52
Оценка: :)
M>>Ничего он не позволяет. Все вышеописанное — это не прелесть, а костыли для обхода того факта, что нормальных строк в С++ нет. Поэтому каждый пишет собственные велосипеды, которые еще и между собой несовместимы.

O>Критерий нормальности строк, пожалуйста. Иначе как-то необъективно.


Вообще-то, в 21-м веке нормальность — это поддержка хотя бы utf8. У С++ с этим вообще швах. Во всех остальных — кто на что горазд

Ну и да, количество реализаций строк для С++ намекает на то, что в консерватории что-то не так. А rationale для этих реализаций искать лень.


dmitriid.comGitHubLinkedIn
Re[4]: И снова про ц++
От: x-code  
Дата: 03.02.12 11:34
Оценка: :)
Здравствуйте, gegMOPO4, Вы писали:

XC>>> отсутствие нормальной модульной системы

N>>Если речь про схему в стиле Вирта (тут interface, а тут implementation), то несложно заметить, что почему-то она не прижилась в промышленности и не была принята ни в одном языке, начатом "с нуля", заведомо позже массового распространения Паскаля. Например, она не была принята ни в Java ни в C#. Зато подход с заголовочными описаниями распространяется практически на все языки. Я думаю, у "нормальной модульной системы" всё-таки есть какой-то фатальный недостаток.

MOP>Где ещё, кроме C/C++ (и нескольких непродуманных язычков вроде PHP) используется «модульность» на основе #include? Как раз в Java отдельный файл — отдельный класс, единица трансляции, пространство имён, единица организации кода.


MOP>Есть два преимущества системы C — раздельная компиляция и совместимость со старым кодом на ассемблере и Фортране. Первое сейчас не критично, в память влазит полностью и файл-исходник, и выход, и промежуточное представление, и интерфейсы других модулей. Совместимость же сейчас интереснее с другими языками (Java, Python,...).


Ну вот в C# вроде нормальная модульная система. Раздельная компиляция, но никаких include, То, что объявлено в одном файле, свободно доступно в другом. Я не думаю что такое сложно сделать для нативного языка типа С++.
При чем тут совместимость с кодом на других языках — вообще непонял.
Re[6]: И снова про ц++
От: Banned by IT  
Дата: 03.02.12 11:40
Оценка: +1
Здравствуйте, x-code, Вы писали:

XC>Комментарии лексически корректного блока.

XC>
rem if(x>0) { 
XC>  // ...
XC>  while(b) {
XC>      // ...
XC>      for(int i=0; i<n; i++)
XC>       {
XC>          // ...
XC>       }
XC>  }
XC>  x = y;
XC>  // ...
XC>}


IMHO это мало кому нужно чтоб добавлять в язык.

XC>Не. У меня есть объект конкретного класса, у которого внутри сотни методов, полученных ЛЮБЫМ путем, может быть — длинная цепочка наследования, может быть все сразу объявлены, неважно. Я в IDE пишу "obj." и мне автокомплит выдает ПРОСТЫНЮ из методов, отсортированных тупо в алфавитном порядке. А я хочу, чтобы мне выдавалось около 10 внутренних неймспейсов, между которыми методы разгруппированы ПО СМЫСЛУ. Кстати, кроме иерархических неймспейсов можно ввести и "теги", правда это я еще не обдумывал.

Так это тебе надо в GUI добавлять функциональность а не в язык. А то ты усложняешь язык ради группировки методов в подсказке.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[9]: И снова про ц++
От: x-code  
Дата: 03.02.12 11:41
Оценка: :)
Здравствуйте, okman, Вы писали:

O>Критерий нормальности строк, пожалуйста. Иначе как-то необъективно.


Для меня — полная совместимость всех строк и их "абстрактность".
Я хочу, чтобы строка в кавычках была просто объектом. Чтобы не было даже привязки к кодировке (utf16, utf8, windows...), к внутреннему устройству и т.д.
Чтобы для юникода не писать ужасных _T("hello"). И вообще, строка — это как число, просто абстрактный способ представления данных.

А конкретная реализация строки (std::string, CString, QString...) подключается каким-то образом на этапе компиляции. По умолчанию — стандартная, поставляемая вместе с компилятором. Хочешь нестандартную — например, чтобы все строки хранились в бинарнике в зашифрованном виде — пиши какой-то специальный модуль-плагин к компилятору и подключай. При этом любая нестандартная реализация должна реализовывать некий интерфейс — список операций, которые можно сделать со строкой.
Re[5]: И снова про ц++
От: Andrey.V.Lobanov  
Дата: 03.02.12 12:37
Оценка: -1
Здравствуйте, Mamut, Вы писали:

AVL>>массовым погромистам гораздо проще развешивать лапшу прикрываясь всякими С# 100500 / мета- / фукнциональное программирование / лямбды / монады / linq / макросы / прочая фигня. а да, виртуальные машины забыл, тоже модная тема.

M>Выделенное — не лапша, а очень удобные инструменты. Которые — ВНЕЗАПНО — тоже появляются в С++
странно было бы, если бы человек, покусанный яблочным маркетингом, не утверждал, что вся это модная лапша не является удобной
расскажи что там внезапно появилось в плюсах (можно без лямбд, хотя кому они нужны там...), что тебя на капс пробило.
Re[10]: И снова про ц++
От: Banned by IT  
Дата: 03.02.12 13:01
Оценка: +1
Здравствуйте, x-code, Вы писали:

XC>Я хочу, чтобы строка в кавычках была просто объектом. Чтобы не было даже привязки к кодировке (utf16, utf8, windows...), к внутреннему устройству и т.д.

Добро пожаловать в реальный мир.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[9]: И снова про ц++
От: Cadet  
Дата: 03.02.12 16:53
Оценка: -1
Здравствуйте, Banned by IT, Вы писали:

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


BBI>>>А чем не нравится конструктор string (int x)?


C>>Мне не нравится например тем, что нужного конструктора может не быть.

BBI>А чем это отличается от того, что функции ToStr для типа int (чтоб вызывать как 10.ToStr ()) может не быть?
BBI>Если писать самому так почему не написать string ToStr (int x)?
BBI>Какой смысл вот в этом изврате с 10.ToStr () ?

Смысл именно в том, что нет нужного метода, но ты можешь написать внешнюю функцию, которая при вызове будет выглядешь как метод. К примеру:
var fileContent = File.Read()...
fileContent.RemoveDuplicates().Compress().ToBase64().SendToServer();

ИМХО выглядит сильно читабельнее чем
var fileContent = File.Read()...
SendToServer(ToBase64(Compress(RemoveDuplicates(fileContent))));
... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
Re[5]: namespace'ы в классах
От: Cadet  
Дата: 03.02.12 16:58
Оценка: +1
Здравствуйте, Sheridan, Вы писали:

S>Ничего тут страшного нет ни в читаемости, ни в поддержке, ибо кода в реализации кот наплакал


Да в данном месте наплакал конечно. А в реальном проекте, с исходниками мегабайт ну скажем 5, один так наплакал в одном месте, другой в другом, третий в третьем. А потом ты рыдаешь, когда продираешься через это в поисках ошибки.
... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
Re: И снова про ц++
От: goondick  
Дата: 03.02.12 18:04
Оценка: +1
Здравствуйте, Sheridan, Вы писали:

S>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++? Указатели? Да фигня это, на пару граблей наступить и рефлекс появится. Зато более шустрый софт получается.

S>Так все же?

это реакция людей ко всему непонятному и что не дано понять...
Re[7]: И снова про ц++
От: Artifact  
Дата: 03.02.12 20:39
Оценка: :)
Здравствуйте, hattab, Вы писали:

H>О-о-о... Аргументы что надо На дельфях это тоже можно изобразить не меньшим числом вариантов


По крайней мере на один меньше. Едва ли это считается нормальным в Дельфи выводить строку в консоль при помощи перегруженного оператора сдвига влево (если это вообще возможно). Суть в том, что в других языках нет такого большого разброса в стилях как в C++. Вы можете писать в стиле Си с классами, а можете в стиле "я тоже сам себе Александреску", а можете вообще писать как на Си — разница как между небом и землёй. Плюс вы будете использовать библиотеки, стили которых тоже будут отличаться. Ну и в довесок С++ просто чемпион по количеству способов форматирования кода. В других языках люди как-то незаметно для себя учаться придерживаться одного, фактически официального стиля, но только не в С++.
__________________________________
Не ври себе.
Re[2]: И снова про ц++
От: trop Россия  
Дата: 04.02.12 05:31
Оценка: :)
Здравствуйте, InfoPilot, Вы писали:
IP>С++ как высшая математика, не каждый его понимает и не каждому она доступна по умственному потенциалу, но с помощью него делаются реальные вещи.

тем не менее в серъезных областях его испольщуют минимаьлно или не используют
например в nasa запрет на c++ на любых аппаратах, то же самое в военной авионике,
в системах наведения ,робототехнике. ьам только с

напротив, lisp использовался по крайней мере на одном космическом аппарате, в виде модуля отладки
-
Re[12]: И снова про ц++
От: okman Беларусь https://searchinform.ru/
Дата: 04.02.12 05:46
Оценка: +1
Здравствуйте, Cadet, Вы писали:

C>Ага, в плюсах этого нет, значит этого не надо . А вообще забавно смотреть, как плюсовики, ранее кричавшие про ненужность var в шарпе к примеру, резко полюбили auto с выходом С++ 11. Это же не var, это auto, разница огромна .


IMHO использовать auto из C++11 надо с крайней осторожностью. Хотя бы потому, что выбор типа
производится неявно. Короче, есть риск наступить на маленькие, но коварненькие грабельки.
А вообще, "вопли радости" плюсовиков по поводу скинутых сверху подачек от нормальных, правильных,
языков, сильно преувеличены.
Re[5]: И снова про ц++
От: jazzer Россия Skype: enerjazzer
Дата: 04.02.12 13:41
Оценка: +1
Здравствуйте, Sheridan, Вы писали:

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


J>>Вон Немерле — хороший язык, и где он? А если мелкософт его попиарит в стиле "больше шарпа не будет, следующий шарп — это Немерле" — угадай, насколько вырастет его доля через год-два, и на какой строчке он будет в каком-нть ТИОБЕ.

S>Дело в том, что ц++ переживет и земноводных и немерле с хаскелями, как уже пережил вижуалбэйсик например.
Ну так и лисп с фортраном успешно всех переживают, и даже кобол, прости господи
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[5]: И снова про ц++
От: Young yunoshev.ru
Дата: 04.02.12 15:22
Оценка: :)
Здравствуйте, FR, Вы писали:

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



Y>>Не понял.... Собственно речь как раз и идет о том, что язык должен обеспечивать невозможность сайд-эффектов.


FR>То есть пишем только на сильно ограниченном подмножестве Хаскеля?


Ага. Хотя я скорее про подмножество Эрланга.
Re[5]: И снова про ц++
От: Young yunoshev.ru
Дата: 04.02.12 19:39
Оценка: -1
Здравствуйте, okman, Вы писали:

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


Y>>Собственно речь как раз и идет о том, что язык должен обеспечивать невозможность сайд-эффектов.


O>Вот давайте порассуждаем над этим тезисом.

O>Итак, есть массив. Все согласны, что выход за границы массива — зло ? Ок.

А давайте допустим у нас нету массива — есть списки, кортежи и т.п. А массива нет.
Сильно хуже будет?

O>Теперь предположим, что мы пишем некий алгоритм и точно знаем, что выход за границы

O>массива невозможен. Например, в этот массив попадают только символы английского алфавита.
O>Их 26. Вопрос — зачем нам лишние проверки на предмет выхода за его границы, если у нас
O>это условие обеспечивается корректностью самого алгоритма (да еще набором юнит-тестов в
O>придачу) ? В C++ такие проверки обычно не мешают, но в ряде случаев они становятся причиной
O>ухудшения производительности. И именно по этой причине массивы в C и C++ реализованы
O>наиболее близким и естественным для платформы способом — как последовательность ячеек памяти,
O>и никаких size(), capacity() и проверок индекса при попытке чтения-записи.
O>Кому надо — берет std::vector. Короче, в описанном примере сайд-эффектом как раз
O>является не выход за пределы массива, а лишние проверки, плохо влияющие на перфоманс.

Знаете, лет 15 назад я бы разделил вашу печаль..
Но в текущий момент я (занимаясь разработкой игр под мобильные платформы замечу) — не могу представить себе реальной ситуации, в которой при размере массива в 26 ячеек мне было бы дело до того — есть там проверки или нету там проверок.

Более, того — я предпочту чтобы проверки были — ибо все мы знаем насколько меняются требования — и вполне возможно, что там будут не только символы английского английского алфавита по каким либо внешним причинам (опять же сайд эффекты — изменения в другой части программы могут привести к тому, что на вход нам подадут не символы английского алфавита).

Так что лучше с проверками, а лучше вообще без массивов.
Re[7]: И снова про ц++
От: Young yunoshev.ru
Дата: 04.02.12 19:45
Оценка: :)
Здравствуйте, okman, Вы писали:

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


Y>>А какие возможности вам нужны — из тех которые наиболее часто вызывают сайд эффекты?


Y>>Возможность записать за пределы массива?


O>Нет. Но отключить проверку выхода за пределы массива — да.


Y>>Возможность попортить стек?


O>Нет. Но отключить проверку порчи стека — да.


Y>>Или вообще возможность писать в произвольное место памяти?


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


Y>>А зачем нам получать противоречивое состояние объекта? Нет нельзя. Более того — даже изменить состояние переменной нельзя — она переменная в математическом смысле.


O>Я, вообще-то, писал о том, что на любом языке можно написать код, провоцирующий


Не на любом.

O>возникновение указанных Вами проблем. Можно на C# накатать глобальных переменных и построить

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

Да, именно давайте запрещать глобальные переменные.

Y>>Все верно — у языка есть ряд вещей от которых избавляютя искуственным путем.

Y>>Самый древний пример пожалуй с goto будет.

O>Да, goto. А еще break, continue, вложенные на много уровней if-else, невнятное

O>именование, злоупотребление наследованием, отсутствие инкапсуляции, дублирование и
O>многое другое — все это есть во многих языках, не только в C++.

Да, есть еще много столь же плохих как ц++ языков — и что?
Но есть языки в которых от этого пытаются избавится.
И достаточно успешно.

Y>>Во первых находим слово потенциально в моем утверждении.


O>Ок, погорячился.


Y>>А во вторых — а как можно утверждать что у функции нету сайд эффекта — ничего не зная например о том как у IP_ADDRESS определен оператор сравнения?


O>Каким боком тут C++ ? Этот код мог быть на любом языке. И тоже бы имел

O>обозначенные Вами "сайд-эффекты".

Нет, в том то и дело. Более того — насколько я знаю, в ряде языков, есть возможность чисто математически это доказать — т.е. что код делает именно это и только это.

Но не суть. Когда я в erlang-е вижу такое — мне как-то спокойнее насчет сайд эффектов


is_local_address(IP_Adress) ->
    case IP_Adress of
        "localhost" -> true;
        "127.0.0.1"    -> true;
        _ -> false
end.
Re[6]: namespace'ы в классах
От: Cadet  
Дата: 04.02.12 21:16
Оценка: +1
Здравствуйте, Mamut, Вы писали:

M>Ты хоть раз участвовал в проектах, в которых был больше, чем один программист, и как долго?


Помнится участвовал в Авалоне, был быстро с треском изгнан . Из-за стиля работы "пишу как хочу и класть мне на остальную команду".
... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
Re[2]: И снова про ц++
От: Ночной Смотрящий Россия  
Дата: 04.02.12 21:19
Оценка: +1
Здравствуйте, InfoPilot, Вы писали:

IP>С++ как высшая математика, не каждый его понимает и не каждому она доступна по умственному потенциалу, но с помощью него делаются реальные вещи.


Какая прелесть.

Умственнопотенциальному сколько лет, если не секрет?
Re[13]: И снова про ц++
От: b-3 Россия  
Дата: 04.02.12 22:56
Оценка: :)
Здравствуйте, okman, Вы писали:

C>>есть extension-метод SendToServer.

O>А если SendToServer занимает продолжительное время и ее надо будет использовать асинхронно ?
O>Что дальше — лепим туда еще и мьютекс, рабочий поток, нотификаторы и механизм отмены ?
Ещё обязательно замыканий штуки три, и задействовать dynamic — а то кодер, поддерживающий наш код, не проникнется достаточным уважением.
Забанен с формулировкой "клинический дисидент".
Re[10]: namespace'ы в классах
От: Mamut Швеция http://dmitriid.com
Дата: 04.02.12 23:11
Оценка: +1
M>>Но да, д'Артаньян у нас только и исключительно ты, ага
S>А ты сам бы сравнил то что было (и к чему вернулись) с тем что я сделал. Работу проделал огромную, вдобавок прикрутил логгер, изменяемые меню, нормальные иконки. На все это практически наплевали.

Нет. Ты читай не то, что тебе хочется читать, а то, что тебе люди говорят. Люди, которы знают, что такое командная разработка.

В итоге:
— ты не согласовал свои изменения с другими членами команды
— вместо инекрементальных изменений ты все вывалил в кучу одним скопом, который невозможно смерджить в основную ветку без лома и такой-то матери
— попутно ты поломал ключевой функционал и отказался его чинить

Но да — ты д'Артаньян и навел порядок, ага ага.


dmitriid.comGitHubLinkedIn
Re[12]: namespace'ы в классах
От: Mamut Швеция http://dmitriid.com
Дата: 04.02.12 23:45
Оценка: -1
M>>В итоге:
M>>- ты не согласовал свои изменения с другими членами команды
S>Так вот почему разработка всегда затягивается — бюрократия везде, ага.

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

M>>- вместо инекрементальных изменений ты все вывалил в кучу одним скопом, который невозможно смерджить в основную ветку без лома и такой-то матери

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

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

M>>- попутно ты поломал ключевой функционал и отказался его чинить

S>Не лги. Починил. http://www.rsdn.ru/forum/janus/3488009.1.aspx
Автор: Sheridan
Дата: 31.07.09


Дададада. Буквально следующее сообщение. http://www.rsdn.ru/forum/janus/3489032.aspx
Автор: cencio
Дата: 31.07.09
. Ну, не говоря о том, что такой поломки вообще произойти не должно было (читаем исходную проблему
Автор: Sheridan
Дата: 31.07.09
— кодировка поломана, код не компилится).

S>А вот ты помогать отказывался
Автор: Mamut
Дата: 24.08.09
.


Именно. Я указал причины
Автор: Mamut
Дата: 24.08.09
и не стал лезть что-либо ломать. В отличие от.

И вообще, все написано тут: http://rsdn.ru/forum/janus/3486216.1.aspx
Автор: Anton Batenev
Дата: 30.07.09


Но ты же д'Артаньян, а не мы, так что


dmitriid.comGitHubLinkedIn
Re[12]: И снова про ц++
От: Banned by IT  
Дата: 05.02.12 03:17
Оценка: +1
Здравствуйте, Cadet, Вы писали:

C>как плюсовики, ранее кричавшие про ненужность var в шарпе к примеру

А были такие?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[14]: namespace'ы в классах
От: FR  
Дата: 05.02.12 09:37
Оценка: +1
Здравствуйте, Sheridan, Вы писали:

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

S>Вот когда мне будут за код платить деньги — я буду делать то что надо. До тех пор я буду делать то, что мне интересно.

Не сможешь, во всяком случае сразу, программирование практический навык, и как любой навык базируется на привычках. Их перебарывать будет очень тяжело.
Re[15]: namespace'ы в классах
От: Mamut Швеция http://dmitriid.com
Дата: 05.02.12 11:20
Оценка: :)
C>[skipped]

C>Ты знаком с понятием "медвежья услуга"?


Услуга, оказываемая д'Артаньяном, медвежьей не может быть по определению


dmitriid.comGitHubLinkedIn
Re[8]: И снова про ц++
От: okman Беларусь https://searchinform.ru/
Дата: 05.02.12 12:11
Оценка: +1
Здравствуйте, Young, Вы писали:

Y>...нелюбовь от того, что при разработке на ц++ — и особенно при поддеживании чужого кода мы будем скорее решать технические проблемы связананные с выстрелами по памяти, порчей стека и т.п. — чем логические. А хочеться технические проблемы не решать и забыть о них.

Y>И мне ей богу странно что с этим спорят. Что прет решать технические проблемы???

Инструмент не может быть проще предметной области, задачи которой он призван решать.
Если вы пишете системный софт, работаете с виртуализацией, прерываниями, вводом-выводом на
низком уровне, технические вопросы и технические проблемы будут окружать вас постоянно.
Они, так сказать, будут являться частью нормального рабочего окружения.
Попробуйте поставить какой-нибудь хук в kernel-mode, не зная про доступ к памяти или
calling convention — тут же отхватите BSOD (Blue Screen Of Death — синий экран смерти).

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

Y>Бывает, да. Только зачем вам в случае микропроцессоров ц++? Чем вам ц99 не хватает то — если вы боритесь за производительность?


Мне лично в C очень не хватает RAII (жить не могу) и какой-нибудь простенькой библиотеки
контейнеров по образцу vector/map/set/list. Без остального можно обходиться, в принципе.

Y>Да елки-палки. Что значит не платишь — платишь, платишь потом сложными багами в чужих проектах, та же случайная, раз в месяц работы программы стрельба по памяти, приводящая не к крашу, а изменению данных.


Почему Вы отрицаете тот факт, что корректность функции нельзя доказать другими средствами,
нежели чисто языковыми (к примеру, набором юнит-тестов) ? Я о том, что когда такая гарантия
корректности есть, необходимость в накладных расходах, вызванных всякими проверками доступа к
памяти, стеку или выхода за границы массива, отпадает.

C++ позволяет отключать такие проверки, и это играет важную роль там, где производительность критична.
Поэтому в некоторых случаях выгоднее не платить за то, что не используется.
Re[12]: И снова про ц++
От: Cadet  
Дата: 06.02.12 04:41
Оценка: +1
Здравствуйте, Sheridan, Вы писали:

S>Я это называю ленью.


Ты не участвовал ни в больших проектах, ни в командной разработке, посему можешь как угодно называть. Но со временем такая беготня начинает отнимать слишком много времени.
... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
Re[15]: И снова про ц++
От: Cadet  
Дата: 06.02.12 05:18
Оценка: :)
Здравствуйте, enji, Вы писали:

C>>Да-да. Ты еще найди такую пасхалку в большом проекте. Она к примеру может хитро использоваться совместно с макросом __DATE__, и стрельнуть примерно через полгода после коммита.


E>Вы серьезно обсуждаете, что минус С++ — в том, что кто-то может написать #define true false? И скомбинировать это с макросом DATE?

E>Что мешает мне написать какую-нить пакость в обычном коде на яве/питоне/шарпе, без использования препроцессора? И скомбинировать это с DateTime.Now или rand?

Ну напиши что ли, а потом обсудим, что сложнее поймать будет.
... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
Re[10]: И снова про ц++
От: Sheridan Россия  
Дата: 06.02.12 08:34
Оценка: :)
Здравствуйте, Privalov, Вы писали:

S>>Еще раз: эту обертку делает IDE.

P>Ты совсем недавно утверждал, что IDE не нужны. Что-то с тех пор изменилось?
Мне — не нужны как правило. Но так то — мне. А рассказываю я то — вам.
Matrix has you...
Re[9]: И снова про ц++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 06.02.12 09:28
Оценка: :)
Здравствуйте, okman, Вы писали:

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


I>>Попроси что бы ктото убил тебя. Понавыбираете а потом интеграция превращается в переписывание.


O>Бедненький.

O>Как же тебе тяжело с нами.

Это вам тяжело, потому что нам приходится изыскивать время что бы помогать вам с вашими проектами.
Re[12]: И снова про ц++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 06.02.12 09:40
Оценка: +1
Здравствуйте, Sheridan, Вы писали:

___>>Ты реально похож на пингвина в подписи. Нечитаемо, это когда инклуды. И надо бегать по коду туда сюда.

S>Я это называю ленью.

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

Ты похоже продолжаешь рассказвать про прелести разработки в одиночку. Спасибо, кушай сам.
Re[3]: Подытожим?
От: Ops Россия  
Дата: 06.02.12 12:04
Оценка: +1
Здравствуйте, neFormal, Вы писали:

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


S>>Чтож, печально все. Основным минусом плюсов, как выясняется, является его мощность и универсальность.


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

При хорошей начальной архитектуре сложность неособо-то и растет. А если архитектура гавно, то ее никакой язык не спасет.

F>почему ты не назвал более тривиальных и полезных вещей вроде автоматического тестирования?

Я что-то не заметил в топике ни одного поста про это.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[5]: namespace'ы в классах
От: Sinclair Россия https://github.com/evilguest/
Дата: 06.02.12 14:21
Оценка: +1
Здравствуйте, Sheridan, Вы писали:

S>>В качестве упражнения — годится. В продакшн — вряд ли: слишком многословно и чревато ошибками.

S>Ох да какже вы все дефайнов боитесь... о0
При чём тут дефайны? Речь о том, что есть куча полунеявных соглашений, вроде явной передачи имени родительского класса в макрос — несмотря на то, что класс должен быть понятен из контекста. Все такие вещи чреваты боком при будущем рефакторинге — например, когда я захочу перетащить часть методов из предка в наследника, я могу запросто упустить переименование и получать всякие забавные результаты.

S>>Доступ к полям "объёмлющего" класса не вполне удобен, как и вызовы в "соседние" неймспейсы.

S>Абсолютно согласен.
Ещё будут занятные сложности в тот момент, когда я захочу перегрузить виртуальный метод из "неймспейса" в классе-наследнике. Или хотя бы добавить ещё один метод в такой "неймспейс".

Я же говорю — эта штука хороша в качестве упражнения, показать, что можно и правой ногой левое ухо чесать.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[13]: namespace'ы в классах
От: Mamut Швеция http://dmitriid.com
Дата: 06.02.12 15:41
Оценка: -1
S>>>>>К тому, что в сторону ц++ высказываются в похожем стиле.
M>>>>Ну, если ты неспособен понять, что тебе пишут, то да, конечно, именно так и высказываются

S>>>До сих пор никто не смог повторить на других языках реализацию нэймспейсов в классах. Да, конечно, мне не понять, ага.


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


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


Это гениально. Ничего, что изначально вопрос был совсем про другое — это раз. И что вообще я говорил Шеридану про другое — это два


dmitriid.comGitHubLinkedIn
Re[9]: namespace'ы в классах
От: Ночной Смотрящий Россия  
Дата: 06.02.12 17:54
Оценка: :)
Здравствуйте, Sheridan, Вы писали:

S>Не искажай. Я сам ушел оттуда по причинам ухода из виндов в линукса.


Другие участники почему то говорят иное. И всю твою химию со string.Format из исходников тщательно выпилили. Можно было бы, конечно, списать на глупых разработчиков янусовых, но ведь в Авалоне все повторилось с точностью до деталей. А это уже тенденция — ты абсолютно бесполезен как программист.
Re[24]: ЗЫ
От: Mamut Швеция http://dmitriid.com
Дата: 06.02.12 20:24
Оценка: +1
В свете этого: http://rsdn.ru/forum/flame.comp/4606579.aspx
Автор: hattab
Дата: 07.02.12
понятно, что говорим о разном


dmitriid.comGitHubLinkedIn
Re[14]: namespace'ы в классах
От: Sheridan Россия  
Дата: 06.02.12 20:55
Оценка: -1
Здравствуйте, Privalov, Вы писали:

N>>Такого рода отношение к проекту, в котором участвуешь, неприемлемо как для меня, независимо от того, он платный, бесплатный, открытый, или какой-то ещё.

P>Целая толпа народу пытается объяснить это мсье д'Артаньяну черт знает сколько времени.
А Дарт Аньян все никак не может донести толпе, что работать в сторону интереса намного продуктивнее, нежели работать в сторону необходимости. Например, сравни сколько жил авалон в мусорке и за сколько я его привел в порядок и добавил в туда несколько вкусных возможностей, а также намного улучшил его внешний вид. И сравни сколько изменилось после того как код мой убрали.
Matrix has you...
Re[16]: И снова про ц++
От: okman Беларусь https://searchinform.ru/
Дата: 07.02.12 06:40
Оценка: +1
Здравствуйте, Mamut.

Ты обвинил C++ в отсутствии нормальных строк. Я спросил о критериях нормальности — ответом мне
было "отсутствие поддержки UTF-8", что, как выяснилось, не соответствует действительности (см. выше).
Далее пошли наезды на "велосипедность" и несовместимость реализаций, в какой-то степени справедливые.
На что я возразил в духе: "зато для конкретной задачи можно выбрать наиболее подходящую реализацию, а
не обходиться одной везде и всюду".

На этом объективные аргументы закончились: "я описываю реальность", "в подавляющем большинстве
случаев", "там нету" и т.д. Знаешь, дискуссия интересна, когда обе стороны выдвигают в защиту своих
тезисов конкретные доводы, а не просто утверждают: "этого нет" или "дадада".

Некоторые люди разницу между std::string и CString из MFC очень хорошо ощущают и умеют использовать, а
то, что для кого-то все эти строки на одно лицо, еще ничего не значит.
Re[17]: Прошу прощения...
От: Privalov  
Дата: 07.02.12 06:49
Оценка: +1
Здравствуйте, Sheridan, Вы писали:

S>Причину со следствием пожалуйста не путай. Обвиняя тебя, я не врал, так как считал что пишу ответ Мамуту. И сразу извинился после твоего ответа, так как раньше не заметил. Если бы заметил — просто удалил бы сообщение совсем.


Тебе надо чуть меньше торопиться и чуть больше думать, тогда тебе не придется сочинять такие отмазки. Таких отмазок мои дети уже давным-давно не приносят.
Re[15]: Подытожим?
От: Sheridan Россия  
Дата: 07.02.12 11:24
Оценка: -1
Здравствуйте, Mamut, Вы писали:

S>>Ты не сказал сколько по твоему мнению дартаньянов писало тот код.

M>Как этот вопрос соотносится с той, которую ты оставил из моего сообщения? И вообще со всем моим предыдущим сообщением?
Я к тому, что если вокруг сплошные Дарт Аньяны, то может наоборот?
Matrix has you...
Re[3]: И снова про ц++
От: ДимДимыч Украина http://klug.org.ua
Дата: 08.02.12 12:23
Оценка: +1
Здравствуйте, Sheridan, Вы писали:

ДД>>Встречный вопрос: почему ты скрипты автоматизации не на C/C++ пишешь? Ведь bash, а впрочем и остальные shell-интерпретаторы такие тормознутые по сравнению с нативным кодом.

S>Иногда пишу, а что?

Почему иногда, а не всегда? Что застваляет в остальных случаях использовать bash? Лень?
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
Re[19]: Прошу прощения...
От: Privalov  
Дата: 08.02.12 20:51
Оценка: +1
Здравствуйте, jazzer, Вы писали:

P>>Тебе надо чуть меньше торопиться и чуть больше думать


J>Он уже признал, что был неправ, и извинился. Чего тебе еще надо


Я попросил Sheridan-а чуть меньше торопиться и чуть больше думать. В этом случае с ним вполне можно вести нормальный диалог. Проверено на себе. Мне, человеку мирному, хотелось бы общаться с ним в таком вот ключе. Вот и все. Он же сам разрешил мне дать ему подзатыльник. Я воспользовался.
Re[15]: И снова про ц++
От: jazzer Россия Skype: enerjazzer
Дата: 09.02.12 09:57
Оценка: +1
Здравствуйте, Sheridan, Вы писали:

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


S>Да ладно? Ты действительно не понимаешь, что "Если мне интересно — буду писать как хочу" работает до тех пор, пока "мне за код не платят деньги"?

Да все понятно, чего тут непонятного.
Вроде никто не запрещает тебе писать, как ты хочешь.
Но ты, в свою очередь, должен понимать, что команда имеет такое же право не принимать твоих изменений, если они ей не нравятся.
Ну и вы оба активно пользуетесь своими правами — ты пишешь как хочешь, они не принимают — вроде, все должны быть довольны, не?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[22]: И снова про ц++
От: Banned by IT  
Дата: 09.02.12 14:34
Оценка: +1
Здравствуйте, enji, Вы писали:

E>На самом деле, даже если бы твоя идея сработала, нет совершенно никаких проблем найти такую закладку.


Да первая же VAX подсказка на необычно расцвеченом true или false приведёт к макросу. Ещё до срабатывания.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[37]: И снова про ц++
От: ambel-vlad Беларусь  
Дата: 09.02.12 15:35
Оценка: +1
Здравствуйте, Cadet, Вы писали:

AV>>Угу. Одна закладка проявляется в 99% времени работы программы, а другая в 0.01%. Какую быстрее обнаружат?


C>Ты правда rand() в моем примере здесь
Автор: Cadet
Дата: 07.02.12
не заметил, или даже не смотрел? Вероятность можно и сильно ниже поставить.


заметил. Думаешь этот rand принципиально меняет картину?

C>>>Кстати вполне можно бомбить не такую распространенную вещь как true/false, а точно так же как и в твоем примере тихой сапой подменить через дефайн класс. Или функцию. Тут сишный препроцессор практически неограничен, что хошь то и вороти.


AV>>А никто и не говорил, что такое с плюсах невозможно. В отличии от обратного утверждения.


C>Что возвращает нас к моему утверждению про бомбу схожей мощности и т.д. в НЕ с/с++. На сишном препроцессоре можно сделать все что можно в шарповом, и еще дополнительно кучу всего.


Можно. В других языках можно другие бомбы сделать. И что из того? С/С++ в этом вопросе не есть что-то уникальное.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[17]: namespace'ы в классах
От: Ночной Смотрящий Россия  
Дата: 10.02.12 20:34
Оценка: +1
Здравствуйте, Sheridan, Вы писали:

НС>>Да ты в этом топике его сам привел. И другие приводили. Из януса, к примеру — это ж пестня.


S>Что тебе в коде непонятно?


Самое главное — нафига этот изврат вообще.
Re[25]: namespace'ы в классах
От: Cadet  
Дата: 11.02.12 21:48
Оценка: +1
Здравствуйте, Sheridan, Вы писали:

S>И да, я всетаки не шарпей, чтобы знать тонкости этого самого шарпа... Впрочем да, мог и догадаться...


Ну давай я твои высказывания применю к тебе же: обленились админы! Вырождаются! Банально синтаксиса языков не знают! Это же даже не библиотека, надо знать инструмент который используешь! Как ты можешь эффективно админить не зная такой ерунды? Включить мозг и подумать уже сил нету! Пилу точить некогда надо пилить!
... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
Re[25]: namespace'ы в классах
От: Cadet  
Дата: 11.02.12 22:13
Оценка: +1
Здравствуйте, Sheridan, Вы писали:

S>Ок. Я написал излишне объемный код вместо компактного. Можно я отрежу себе ухо?


Странное желание, но валяй раз хочешь .

S>Но у меня появляются два вопроса:

S>1. Почему этот код не переписал сам АВК, а предпочел спихнуть это на меня?

Не знаю о чем думал АВК, но я бы аргументировал это тем что говно твое — убирать тебе.

S>2. Почему эту мелочь вспоминают до сих пор, по истечении шести(?) лет?


Да потому что более свежий пример с Авалоном показал что лучше не стало. Да и последние твои куски кода то же самое демонстрируют (хотя бы вспомнить явные new/delete в пределах функции и "мне так больше нравится" ). Какая разница что вспоминать — у тебя прогресса с т.з качества кода нет. Он как был неустойчив к ошибкам и модификациям, так и остался
... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
Re[25]: namespace'ы в классах
От: Ночной Смотрящий Россия  
Дата: 11.02.12 23:46
Оценка: +1
Здравствуйте, Sheridan, Вы писали:

S>1. Почему этот код не переписал сам АВК, а предпочел спихнуть это на меня?


Это как то тебя извиняет?

S>2. Почему эту мелочь вспоминают до сих пор, по истечении шести(?) лет?


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

S>Предполагаю ответы 1: лень.


Судя по этому, вовсе нет.

S> 2: больше ничего не нашли.


Скорее не искали, а просто грохнули все твое гавно и переписали по нормальному.
Re[30]: Стоп
От: Sheridan Россия  
Дата: 12.02.12 11:57
Оценка: :)
Здравствуйте, Mamut, Вы писали:

M>>>Почему тебе можно, а нам — нельзя?

S>>Это где я так делал?

M>Везде, где выдаешь свои фантазии за абсолютную истину.


Я не манипулирую фактами в отличии от.
Matrix has you...
Re[44]: И после препроцессора, кстати...
От: hattab  
Дата: 12.02.12 14:44
Оценка: :)
Здравствуйте, Erop, Вы писали:

E> H>Вот жеж народ... Шеридан дважды уж написал, что это не корысти ради, а токмо волею пославшей мя жены не практическая задача, а так, разминка, нет упорно продолжают говорить об IDE (напоминаю: была претензия к языку, Шеридан хочет решение средствами языка. Кроме того, я сомневаюсь, что кто-то предложит решение подходящее для всех существующих IDE).


E> Шеридан да одну формулировку, ты процитировал другую. Та, которую ты процитировал -- претензия чисто к IDE...


Я цитировал с чего весь разговор начался, если ты не понял. Это была претензия к языку т.к. оно должно бы работать вне зависимости от IDE.

E> H>Само именование в таком стиле негодное, из соображений сохранения стиля, положим.


E> Не понимаю. Вот положим я придумаю как назвать метоы в стие namespace::method, то чем это будет принципиально отличаться от namespace_method?


Наличием иерархии. Впрочем, я тебя убеждать не собираюсь. Нет ответа ну и ладно.
avalon 1.0rc3 build 428, zlib 1.2.3
Re[32]: И после препроцессора, кстати...
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.02.12 16:14
Оценка: :)
Здравствуйте, Sheridan, Вы писали:

FR>>Как разминка для мозгов вполне, как код в реальном проекте, к тому же на C++ а не Си, нафиг.

FR>>Поддерживать как раз будет проще без дефайнов. Вот представь какой-то нехороший человек нагородил раз в десять
FR>>больше и сложнее чем у тебя макросов, ты в первый раз жизни видишь этот код, тебе практически приходится изучить
FR>>тот DSL который он наваял и который наверняка глобален для проекта. При этом тебе обычно надо сделать небольшое
FR>>локальное исправление, а ошибка в макросе, самое веселое это когда в половине мест использования этого макроса
FR>>надо править ошибку а в половине код уже завязан на эту багофичу. И вместо правки небольшого локального участка
FR>>у тебя гемморой.

S>Не до конца понятно — при чем тут маакросы вообще? Можно и на багофичу-неверный результат метода полпроекта завязать, и на долгое удаелние объекта надеяться например. И будут ровно такие же проблемы.


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

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

S>Никак не могу понять чем для тебя макрос отличается например от метода, ежели писан не тобой и в документации описано как и где его применять.

У макросов больше потениальных проблем.
Re[9]: И снова про ц++
От: Ночной Смотрящий Россия  
Дата: 12.02.12 22:13
Оценка: +1
Здравствуйте, vdimas, Вы писали:

V>Это было задолго до Явы, но и в Яве как анонимные классы, так и локальные весьма популярны


На безрыбье ака отсутствие лямбд и замыканий ...

V>Да, решают ту же задачу, что и ФП-замыкания, только в ООП-стиле.


Верно. Но только вот нормальные лямбды и замыкания выглядят намного лучше и понятние, хоть и не тру ООП.
Re[8]: namespace'ы в классах
От: vdimas Россия  
Дата: 13.02.12 04:48
Оценка: :)
Здравствуйте, landerhigh, Вы писали:

L>>>Какой хороший наброс! Долго сочинял?


V>>Да ты тоже как бы набросил перед этим... как-то по-детски, что-ле, отдает максимализмом и неопытностью.


L>Я набросил? Я опытом поделился — у нас подобное, эээ, графоманство, встреченное во время код ревью, есть повод к его немедленному прекращению без дальнейших разговоров, ибо время всех членов команды стоит дорого. Вот теперь можешь обвинять нас в максимализме и неопытности, но смотри, как бы впросак не попасть.


Дык, где тут попасть-то в твоей незамутненности-то. Ты уже сдал себя с потрохами — вы клепаете сугубо заказные продукты, а не на рынок. Насчет "дорого время команды чтобы заточить пилу, пилить надо" — это истина только в заказных вещах, иначе это не истина, а идиотизм и убытки из-за потерь рынка. Но вам нечего терять. У вас не рынок, а клиенты.


V>>Очень похоже на аналог действия Саттера & Co на неокрепший ум буквально первые пару-тройку лет после прочтения... Так что получил заслуженно в ответ.


L>Что? Получил в ответ? Где? Не вижу!


Ну не видь, делов-то... судя по безапелляционности тона, ты много еще чего не видел.


V>> Иногда дается задача и диктуется инструмент под нее (много чем может диктоваться). И вот видишь, что инструмент задаче не канает, а делать нефиг — закатываешь рукава и пашешь. А такие как ты канитель разводят, да об "идеальном коде" рассуждают.


L>Вот додумывание за собеседника плюс переход на личности и есть как раз признак юношеского максимализма и неопытности.


В ответ разрешается. Хоть посмотришь со стороны, каково эти перлы читать.


L>Прощайте, молодой человек, можете даже не беспокоиться с ответом.


Я уж сам разберусь, сорри, беспокоиться мне или нет.
Re[23]: И снова про ц++
От: Mamut Швеция http://dmitriid.com
Дата: 13.02.12 10:35
Оценка: -1
E>>На самом деле, даже если бы твоя идея сработала, нет совершенно никаких проблем найти такую закладку.

BBI>Да первая же VAX подсказка на необычно расцвеченом true или false приведёт к макросу. Ещё до срабатывания.


Ложь и фантазии в любом случае ложь и фантазии


dmitriid.comGitHubLinkedIn
Re[6]: namespace'ы в классах
От: Sheridan Россия  
Дата: 13.02.12 22:12
Оценка: :)
Здравствуйте, Privalov, Вы писали:

P>А прикинь, как математики измельчали. Не хотят почему-то использовать римские цифры при записи чисел. Перешли на позиционные системы счисления. И теперь любой школьник выполняет арифметические действия без особых проблем. Не хотят разбираться в римских цифрах, считают их источником ошибок и тратой времени.

Ой передергиваешь. Римские цифры от арабских отличаются только при письме. Считать надо ровно также уметь. И если математика попросить римскими цифрами писать — он недельку привыкать будет, а потом обратно в колею войдет.
А вот ежели шарпея например или там заводчиков земноводных вдруг за ц++ посадить — ВНЕЗАПНО окажется что ой. Не хватает в головах и надо доучиваться.

S>>Плохо. Очень плохо.

S>>Я очень надеюсь что производительность компов упрется в потолок и наконецто придется писать нормальный софт, не надеясь на мощность компьютеров.
P>Следует ли это понимать так, что ты хочешь ввести для разработчиков условия, о которых как-то писал Pavel Dvorkin: Вот если бы было введено ограничение по количеству переменных в программе (вот тебе 100 на программу и крутись как хочешь

Я честно попытался представить себе ход твоих мыслей, которые привели тебя к этому умозаключению, но тщетно. Поведаешь как ты додумался до такого что я буду подобный бред разделять?

Так ограничивать программиста не просто глупо, а граничит с шизофренией. Максимум ограничить языком (основным и вспомогательными) и библиотеками. Но не более.
Matrix has you...
Re[3]: И снова про ц++
От: _d_m_  
Дата: 17.02.12 02:10
Оценка: :)
Здравствуйте, Dair, Вы писали:

XC>>Ужасная система #include и препроцессора, отсутствие нормальной модульной системы

D>А чем ужасна система #include?
D>Что такое "модульная система"? Я компоную исходники по модулям так, как мне захочется. Компилирую их отдельно в библиотеки. Также делают и поставщики библиотек. Это не модульность?
...
XC>>соответственно невозможность сделать break и continue на именованный блок/из блока
D>Нипонел. break/continue делается на текущий цикл. Вы хотите чтобы break/continue выходил сразу из более чем одного цикла?
...
XC>>Отсутствие методов-расширений, отсутствие возможности обращаться к методу класса как к статическому с явной (ручной) передачей this
D>"Методы-расширения" — это что?
D>Зачем надо обращаться к не-статическому?
...
XC>>Отсутствие системы сообщений как в ObjectiveC, встроенной системы сигналов и слотов как в QT
D>То, что вы называете системой сообщений в ObjC — это про
[obj performSelector:@selector(mySelector)]
?

...
XC>>Невозможность создания namespace внутри класса (вспомните хотя-бы "главные оконные классы" разных библиотек — CWnd, QWidget... сотни методов, там разделение не помешало бы)
D>Примите за правило не делать более N методов в классе. Получается больше — рефакторинг.
...
XC>>Отсутсвие вложенных функций (даже в турбо паскале вроде были), а лямбды в C++11 на редкость кривые
D>С лямбдами не знаком вообще, а отсутствие вложенных функций — сомнительное неудобство. Какая разница? Объявил статической и ладно.
...
XC>>Отсутствие замыканий, простого объявления функциональных типов (int=>int)
D>Что это и зачем это надо?
...
XC>>Отсутствие кортежей, групповых операций над кортежами, невозможность вернуть из функции несколько значений напрямую
D>Что это и зачем это надо?
...
XC>>Отсутствие опциональной возможности структуной типизации
D>Что это и зачем это надо?
...
XC>>При этом отсутствие полноценной системы метапрограммирования (типа как в Nemerle, хотя я бы сделал еще лучше)
XC>>Отсутствие полноценной рефлексии и атрибутов (как в C#)
XC>>Отсутствие встроенной параллельности и каналов (как в Go)
XC>>Отсутствие свойств (properties) как в C# (хотя и в C# можно еще кое-что улучшить)

D>Про это я вообще не в курсе, так что вообще ничего не скажу.

...

Мда... Ппц, нет слов. А зачем это сообщение вообще? Ты словно из лесу вышел и был там лет 20.
Re: И снова про ц++
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.02.12 05:11
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++? Указатели? Да фигня это, на пару граблей наступить и рефлекс появится. Зато более шустрый софт получается.

S>Так все же?

Шеридан, а ты какого размера проект на С++ делал?

А то какой-то разговор о вкусе устриц с тем кто их не пробовал получается.
Re[2]: И снова про ц++
От: Sheridan Россия  
Дата: 03.02.12 05:19
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Шеридан, а ты какого размера проект на С++ делал?


Больше размер проекта — сложнее ловить баги, согласен. И чем больше — тем сложнее.
При чем тут ц++?
Matrix has you...
Re[3]: И снова про ц++
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.02.12 05:33
Оценка:
Здравствуйте, Sheridan, Вы писали:

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


G>>Шеридан, а ты какого размера проект на С++ делал?


S>Больше размер проекта — сложнее ловить баги, согласен. И чем больше — тем сложнее.

S>При чем тут ц++?

Действительно не при чем. Вопрос должен быть такой: какого размера проекты ты делал на С++ и не не-С++ чтобы сам мог понять разницу?
Re: И снова про ц++
От: Alex912  
Дата: 03.02.12 06:23
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++? Указатели? Да фигня это, на пару граблей наступить и рефлекс появится. Зато более шустрый софт получается.

S>Так все же?

Нет.
Re: И снова про ц++
От: Философ Ад http://vk.com/id10256428
Дата: 03.02.12 06:26
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++? Указатели? Да фигня это, на пару граблей наступить и рефлекс появится. Зато более шустрый софт получается.

S>Так все же?

да
Всё сказанное выше — личное мнение, если не указано обратное.
Re: И снова про ц++
От: jazzer Россия Skype: enerjazzer
Дата: 03.02.12 06:38
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++? Указатели? Да фигня это, на пару граблей наступить и рефлекс появится. Зато более шустрый софт получается.

S>Так все же?

А тебе зачем?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[3]: И снова про ц++
От: x-code  
Дата: 03.02.12 07:14
Оценка:
Здравствуйте, jazzer, Вы писали:

XC>>Да еще много чего, сразу все и не вспомнить...

J>Давай подскажу: отсутствие монад как в Хаскеле, отсутствие зависимых типов как в Агда-2, отсутствие eval как в Перле, отсутствие значимых отступов как в Питоне... ну и далее по списку

Нет, значимые отступы как в Питоне я не хочу. Как не хочу и жесткий стиль расстановки фигурных скобок, как в Go и Rust (когда открывающая фигурная скобка обязана быть на той же строке что и оператор)
С зависимыми типами и монадами еще не разобрался, как разберусь — решу надо или нет Может подскажешь — что могут дать монады в императивном языке программирования типа С++ или C# ?
eval сделать на компилируемом языке невозможно, но надо подумать о максимально бесшовной интеграции языков типа javascript — в смысле, что для этого нужно ввести в компилируемый язык. Возможно, синтаксис языковых вставок с возможностью подключения верификаторов (ну типа "asm", но для любого скриптового языка, подключенного неким способом в проект).
Re[4]: И снова про ц++
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.02.12 07:17
Оценка:
Здравствуйте, jazzer, Вы писали:

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


N>>В принципе согласен. Более того, система namespace неудобна.

N>>Постоянно хочется решений в стиле питоновского import X.Y.Z as W.
J>чем не устраивает
J>
J>namespace W = X::Y::Z;
J>

J>

Это давно появилось? Я такого ещё не видел. Оно действует на полные символы или только на пространства?
The God is real, unless declared integer.
Re[2]: И снова про ц++
От: blackhearted Украина  
Дата: 03.02.12 07:29
Оценка:
Здравствуйте, denisko, Вы писали:

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


S>>Зато более шустрый софт получается.

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

C жабой, уоторая в болоте тонет.
Re: И снова про ц++
От: Andrey.V.Lobanov  
Дата: 03.02.12 07:38
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++?

слабая маркетинговая составляющая

S>Зато более шустрый софт получается.

запасаемся попкорном или линейками...
Re: И снова про ц++
От: Mamut Швеция http://dmitriid.com
Дата: 03.02.12 08:15
Оценка:
S>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++? Указатели? Да фигня это, на пару граблей наступить и рефлекс появится. Зато более шустрый софт получается.

И при этом ты поносишь браузеры и IDE, которые на этом самом С++ написаны. Нуну.

*Ушел за колой и попкорном в ожидании ответа хотя бы на это
Автор: gandjustas
Дата: 03.02.12
*

А так: C++ можно не любить хотя бы за отсутсвие вменяемых строк. Хотя твой мозг отказывается понимать, что строки — это не последовательность char'ов, это так.


dmitriid.comGitHubLinkedIn
Re[5]: И снова про ц++
От: Философ Ад http://vk.com/id10256428
Дата: 03.02.12 08:21
Оценка:
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, Философ, Вы писали:
Ф>Здравствуйте, LaptevVV, Вы писали:

LVV>>>ИМХО для С это было самое то! Но для С++, который позиционируется как язык более высокого уровня


N>А что такое Ваше "язык более высокого уровня", известно только Вам. Насколько более высокого? На миллиметр, километр, 3 слоя или ровно на одну морковку?


адресатом ошибся
Всё сказанное выше — личное мнение, если не указано обратное.
Re[6]: И снова про ц++
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.02.12 08:23
Оценка:
Здравствуйте, jazzer, Вы писали:

N>>>>В принципе согласен. Более того, система namespace неудобна.

N>>>>Постоянно хочется решений в стиле питоновского import X.Y.Z as W.
J>>>чем не устраивает
J>>>
J>>>namespace W = X::Y::Z;
J>>>

J>>>
N>>Это давно появилось? Я такого ещё не видел.
J>Всегда было, см. 7.3.2 [namespace.alias] в С++98.

Что "всегда", не согласен, в первых версиях не было, а потом я с C++ настолько плотно не общался. Но идея ясна. И это не совсем то, что надо, хотя тоже помогает.

N>>Оно действует на полные символы или только на пространства?

J>Я не очень понял, в чем вопрос.

Это алиасы только для пространств. А я хотел для одного имени.
Чтобы, например, я мог функцию X::Y::Z::W назвать как ZW и вызывать её по этому имени.
Это крайне полезно для ситуаций, когда удобно принять 2 разных пространства имён в основне пространство, чтобы не требовалось их уточнять на каждом шагу, но при этом одно из имён там конфликтует (есть в обоих). Тогда только оно алиасится, а остальные применяются напрямую.
Через алиас для пространства это немного удобнее, но не до конца.
Или есть случаи, когда имя в пространстве само по себе безумно длинное, а удобно назвать его короче, или просто переименовать в пределах данного модуля в соответствии с более подходящим смыслом. Такое данным методом вообще не решается.
The God is real, unless declared integer.
Re[3]: И снова про ц++
От: x-code  
Дата: 03.02.12 08:36
Оценка:
Здравствуйте, LaptevVV, Вы писали:

XC>>Отсутствие вложенных блочных комментариев

LVV>Это мелочь
Из мелочей состоит все. И красота языка программирования именно в мелочах. Я кстати придумал третий совершенно новый и очень удобный вид комментариев (кроме блочных и однострочных).

XC>>Имя массива является адресом первого элемента массива (нелогично! со структурами же не так)

LVV>ИМХО для С это было самое то! Но для С++, который позиционируется как язык более высокого уровня, — это анахронизм.
XC>>Отсутствие низкоуровневых возможностей: sizeof( ) от функции и блока кода, goto на переменные метки (в gcc есть, но это нестандартно)
LVV>Зачем?
Для различных хакерских целей возможно и понадобится. Или для целей защиты программ от взлома.

XC>>Невозможность передачи массивов в фигурных скобках "как есть" в функции Foo({1,2,3});

LVV>Если бы массивы были полноценные объекты — это было бы самое то!
Все должно быть полноценными объектами, и числа, и строки. То есть должны быть вызовы вида 10.ToStr(), "Hello".ToUpper(), но при этом эти "объекты" должны оставаться простыми сущностями.

XC>>Отсутствие именованных блоков кода, соответственно невозможность сделать break и continue на именованный блок/из блока

LVV>Это мелочь. Особенно ghyb наличии goto/ Если goto убрать, то да.
goto тоже нужно оставить, это уникальный оператор безусловного перехода, и в некоторых особых случаях заменой ему могут быть только ассемблерные вставки. Уберем — и получим очередную джаву, на которой ничего кроме бизнес-бухгалтерии и не напишешь.

XC>>Отсутствие методов-расширений, отсутствие возможности обращаться к методу класса как к статическому с явной (ручной) передачей this

LVV>Сильно напрягает?
Если возможность может быть, она ДОЛЖНА быть.

XC>>Отсутствие системы сообщений как в ObjectiveC, встроенной системы сигналов и слотов как в QT

LVV>А где такое еще есть?
Ну вот в ObjC и QT есть.

XC>>Невозможность создания namespace внутри класса (вспомните хотя-бы "главные оконные классы" разных библиотек — CWnd, QWidget... сотни методов, там разделение не помешало бы)

LVV>ИМХО сотни методов — это проблема реализации. И следствие отсутствия нормальной модульности.

Да пусть у меня всего 4 метода в классе, но я хочу разделить их в две группы, что не имею права?

XC>>Отсутсвие вложенных функций (даже в турбо паскале вроде были), а лямбды в C++11 на редкость кривые

LVV>
XC>>Отсутствие замыканий, простого объявления функциональных типов (int=>int)
LVV>А надо?

Код должен быть простым. Если я хочу объявить аргумент "функцию, принимающую на вход int и возвращающую int", я хочу сделать это максимально простым и естественным способом: "int=>inf f" и передавать туда что угодно — метод класса, глобальную функцию, лямбду, функтор с перегруженным operator() и т.д. Это должно работать без шаблонов, если я хочу без шаблонов.

XC>>Отсутствие кортежей, групповых операций над кортежами, невозможность вернуть из функции несколько значений напрямую

LVV>Напрямую — это как?
После многих вариантов я остановился на таком варианте синтаксиса функций, ИМХО самый оптимальный из всех возможных:
def Func(int a, b, c) int x, y
{
  x = a*b + c;
  y = a/b - c;
}
// ну и вызов, какие-то две переменные объявленные где-то, объединяем их в кортеж и принимаем результат функции
(i, j) = Func(100,200,300);
Re[2]: И снова про ц++
От: Sheridan Россия  
Дата: 03.02.12 08:36
Оценка:
Здравствуйте, Mamut, Вы писали:

S>>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++? Указатели? Да фигня это, на пару граблей наступить и рефлекс появится. Зато более шустрый софт получается.


M>И при этом ты поносишь браузеры и IDE, которые на этом самом С++ написаны. Нуну.

Гм, напомни ка...

M>А так: C++ можно не любить хотя бы за отсутсвие вменяемых строк. Хотя твой мозг отказывается понимать, что строки — это не последовательность char'ов, это так.

std::string чем невменяемо?
Matrix has you...
Re[2]: И снова про ц++
От: Sheridan Россия  
Дата: 03.02.12 08:36
Оценка:
Здравствуйте, Andrey.V.Lobanov, Вы писали:

S>>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++?

AVL>слабая маркетинговая составляющая
Каким боком маркетинг относится к языку программирования?
Matrix has you...
Re[2]: И снова про ц++
От: Sheridan Россия  
Дата: 03.02.12 08:37
Оценка:
Здравствуйте, jazzer, Вы писали:

J>А тебе зачем?

Риторический вопрос
Matrix has you...
Re[2]: И снова про ц++
От: Sheridan Россия  
Дата: 03.02.12 08:38
Оценка:
Здравствуйте, denisko, Вы писали:

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


S>>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++?

D>учи дальше плюсы.
Чем дальше вникаю тем больше нравится.

S>>Указатели? Да фигня это, на пару граблей наступить и рефлекс появится.

D>Это к плюсам вообще не имеет отношения.
Абсолютно верно, это имеет отношение ко всему вообще. И к ц++ в частности.

S>>Зато более шустрый софт получается.

D>По сравнению с чем?
Ну например по сравнению с земноводными.
Matrix has you...
Re[7]: И снова про ц++
От: jazzer Россия Skype: enerjazzer
Дата: 03.02.12 08:41
Оценка:
Здравствуйте, netch80, Вы писали:

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


N>>>>>В принципе согласен. Более того, система namespace неудобна.

N>>>>>Постоянно хочется решений в стиле питоновского import X.Y.Z as W.
J>>>>чем не устраивает
J>>>>
J>>>>namespace W = X::Y::Z;
J>>>>

J>>>>
N>>>Это давно появилось? Я такого ещё не видел.
J>>Всегда было, см. 7.3.2 [namespace.alias] в С++98.

N>Что "всегда", не согласен, в первых версиях не было, а потом я с C++ настолько плотно не общался. Но идея ясна. И это не совсем то, что надо, хотя тоже помогает.

В каких таких "первых" версиях? Cfront?
В стандарте 98-го года это было, а в достандартном ARM пространств имен не было вообще

N>>>Оно действует на полные символы или только на пространства?

J>>Я не очень понял, в чем вопрос.

N>Это алиасы только для пространств. А я хотел для одного имени.

N>Чтобы, например, я мог функцию X::Y::Z::W назвать как ZW и вызывать её по этому имени.
N>Это крайне полезно для ситуаций, когда удобно принять 2 разных пространства имён в основне пространство, чтобы не требовалось их уточнять на каждом шагу, но при этом одно из имён там конфликтует (есть в обоих). Тогда только оно алиасится, а остальные применяются напрямую.
N>Через алиас для пространства это немного удобнее, но не до конца.
N>Или есть случаи, когда имя в пространстве само по себе безумно длинное, а удобно назвать его короче, или просто переименовать в пределах данного модуля в соответствии с более подходящим смыслом. Такое данным методом вообще не решается.

Ну так это ты плачешь об общей проблеме переименования (или даже о еще более общей проблеме выделения имени в первоклассную сущность), пространства имен тут ни при чем, эта же проблема у тебя будет и без них.
Действительно, общего решения этой проблемы нет.
Для частных случаев есть частные решения:
— Пространства имен: приведенный выше [namespace.alias]
— Типы: typedef
— Переменные: ссылки
— Шаблоны: алиасы шаблонов [temp.alias] (C++11)
— Функции: общего решения нет из-за наличия перегрузки, надо либо через указатели на функции, либо через библиотечные решения типа std::function/std::bind (C++11/ищщые)
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[4]: И снова про ц++
От: Sheridan Россия  
Дата: 03.02.12 08:43
Оценка:
Здравствуйте, gandjustas, Вы писали:


G>Действительно не при чем. Вопрос должен быть такой: какого размера проекты ты делал на С++ и не не-С++ чтобы сам мог понять разницу?

https://github.com/Sheridan/HAcc
https://github.com/Sheridan/gpstool
Matrix has you...
Re[4]: И снова про ц++
От: LaptevVV Россия  
Дата: 03.02.12 08:45
Оценка:
Здравствуйте, x-code, Вы писали:

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


XC>>>Отсутствие вложенных блочных комментариев

LVV>>Это мелочь
XC>Из мелочей состоит все. И красота языка программирования именно в мелочах. Я кстати придумал третий совершенно новый и очень удобный вид комментариев (кроме блочных и однострочных).
Покажь! Мы в свой язык и среду добавим — со ссылкой на автора.

XC>>>Имя массива является адресом первого элемента массива (нелогично! со структурами же не так)

LVV>>ИМХО для С это было самое то! Но для С++, который позиционируется как язык более высокого уровня, — это анахронизм.
XC>>>Отсутствие низкоуровневых возможностей: sizeof( ) от функции и блока кода, goto на переменные метки (в gcc есть, но это нестандартно)
LVV>>Зачем?
XC>Для различных хакерских целей возможно и понадобится. Или для целей защиты программ от взлома.
Ассемблерные вставки спасут отца русской демократии
XC>>>Невозможность передачи массивов в фигурных скобках "как есть" в функции Foo({1,2,3});
LVV>>Если бы массивы были полноценные объекты — это было бы самое то!
XC>Все должно быть полноценными объектами, и числа, и строки. То есть должны быть вызовы вида 10.ToStr(), "Hello".ToUpper(), но при этом эти "объекты" должны оставаться простыми сущностями.
Я так понимаю, что настал момент разработки волны языков следующего уровня (после паскаля и С)
XC>>>Отсутствие именованных блоков кода, соответственно невозможность сделать break и continue на именованный блок/из блока
LVV>>Это мелочь. Особенно при наличии goto. Если goto убрать, то да.
XC>goto тоже нужно оставить, это уникальный оператор безусловного перехода, и в некоторых особых случаях заменой ему могут быть только ассемблерные вставки. Уберем — и получим очередную джаву, на которой ничего кроме бизнес-бухгалтерии и не напишешь.
В нашем языке вообще нет меток — никаких. И никаких операторов перехода. Только структурные.
XC>>>Отсутствие методов-расширений, отсутствие возможности обращаться к методу класса как к статическому с явной (ручной) передачей this
LVV>>Сильно напрягает?
XC>Если возможность может быть, она ДОЛЖНА быть.
Не согласен. Тут чувство меры разработчика большую рояль играет.
Иначе вместо языка получим большую кучу сами знаете чего.
Страуструп, кстати, в С++ играет роль цензора...
XC>>>Отсутствие системы сообщений как в ObjectiveC, встроенной системы сигналов и слотов как в QT
LVV>>А где такое еще есть?
XC>Ну вот в ObjC и QT есть.
Сигналы со слотами мне нравятся — это как-то сильно понятно... Даже новичкам в программировании...
XC>>>Невозможность создания namespace внутри класса (вспомните хотя-бы "главные оконные классы" разных библиотек — CWnd, QWidget... сотни методов, там разделение не помешало бы)
LVV>>ИМХО сотни методов — это проблема реализации. И следствие отсутствия нормальной модульности.
XC>Да пусть у меня всего 4 метода в классе, но я хочу разделить их в две группы, что не имею права?
А два класса написать с общим абстрактным предком — не?
XC>>>Отсутствие замыканий, простого объявления функциональных типов (int=>int)
LVV>>А надо?
XC>Код должен быть простым. Если я хочу объявить аргумент "функцию, принимающую на вход int и возвращающую int", я хочу сделать это максимально простым и естественным способом: "int=>inf f" и передавать туда что угодно — метод класса, глобальную функцию, лямбду, функтор с перегруженным operator() и т.д. Это должно работать без шаблонов, если я хочу без шаблонов.
Вот насчет "передавать что угодно" я сильно против. Зачем тогда тип указывать? Пусть принимает any и возвращает any...
XC>>>Отсутствие кортежей, групповых операций над кортежами, невозможность вернуть из функции несколько значений напрямую
LVV>>Напрямую — это как?
XC>После многих вариантов я остановился на таком варианте синтаксиса функций, ИМХО самый оптимальный из всех возможных:
XC>
def Func(int a, b, c) int x, y
XC>{
XC>  x = a*b + c;
XC>  y = a/b - c;
XC>}
XC>// ну и вызов, какие-то две переменные объявленные где-то, объединяем их в кортеж и принимаем результат функции
XC>(i, j) = Func(100,200,300);

Это — хорошо...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[5]: И снова про ц++
От: Философ Ад http://vk.com/id10256428
Дата: 03.02.12 08:48
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Покажь! Мы в свой язык и среду добавим — со ссылкой на автора.


Очень любопытно.
Всё сказанное выше — личное мнение, если не указано обратное.
Re[3]: И снова про ц++
От: Mamut Швеция http://dmitriid.com
Дата: 03.02.12 08:49
Оценка:
S>>>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++? Указатели? Да фигня это, на пару граблей наступить и рефлекс появится. Зато более шустрый софт получается.

M>>И при этом ты поносишь браузеры и IDE, которые на этом самом С++ написаны. Нуну.

S>Гм, напомни ка...

Жрут много памяти и тормозят ©

M>>А так: C++ можно не любить хотя бы за отсутсвие вменяемых строк. Хотя твой мозг отказывается понимать, что строки — это не последовательность char'ов, это так.

S>std::string чем невменяемо?

Мультибайтные кодировки.


dmitriid.comGitHubLinkedIn
Re[4]: И снова про ц++
От: Mamut Швеция http://dmitriid.com
Дата: 03.02.12 08:50
Оценка:
S>>>>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++?
AVL>>>слабая маркетинговая составляющая
S>>Каким боком маркетинг относится к языку программирования?
AVL>да напрямую. ц++ старый, следовательно немодный/беспонтовый/ненужный и т.д.
AVL>массовым погромистам гораздо проще развешивать лапшу прикрываясь всякими С# 100500 / мета- / фукнциональное программирование / лямбды / монады / linq / макросы / прочая фигня. а да, виртуальные машины забыл, тоже модная тема.

Выделенное — не лапша, а очень удобные инструменты. Которые — ВНЕЗАПНО — тоже появляются в С++


dmitriid.comGitHubLinkedIn
Re[4]: И снова про ц++
От: Sheridan Россия  
Дата: 03.02.12 08:55
Оценка:
Здравствуйте, Mamut, Вы писали:

M>>>И при этом ты поносишь браузеры и IDE, которые на этом самом С++ написаны. Нуну.

S>>Гм, напомни ка...
M>Жрут много памяти и тормозят ©
Ну так то я про всякие эклипсы

M>>>А так: C++ можно не любить хотя бы за отсутсвие вменяемых строк. Хотя твой мозг отказывается понимать, что строки — это не последовательность char'ов, это так.

S>>std::string чем невменяемо?
M>Мультибайтные кодировки.
std::wstring?
Matrix has you...
Re[5]: И снова про ц++
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.02.12 09:04
Оценка:
Здравствуйте, Sheridan, Вы писали:

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



G>>Действительно не при чем. Вопрос должен быть такой: какого размера проекты ты делал на С++ и не не-С++ чтобы сам мог понять разницу?

S>https://github.com/Sheridan/HAcc
S>https://github.com/Sheridan/gpstool

А не-с++ ?
Re[6]: И снова про ц++
От: LaptevVV Россия  
Дата: 03.02.12 09:06
Оценка:
Здравствуйте, Философ, Вы писали:

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


LVV>>Покажь! Мы в свой язык и среду добавим — со ссылкой на автора.


Ф>Очень любопытно.

Мечта (моя) с 1999 года. Наконец нашелся пацан, который РЕАЛЬНО пишет. И еще года 4 будет писать. До защиты диссера.
И командочка вокруг него подбирается. Которым не только диплом, а еще и интересно.
В сентябре будем внедрять заместо Кумира первую рабочую версию. Вот объектную часть доделаем — и вперед!
Расширяемая среда программирования для препода. Со структурным языком программирования.
Одной кнопочкой синтаксис переключается на 3 языка: Оберон, Додиез, наш.
Другой кнопочкой — семантика копирования на семантику ссылочную.
третьей кнопочкой — с русской на английскую лексику и обратно...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re: И снова про ц++
От: TimurSPB Интернет  
Дата: 03.02.12 09:07
Оценка:
S>Так все же?
Просто у многих отсутствуют или слабо развиты отделы головного мозга, ответственные за понимание указателей и разворачивание макросов в уме. Это вызывает негативную эмоциональную реакцию. Примерно такую же реакцию проявляет сиплюсплюсник, когда речь заходит о гуманитарных "науках".
Make flame.politics Great Again!
Re: И снова про ц++
От: leshikru  
Дата: 03.02.12 09:08
Оценка:
S>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++? Указатели? Да фигня это, на пару граблей наступить и рефлекс появится. Зато более шустрый софт получается.
S>Так все же?

Смысла говорить про "нелюбовь" нет — люди будут защищаться и писать разное. Каждый язык хорош под свою задачу. C++ хорошо для написания критичного по памяти и времени исполнения кода профессионалами с отличным пониманием железа. Perl хорош для парсинга строчек, C#(Delphi, VB, PHP) хорош для слепливания кучи разнообразных компонент в одну систему. В наше время компонент написано настолько много, что смысла писать что-то своё нет в 99% случаев. А для использования готовых компонент С++ не очень удобен.
Re[7]: И снова про ц++
От: Философ Ад http://vk.com/id10256428
Дата: 03.02.12 09:11
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Здравствуйте, Философ, Вы писали:


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


LVV>>>Покажь! Мы в свой язык и среду добавим — со ссылкой на автора.


Ф>>Очень любопытно.


ICQ: 435340832 — (Философ)
Всё сказанное выше — личное мнение, если не указано обратное.
Re[4]: И снова про ц++
От: TimurSPB Интернет  
Дата: 03.02.12 09:11
Оценка:
Ф>ЗЫ: ЦПП — мутант переходного периода.
Крайне живучий мутант, надо заметить!
Make flame.politics Great Again!
Re[4]: И снова про ц++
От: TimurSPB Интернет  
Дата: 03.02.12 09:14
Оценка:
XC>goto тоже нужно оставить
Сказал бы я. Но меня тут недавно в бан отправляли уже за высказывания относительно пробелов и табов.
Make flame.politics Great Again!
Re[5]: И снова про ц++
От: Философ Ад http://vk.com/id10256428
Дата: 03.02.12 09:16
Оценка:
Здравствуйте, TimurSPB, Вы писали:

Ф>>ЗЫ: ЦПП — мутант переходного периода.

TSP>Крайне живучий мутант, надо заметить!

к сожалениею новые мутанты оказываются или хуже, или такого же качества
чтоб C++ начал умирать должен появиться действительно хороший нативный ЯВУ, поддерживаемый софтверными гигантами

если бы не сан и мелкософт, ява и шарп были бы где-то в анале
Всё сказанное выше — личное мнение, если не указано обратное.
Re[8]: И снова про ц++
От: LaptevVV Россия  
Дата: 03.02.12 09:18
Оценка:
Здравствуйте, Философ, Вы писали:

LVV>>>>Покажь! Мы в свой язык и среду добавим — со ссылкой на автора.

Ф>>>Очень любопытно.
Ф>ICQ: 435340832 — (Философ)
Аськой не пользуюсь — никакой.
Сижу здесь, в контакте в одноклассниках, в моем мире.
Мыло в профиле — рабочее.
Адрес в контакте — тоже рабочий.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[6]: И снова про ц++
От: LaptevVV Россия  
Дата: 03.02.12 09:25
Оценка:
Здравствуйте, x-code, Вы писали:

LVV>>Покажь! Мы в свой язык и среду добавим — со ссылкой на автора.

XC>Комментарии лексически корректного блока.
XC>
rem if(x>0) { 
XC>  // ...
XC>  while(b) {
XC>      // ...
XC>      for(int i=0; i<n; i++)
XC>       {
XC>          // ...
XC>       }
XC>  }
XC>  x = y;
XC>  // ...
XC>}

XC>Можно закомментировать целый блок, к такому блоку применяется только лексический анализ и базовое построение AST, без проверки всего остального. То есть если у блока корректно расставлены скобки, то неважно что там внутри (несуществующие переменные и т.д.) — его можно закомментировать. В простейших случаях можно сымитировать, подставляя в блоки невыполнимые условия "if(0)" и т.п. Но если сделать это отдельным ключевым словом, то получим кучу преимуществ — это воспринимается как осмысленное действие, а не как случайная ошибка программиста; в IDE поялвяется возможность подсветки; ну и упрощенный парсинг кода позволит не ругаться на возможных ошибках.
Понятно. В нашем редакторе это делается одной клавишей:
превратить узел-оператор в комментарий. И обратно.
Но для текстового представления программы — любопытно. Надо пообсуждать с пацанами.
XC>>>Если возможность может быть, она ДОЛЖНА быть.
LVV>>Не согласен. Тут чувство меры разработчика большую рояль играет.
LVV>>Иначе вместо языка получим большую кучу сами знаете чего.
XC>Ну это мое личное ИМХО. Мне нравятся языки возможностей, а не языки ограничений. А большую кучу можно получить из чего угодно, достаточно просто захотеть от языка немного больше того, на что он рассчитан. Пример — С++ с шаблонами и попытками метапрограммирования на них.
XC>Был бы в С++ вместо препроцессора макропроцессор, работающий с AST, с грамотно спроектированным синтаксисом — никто бы даже не полез на шаблонах что-то такое делать...
Согласен!
XC>>>Да пусть у меня всего 4 метода в классе, но я хочу разделить их в две группы, что не имею права?
LVV>>А два класса написать с общим абстрактным предком — не?
XC>Не. У меня есть объект конкретного класса, у которого внутри сотни методов, полученных ЛЮБЫМ путем, может быть — длинная цепочка наследования, может быть все сразу объявлены, неважно. Я в IDE пишу "obj." и мне автокомплит выдает ПРОСТЫНЮ из методов, отсортированных тупо в алфавитном порядке. А я хочу, чтобы мне выдавалось около 10 внутренних неймспейсов, между которыми методы разгруппированы ПО СМЫСЛУ. Кстати, кроме иерархических неймспейсов можно ввести и "теги", правда это я еще не обдумывал.
Спасибо. Надо с пацанами пообсуждать...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[6]: И снова про ц++
От: Sheridan Россия  
Дата: 03.02.12 09:42
Оценка:
Здравствуйте, gandjustas, Вы писали:

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


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



G>>>Действительно не при чем. Вопрос должен быть такой: какого размера проекты ты делал на С++ и не не-С++ чтобы сам мог понять разницу?

S>>https://github.com/Sheridan/HAcc
S>>https://github.com/Sheridan/gpstool

G>А не-с++ ?

Остальные мои на гитхабе кроме mon. Плюс писал для заббикса генератор-конфигуратор на змее, который сканировал сети, искал устройства и просил заббикс их мониторить. Ну и помелочам дохрена писал.
Matrix has you...
Re[7]: И снова про ц++
От: x-code  
Дата: 03.02.12 09:42
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Спасибо. Надо с пацанами пообсуждать...


Где можно почитать о вашем проекте?
Re[8]: И снова про ц++
От: LaptevVV Россия  
Дата: 03.02.12 09:45
Оценка:
Здравствуйте, x-code, Вы писали:

LVV>>Спасибо. Надо с пацанами пообсуждать...

XC>Где можно почитать о вашем проекте?
В РСДН статью напишем месяца через 2.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[5]: И снова про ц++
От: Mamut Швеция http://dmitriid.com
Дата: 03.02.12 10:00
Оценка:
M>>>>И при этом ты поносишь браузеры и IDE, которые на этом самом С++ написаны. Нуну.
S>>>Гм, напомни ка...
M>>Жрут много памяти и тормозят ©
S>Ну так то я про всякие эклипсы

И про ФФ с Хромом.

M>>>>А так: C++ можно не любить хотя бы за отсутсвие вменяемых строк. Хотя твой мозг отказывается понимать, что строки — это не последовательность char'ов, это так.

S>>>std::string чем невменяемо?
M>>Мультибайтные кодировки.
S>std::wstring?

string --> char
wstring --> wchar

wchar == 2 байта в винде, 4 байта в линуксе

И в любом случае они, в основном, позволяют хранить и выводить текст, но не позволяют других манипуляций. Не говоря уже о «удобстве» иметь два набора функций для манипуляции типа strlen и wcslen и т.п.


dmitriid.comGitHubLinkedIn
Re[7]: И снова про ц++
От: Философ Ад http://vk.com/id10256428
Дата: 03.02.12 10:16
Оценка:
Здравствуйте, okman, Вы писали:

O>Здравствуйте, Философ, Вы писали:


Ф>>строки должны быть единственными

Ф>>а тут только в std уже 2 варианта

O>32-битных системах весит "аж" 24 байта.



ржал аки конь
Всё сказанное выше — личное мнение, если не указано обратное.
Re[4]: И снова про ц++
От: Философ Ад http://vk.com/id10256428
Дата: 03.02.12 10:21
Оценка:
Здравствуйте, x-code, Вы писали:

XC>После многих вариантов я остановился на таком варианте синтаксиса функций, ИМХО самый оптимальный из всех возможных:

XC>
def Func(int a, b, c) int x, y
XC>{
XC>  x = a*b + c;
XC>  y = a/b - c;
XC>}
XC>// ну и вызов, какие-то две переменные объявленные где-то, объединяем их в кортеж и принимаем результат функции
XC>(i, j) = Func(100,200,300);



гм...
попробую развить идею

[code]def T Func(int a, b, c) int x, y
{
x = a*b + c;
y = a/b — c;
}
[code]

[code]
deftype T Func(int a, b, c) int x, y;
[code]
Всё сказанное выше — личное мнение, если не указано обратное.
Re[8]: И снова про ц++
От: okman Беларусь https://searchinform.ru/
Дата: 03.02.12 10:47
Оценка:
Здравствуйте, Mamut, Вы писали:

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


Критерий нормальности строк, пожалуйста. Иначе как-то необъективно.
Re[8]: И снова про ц++
От: okman Беларусь https://searchinform.ru/
Дата: 03.02.12 10:48
Оценка:
Здравствуйте, Философ, Вы писали:

Ф>ржал аки конь


Расскажи, что смешного — я тоже поржать люблю.
Re[6]: И снова про ц++
От: Sheridan Россия  
Дата: 03.02.12 10:59
Оценка:
Здравствуйте, Mamut, Вы писали:

M>И про ФФ с Хромом.

Про них в сравнении с кальпаклаудом я говорил.


M>И в любом случае они, в основном, позволяют хранить и выводить текст, но не позволяют других манипуляций. Не говоря уже о «удобстве» иметь два набора функций для манипуляции типа strlen и wcslen и т.п.

Ок, пожалуй соглашусь, так как других способов не знаю, хотя они поидее должны быть.
Matrix has you...
Re[10]: И снова про ц++
От: okman Беларусь https://searchinform.ru/
Дата: 03.02.12 11:06
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Вообще-то, в 21-м веке нормальность — это поддержка хотя бы utf8.


Не совсем соответствует действительности. Работать с UTF-8 (и не только) можно посредством
UnicodeString из ICU, QString из Qt, это как минимум. Не могу привести больше примеров,
так как в WinAPI UTF-8 не особо популярна. А еще для обеспечения поддержки UTF-8 используют
все тот же std::string, у меня несколько месяцев назад был спор с uzhas на эту тему.

M>Ну и да, количество реализаций строк для С++ намекает на то, что в консерватории что-то не так.


Эдак можно прийти к выводу, что linux тоже в глубоком ауте из-за разнообразия версий.
А на самом деле обилие реализаций всего лишь отражает широту круга задач, которые ими решаются.
Re[3]: И снова про ц++
От: gegMOPO4  
Дата: 03.02.12 11:14
Оценка:
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, x-code, Вы писали:
XC>>Ужасная система #include и препоцессора,
N>Для своих задач препроцессор вполне адекватен. С другой стороны, ничто не мешает при необходимости сделать над ним что-то своё. Например, на m4, не к ночи будь сказано (но всё равно для мелких задач начинают выбор с него) или на любом другом макропроцессоре, какой понравится.

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

XC>> отсутствие нормальной модульной системы

N>Если речь про схему в стиле Вирта (тут interface, а тут implementation), то несложно заметить, что почему-то она не прижилась в промышленности и не была принята ни в одном языке, начатом "с нуля", заведомо позже массового распространения Паскаля. Например, она не была принята ни в Java ни в C#. Зато подход с заголовочными описаниями распространяется практически на все языки. Я думаю, у "нормальной модульной системы" всё-таки есть какой-то фатальный недостаток.

Где ещё, кроме C/C++ (и нескольких непродуманных язычков вроде PHP) используется «модульность» на основе #include? Как раз в Java отдельный файл — отдельный класс, единица трансляции, пространство имён, единица организации кода.

Есть два преимущества системы C — раздельная компиляция и совместимость со старым кодом на ассемблере и Фортране. Первое сейчас не критично, в память влазит полностью и файл-исходник, и выход, и промежуточное представление, и интерфейсы других модулей. Совместимость же сейчас интереснее с другими языками (Java, Python,...).

XC>>Невозможность создания namespace внутри класса (вспомните хотя-бы "главные оконные классы" разных библиотек — CWnd, QWidget... сотни методов, там разделение не помешало бы)

N>В принципе согласен. Более того, система namespace неудобна.
N>Постоянно хочется решений в стиле питоновского import X.Y.Z as W.

namespace W = X::Y::Z;
Re[6]: И снова про ц++
От: Banned by IT  
Дата: 03.02.12 11:40
Оценка:
Здравствуйте, Философ, Вы писали:

Ф>чтоб C++ начал умирать должен появиться действительно хороший нативный ЯВУ, поддерживаемый софтверными гигантами

Ой таки шота он так умирает шо ещё нас с вами переживёт.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[4]: И снова про ц++
От: Banned by IT  
Дата: 03.02.12 11:40
Оценка:
Здравствуйте, x-code, Вы писали:

XC>>>Отсутствие вложенных блочных комментариев

LVV>>Это мелочь
XC>Из мелочей состоит все. И красота языка программирования именно в мелочах.
Красота побоку. Главное чтоб задачи решил как надо. Существующая система include мне ещё ни разу не мешала, и showstopperом не была.

XC> Я кстати придумал третий совершенно новый и очень удобный вид комментариев (кроме блочных и однострочных).

И какой же?

XC>>>Отсутствие низкоуровневых возможностей: sizeof( ) от функции и блока кода, goto на переменные метки (в gcc есть, но это нестандартно)

LVV>>Зачем?
XC>Для различных хакерских целей возможно и понадобится. Или для целей защиты программ от взлома.
Я понимаю зачем такое может быть нужно, и уже решал подобные задачи защиты. Но для работы с телом функции я лучше заюзаю debug information. Это будет куда правильнее чем волочь эту редкоиспользуемую функциональность в язык в ущерб качеству генерируемого кода.

XC>Все должно быть полноценными объектами, и числа, и строки. То есть должны быть вызовы вида 10.ToStr(), "Hello".ToUpper(), но при этом эти "объекты" должны оставаться простыми сущностями.

Получится жуткий кадавр.

LVV>>Это мелочь. Особенно ghyb наличии goto/ Если goto убрать, то да.

XC>goto тоже нужно оставить, это уникальный оператор безусловного перехода, и в некоторых особых случаях заменой ему могут быть только ассемблерные вставки. Уберем — и получим очередную джаву, на которой ничего кроме бизнес-бухгалтерии и не напишешь.
Мы пишем системные вещи но goto только в plain С наблюдается, в основном потому что там RAII нету.

XC>>>Отсутствие методов-расширений, отсутствие возможности обращаться к методу класса как к статическому с явной (ручной) передачей this

LVV>>Сильно напрягает?
XC>Если возможность может быть, она ДОЛЖНА быть.
Ты лучше объясни зачем. А то получается что в языке должна быть встроена любая возможность какая только может быть придумана.

XC>>>Отсутствие системы сообщений как в ObjectiveC, встроенной системы сигналов и слотов как в QT

LVV>>А где такое еще есть?
XC>Ну вот в ObjC и QT есть.
Где такое ещё есть? Кроме ObjC и QT.

XC>>>Невозможность создания namespace внутри класса (вспомните хотя-бы "главные оконные классы" разных библиотек — CWnd, QWidget... сотни методов, там разделение не помешало бы)

LVV>>ИМХО сотни методов — это проблема реализации. И следствие отсутствия нормальной модульности.
XC>Да пусть у меня всего 4 метода в классе, но я хочу разделить их в две группы, что не имею права?
А как ты их потом будешь вызывать? Указывая namespace каждый раз? Сделаешь using namespace? Ну так а нахрена их тогда было разделять?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[5]: И снова про ц++
От: Banned by IT  
Дата: 03.02.12 11:40
Оценка:
Здравствуйте, TimurSPB, Вы писали:

XC>>goto тоже нужно оставить

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

А ты корректно выражайся, и не категорично а с обоснованием. Корректным опять таки.
То что мне вспоминается про тебя и пробелы и табы — исключительно "слова не мужа, но юнца".
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[6]: И снова про ц++
От: Banned by IT  
Дата: 03.02.12 11:40
Оценка:
Здравствуйте, Философ, Вы писали:

Ф>строки должны быть единственными

Вот есть у тебя единственный формат строк. И входные/выходные данные в UTF8 и UTF32. Как с ними будешь работать? Приводить все к UTF16 а потом назад?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[5]: И снова про ц++
От: x-code  
Дата: 03.02.12 12:02
Оценка:
Здравствуйте, Banned by IT, Вы писали:

BBI>Красота побоку. Главное чтоб задачи решил как надо. Существующая система include мне ещё ни разу не мешала, и showstopperом не была.

Циклические include всякие. Да и вообще я не хочу, чтобы особенности расположения файлов были как-то связаны с программой. Должна быть система пространств имен и операторы подключения типа using.

XC>>Все должно быть полноценными объектами, и числа, и строки. То есть должны быть вызовы вида 10.ToStr(), "Hello".ToUpper(), но при этом эти "объекты" должны оставаться простыми сущностями.

BBI>Получится жуткий кадавр.
При наличии методов-расширений все получится вообще элементарно. string ToStr(this int x) и т.д.

BBI>Мы пишем системные вещи но goto только в plain С наблюдается, в основном потому что там RAII нету.

В каком-нибудь ядре Linux наверняка немало goto. А оно написано на древнем Си.

XC>>>>Отсутствие методов-расширений, отсутствие возможности обращаться к методу класса как к статическому с явной (ручной) передачей this

LVV>>>Сильно напрягает?
XC>>Если возможность может быть, она ДОЛЖНА быть.
BBI>Ты лучше объясни зачем. А то получается что в языке должна быть встроена любая возможность какая только может быть придумана.
Для функциональной полноты языка. Если есть фичи X и Y, то должны быть и их "суперпозиции" X(Y) и Y(X). Чтобы не было непонятных ограничений.
Простейший пример — если в функцию можно передать строку как адрес массива char*, то почему нельзя передать явный массив любых других объектов?
Или еще: если в классе можно объявить функцию (метод) и другой (вложенный) класс, в функции можно объявить вложенный класс, то почему в функции нельзя объявить вложенную функцию?

XC>>>>Отсутствие системы сообщений как в ObjectiveC, встроенной системы сигналов и слотов как в QT

LVV>>>А где такое еще есть?
XC>>Ну вот в ObjC и QT есть.
BBI>Где такое ещё есть? Кроме ObjC и QT.

Все языки с динамической типизацией.
В том же C# 4 ввели "dynamic", с которым также можно вызывать несуществующие методы.
Кроме того, в проектах на обычном си я видел реализации аналогов "мягкого связывания", сделанные вручную. Естественно, выглядит это коряво и громоздко.

XC>>Да пусть у меня всего 4 метода в классе, но я хочу разделить их в две группы, что не имею права?

BBI>А как ты их потом будешь вызывать? Указывая namespace каждый раз? Сделаешь using namespace? Ну так а нахрена их тогда было разделять?

Чтобы сгруппировать логически. Вызывать — в основном, указывая namespace как часть имени каждый раз. Внутри namespace естественно не указываем.
Re[6]: И снова про ц++
От: TimurSPB Интернет  
Дата: 03.02.12 12:05
Оценка:
BBI>А ты корректно выражайся, и не категорично а с обоснованием. Корректным опять таки.
Есть вопросы, в которых единых обоснований нет.
BBI>То что мне вспоминается про тебя и пробелы и табы — исключительно "слова не мужа, но юнца".
Демагогия. Приплетать юнцов к пробелам, табам и С++
Make flame.politics Great Again!
Re[5]: И снова про ц++
От: Sheridan Россия  
Дата: 03.02.12 12:21
Оценка:
Здравствуйте, x-code, Вы писали:

XC>Ну вот в C# вроде нормальная модульная система. Раздельная компиляция, но никаких include,

Ну да, include нет, есть using.
Matrix has you...
Re[6]: И снова про ц++
От: Sheridan Россия  
Дата: 03.02.12 12:41
Оценка:
Здравствуйте, x-code, Вы писали:


XC>Циклические include всякие.


aaa.h
#ifndef aaa
#define aaa
// пишем, не имея проблем с циклическими инклудами. Любая иде так делает сразу.
#endif aaa
Matrix has you...
Re[6]: И снова про ц++
От: Cadet  
Дата: 03.02.12 12:45
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Ну да, include нет, есть using.


Отсутствие юзинга не помешает использовать нужный класс, а отсутствие инклюда помешает.
... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
Re[6]: И снова про ц++
От: Banned by IT  
Дата: 03.02.12 13:01
Оценка:
Здравствуйте, x-code, Вы писали:

BBI>>Красота побоку. Главное чтоб задачи решил как надо. Существующая система include мне ещё ни разу не мешала, и showstopperом не была.

XC>Циклические include всякие.
Это лечится. Впрочем, циклических я давненько не видел.

XC>>>Все должно быть полноценными объектами, и числа, и строки. То есть должны быть вызовы вида 10.ToStr(), "Hello".ToUpper(), но при этом эти "объекты" должны оставаться простыми сущностями.

BBI>>Получится жуткий кадавр.
XC>При наличии методов-расширений все получится вообще элементарно. string ToStr(this int x) и т.д.
А чем не нравится конструктор string (int x)?

BBI>>Мы пишем системные вещи но goto только в plain С наблюдается, в основном потому что там RAII нету.

XC>В каком-нибудь ядре Linux наверняка немало goto. А оно написано на древнем Си.
Вот вот. А С++ то при чём. Использовать goto в современном c++ нет никакой необходимости.

XC>Простейший пример — если в функцию можно передать строку как адрес массива char*, то почему нельзя передать явный массив любых других объектов?

Объяви рядом да передай. Со строками это явный частный случай, бо частота использования зашкаливала.

XC>Или еще: если в классе можно объявить функцию (метод) и другой (вложенный) класс, в функции можно объявить вложенный класс, то почему в функции нельзя объявить вложенную функцию?

Я честно говоря уже не помню какое там было обоснование почему так не стали делать.

XC>>>Да пусть у меня всего 4 метода в классе, но я хочу разделить их в две группы, что не имею права?

BBI>>А как ты их потом будешь вызывать? Указывая namespace каждый раз? Сделаешь using namespace? Ну так а нахрена их тогда было разделять?
XC>Чтобы сгруппировать логически.
Это лучше сделать на стороне гуя.

XC>Вызывать — в основном, указывая namespace как часть имени каждый раз. Внутри namespace естественно не указываем.

Этож жутко неудобно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[7]: И снова про ц++
От: Banned by IT  
Дата: 03.02.12 13:01
Оценка:
Здравствуйте, TimurSPB, Вы писали:

BBI>>То что мне вспоминается про тебя и пробелы и табы — исключительно "слова не мужа, но юнца".

TSP>Демагогия. Приплетать юнцов к пробелам, табам и С++

Ну а как ещё понять твои заявления про дебилов? Детский максимализм и только.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[8]: И снова про ц++
От: TimurSPB Интернет  
Дата: 03.02.12 13:11
Оценка:
BBI>Ну а как ещё понять твои заявления про дебилов? Детский максимализм и только.
Как моё полное отрицание использования табуляций при форматировании кода и не желание тратить на эти споры лишние буквы.
Make flame.politics Great Again!
Re[11]: И снова про ц++
От: x-code  
Дата: 03.02.12 13:33
Оценка:
Здравствуйте, Banned by IT, Вы писали:

XC>>Я хочу, чтобы строка в кавычках была просто объектом. Чтобы не было даже привязки к кодировке (utf16, utf8, windows...), к внутреннему устройству и т.д.

BBI>Добро пожаловать в реальный мир.

И как я могу в С++ одновременно иметь две разные константные строки в разных кодировках?
Re[7]: И снова про ц++
От: Sheridan Россия  
Дата: 03.02.12 14:16
Оценка:
Здравствуйте, Cadet, Вы писали:

S>>Ну да, include нет, есть using.


C>Отсутствие юзинга не помешает использовать нужный класс, а отсутствие инклюда помешает.

Отсутствие юзингов вообще?
Matrix has you...
Re[8]: И снова про ц++
От: Sheridan Россия  
Дата: 03.02.12 14:17
Оценка:
Здравствуйте, x-code, Вы писали:

XC>Красота языка определяется отсутствием таких вот обходных путей (а это именно обходной путь!). Да, в данном случае обойти просто... но это в данном случае, вполне могут быть случаи и посложнее. Мне нужен язык, в котором вообще ничего не нужно обходить.


Как страшно жить...
Еще раз: эту обертку делает IDE.
Matrix has you...
Re[8]: И снова про ц++
От: hardcase Пират http://nemerle.org
Дата: 03.02.12 15:19
Оценка:
Здравствуйте, Sheridan, Вы писали:

C>>Отсутствие юзинга не помешает использовать нужный класс, а отсутствие инклюда помешает.

S>Отсутствие юзингов вообще?

Юзингов нет ваще.
C#
class Program
{
  static void Main() { System.Console.WriteLine("Hello world!"); }
}

Nemerle:
System.Console.WriteLine("Hello world!");
/* иЗвиНите зА неРовнЫй поЧерК */
Re[12]: И снова про ц++
От: Banned by IT  
Дата: 03.02.12 15:24
Оценка:
Здравствуйте, x-code, Вы писали:

XC>>>Я хочу, чтобы строка в кавычках была просто объектом. Чтобы не было даже привязки к кодировке (utf16, utf8, windows...), к внутреннему устройству и т.д.

BBI>>Добро пожаловать в реальный мир.

XC>И как я могу в С++ одновременно иметь две разные константные строки в разных кодировках?

http://en.wikipedia.org/wiki/C%2B%2B11#New_string_literals
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[2]: И снова про ц++
От: D.Lans Россия  
Дата: 03.02.12 15:28
Оценка:
А какой есть аналог у C++?
Re[8]: И снова про ц++
От: Cadet  
Дата: 03.02.12 15:49
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Отсутствие юзингов вообще?


Совершенно верно.
... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
Re[2]: namespace'ы в классах
От: Sheridan Россия  
Дата: 03.02.12 15:56
Оценка:
Здравствуйте, x-code, Вы писали:

XC>Невозможность создания namespace внутри класса (вспомните хотя-бы "главные оконные классы" разных библиотек — CWnd, QWidget... сотни методов, там разделение не помешало бы)


Ну если очень надо — можно и нарисовать, благо нетрудно. У меня — не программиста — ушло гдето минут 10...

#include <iostream>
using namespace std;

#define C_NAMESPACE_BASE(_base) m_##_base
#define C_NAMESPACE_BEGIN(_ns, _base) \
class class##_ns \
  { \
    private: \
      _base *C_NAMESPACE_BASE(_base); \
    public: \
      class##_ns(_base *v_##_base) { C_NAMESPACE_BASE(_base) = v_##_base; };
#define C_NAMESPACE_END(_ns) \
  }; \
  public: class##_ns *_ns;.

#define C_NAMESPACE_INIT(_ns) _ns = new class##_ns(this);
#define C_NAMESPACE_DELETE(_ns) delete _ns;

class Parent
{
  C_NAMESPACE_BEGIN(SubNS, Parent)
  void f() { cout << "Hi, " << C_NAMESPACE_BASE(Parent)->c()  << "!" << endl; }
  C_NAMESPACE_END(SubNS)

  C_NAMESPACE_BEGIN(OtherNameSpace, Parent)
  void f() { cout << "Hi, " << C_NAMESPACE_BASE(Parent)->c()  << "! This is other namespace :))" << endl; }
  C_NAMESPACE_END(OtherNameSpace)

  public:
  Parent() { C_NAMESPACE_INIT(SubNS) C_NAMESPACE_INIT(OtherNameSpace) };
  ~Parent() { C_NAMESPACE_DELETE(SubNS) C_NAMESPACE_DELETE(OtherNameSpace) }
  int c() { return 123; }
};

int main ()
{
  Parent *p = new Parent();
  p->SubNS->f();
  p->OtherNameSpace->f();
}


gate ~ # g++ example.cpp -o example
gate ~ # ./example
Hi, 123!
Hi, 123! This is other namespace :))


Другое дело что на ненавистных местными дефайнах.... Ну уж это я считаю что они ими пользоваться не умеют...
Matrix has you...
Re[3]: Ах, да. Реализацию забыл от объявления отделить
От: Sheridan Россия  
Дата: 03.02.12 16:01
Оценка:
Ну это несложно, перепишем так:

#include <iostream>
using namespace std;

#define C_NAMESPACE_BASE(_base) m_##_base
#define C_NAMESPACE_BEGIN(_ns, _base) \
class class##_ns \
  { \
    private: \
      _base *C_NAMESPACE_BASE(_base); \
    public: \
      class##_ns(_base *v_##_base) { C_NAMESPACE_BASE(_base) = v_##_base; };
#define C_NAMESPACE_END(_ns) \
  }; \
  public: class##_ns *_ns;.

#define C_NAMESPACE_INIT(_ns) _ns = new class##_ns(this);
#define C_NAMESPACE_DELETE(_ns) delete _ns;
#define C_NAMESPACE_PATH(_ns, _base) _base::class##_ns

class Parent
{
  C_NAMESPACE_BEGIN(SubNS, Parent)
  void f();
  C_NAMESPACE_END(SubNS)

  C_NAMESPACE_BEGIN(OtherNameSpace, Parent)
  void f();
  C_NAMESPACE_END(OtherNameSpace)

  public:
  Parent() { C_NAMESPACE_INIT(SubNS) C_NAMESPACE_INIT(OtherNameSpace) };
  ~Parent() { C_NAMESPACE_DELETE(SubNS) C_NAMESPACE_DELETE(OtherNameSpace) }
  int c() { return 123; }
};

void C_NAMESPACE_PATH(SubNS, Parent)::f()
{
  cout << "Hi, " << C_NAMESPACE_BASE(Parent)->c()  << "!" << endl;
}

void C_NAMESPACE_PATH(OtherNameSpace, Parent)::f()
{
  cout << "Hi, " << C_NAMESPACE_BASE(Parent)->c()  << "! This is other namespace :))" << endl;
}

int main ()
{
  Parent *p = new Parent();
  p->SubNS->f();
  p->OtherNameSpace->f();
}
Matrix has you...
Re[9]: И снова про ц++
От: Sheridan Россия  
Дата: 03.02.12 16:03
Оценка:
А, понял.
Актуально, если платят за размер кода, или например за количество непробельных символов
В любом случае нечитаемо при более-менее сложном коде
Matrix has you...
Re[7]: И снова про ц++
От: Cadet  
Дата: 03.02.12 16:04
Оценка:
Здравствуйте, Banned by IT, Вы писали:

XC>>При наличии методов-расширений все получится вообще элементарно. string ToStr(this int x) и т.д.


BBI>А чем не нравится конструктор string (int x)?


Мне не нравится например тем, что нужного конструктора может не быть.
... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
Re[6]: И снова про ц++
От: Mamut Швеция http://dmitriid.com
Дата: 03.02.12 16:09
Оценка:
AVL>>>массовым погромистам гораздо проще развешивать лапшу прикрываясь всякими С# 100500 / мета- / фукнциональное программирование / лямбды / монады / linq / макросы / прочая фигня. а да, виртуальные машины забыл, тоже модная тема.
M>>Выделенное — не лапша, а очень удобные инструменты. Которые — ВНЕЗАПНО — тоже появляются в С++
AVL>странно было бы, если бы человек, покусанный яблочным маркетингом, не утверждал, что вся это модная лапша не является удобной
AVL>расскажи что там внезапно появилось в плюсах (можно без лямбд, хотя кому они нужны там...), что тебя на капс пробило.

Появились лямбы, а с ними (правда, уже давно в виде обобщенного программирования) — функциональное программирование.


dmitriid.comGitHubLinkedIn
Re[8]: И снова про ц++
От: Banned by IT  
Дата: 03.02.12 16:12
Оценка:
Здравствуйте, Cadet, Вы писали:

BBI>>А чем не нравится конструктор string (int x)?


C>Мне не нравится например тем, что нужного конструктора может не быть.

А чем это отличается от того, что функции ToStr для типа int (чтоб вызывать как 10.ToStr ()) может не быть?
Если писать самому так почему не написать string ToStr (int x)?
Какой смысл вот в этом изврате с 10.ToStr () ?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[7]: И снова про ц++
От: Mamut Швеция http://dmitriid.com
Дата: 03.02.12 16:16
Оценка:
Ф>>строки должны быть единственными
BBI>Вот есть у тебя единственный формат строк. И входные/выходные данные в UTF8 и UTF32. Как с ними будешь работать? Приводить все к UTF16 а потом назад?

Да. Если все упирается только в конвертацию, можно обойтись написанием одной функции для конвертации. А не изобретать для этого очередной, ни скем не совместимый велосипед.


ЗЫ.

Помнится, писал я на Qt программку для работы с симантековской факсовой программой. Qt — это QString, факсовая программа — COM-интерфейсы с, соотсветсвенно, BSTR, или как он там называется. В общем, QString <-> BSTR без потери данных выполняется только при помощи какой-то матери (ЕМНИП, через другой промежуточный тип, возможно, через тот же std::string, а то и через что похуже).

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


dmitriid.comGitHubLinkedIn
Re[4]: namespace'ы в классах
От: Sheridan Россия  
Дата: 03.02.12 16:34
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Когда ты прекратишь слушать голоса в своей голове? То, что ты «нарисовал» — это страшный страх и ужасный ужас со всех сторон — от читаемости до поддержки в будущем


Я в тебе не сомневался, ты просто обязан был первым ответить на такое, особенно моё
Ничего тут страшного нет ни в читаемости, ни в поддержке, ибо кода в реализации кот наплакал
Matrix has you...
Re[2]: И снова про ц++
От: hattab  
Дата: 03.02.12 17:42
Оценка:
Здравствуйте, Artifact, Вы писали:

A>Однако людям, то, на самом деле нужен язык вроде Делфи, а не С++, а покупатель всегда прав. С++ слишком сложен — заявляют они. С++ не делает выбор за человека, он не направляет его в единственно правильное и возможное русло и это фактически всё.


Не хочешь ли ты сказать, что та же дельфя делает какой-то выбор, куда-то направляет?
avalon 1.0rc3 build 428, zlib 1.2.3
Re[10]: И снова про ц++
От: Sheridan Россия  
Дата: 03.02.12 20:14
Оценка:
Здравствуйте, Cadet, Вы писали:

C>Смысл именно в том, что нет нужного метода, но ты можешь написать внешнюю функцию, которая при вызове будет выглядешь как метод. К примеру:

C>
C>var fileContent = File.Read()...
C>fileContent.RemoveDuplicates().Compress().ToBase64().SendToServer();
C>


Да ладно? У строки есть метод sendtoserver? Пример крайне неудачен.
Впрочем мысль понятна. Все зависит от мощности используемой библиотеки. Кутэ приближается к описанному тобой.


C>ИМХО выглядит сильно читабельнее чем

C>
C>var fileContent = File.Read()...
C>SendToServer(ToBase64(Compress(RemoveDuplicates(fileContent))));
C>

Не вижу разницы. Одинаково понятно.
Matrix has you...
Re[5]: namespace'ы в классах
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.02.12 20:15
Оценка:
Здравствуйте, Sheridan, Вы писали:

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


S>Кстати, очень хочется увидеть реализацию пространства имен класса на эрланге.


На параметризованные модули уже смотрел?
The God is real, unless declared integer.
Re[6]: namespace'ы в классах
От: Sheridan Россия  
Дата: 03.02.12 20:17
Оценка:
Здравствуйте, netch80, Вы писали:

S>>Кстати, очень хочется увидеть реализацию пространства имен класса на эрланге.

N>На параметризованные модули уже смотрел?

Я вообще на эрланг не смотрел. Покажи код.
Matrix has you...
Re[4]: namespace'ы в классах
От: Sheridan Россия  
Дата: 03.02.12 20:20
Оценка:
Здравствуйте, Mamut, Вы писали:

Кстати, очень хочется увидеть реализацию пространства имен класса на эрланге.
Matrix has you...
Re[6]: И снова про ц++
От: koodeer  
Дата: 03.02.12 20:21
Оценка:
Здравствуйте, x-code, Вы писали:

XC>Не. У меня есть объект конкретного класса, у которого внутри сотни методов, полученных ЛЮБЫМ путем, может быть — длинная цепочка наследования, может быть все сразу объявлены, неважно. Я в IDE пишу "obj." и мне автокомплит выдает ПРОСТЫНЮ из методов, отсортированных тупо в алфавитном порядке. А я хочу, чтобы мне выдавалось около 10 внутренних неймспейсов, между которыми методы разгруппированы ПО СМЫСЛУ. Кстати, кроме иерархических неймспейсов можно ввести и "теги", правда это я еще не обдумывал.


О! Мне тоже всегда хотелось чего-то подобного. Действительно неудобно, когда автокомплит выдаёт сразу все члены класса.
Re[4]: И снова про ц++
От: hattab  
Дата: 03.02.12 20:30
Оценка:
Здравствуйте, Artifact, Вы писали:

A> H>Не хочешь ли ты сказать, что та же дельфя делает какой-то выбор, куда-то направляет?


A> Я хочу сказать, что в том же Дельфи, если вы даёте незнакомому человеку задание, вы приблизительно догадываетесь какой именно код он напишет. C++ в этом плане непредсказуем.


А нельзя примером каким нибудь пояснить, а то общие слова можно как угодно интерпретировать?
avalon 1.0rc3 build 428, zlib 1.2.3
Re[2]: И снова про ц++
От: Sheridan Россия  
Дата: 03.02.12 20:35
Оценка:
Молодой, зеленый )))
Matrix has you...
Re[12]: И снова про ц++
От: Sheridan Россия  
Дата: 03.02.12 20:36
Оценка:
Здравствуйте, Cyberax, Вы писали:

S>>Впрочем мысль понятна. Все зависит от мощности используемой библиотеки. Кутэ приближается к описанному тобой.

C>QT ограничен языком.

На чем там пример приведен? шарп? Ну так давай на шарпе мне покажи реализацю пространств имен класса.
Matrix has you...
Re[4]: И снова про ц++
От: Sheridan Россия  
Дата: 03.02.12 20:38
Оценка:
Здравствуйте, Artifact, Вы писали:

H>>Не хочешь ли ты сказать, что та же дельфя делает какой-то выбор, куда-то направляет?


A>Я хочу сказать, что в том же Дельфи, если вы даёте незнакомому человеку задание, вы приблизительно догадываетесь какой именно код он напишет.

А чего там гадать? Компонентики давно все известны. Ну разве что в другом порядке на форме разложит

A>C++ в этом плане непредсказуем.

Ну да, тут думать надо, решения принимать.
Matrix has you...
Re[7]: И снова про ц++
От: Sheridan Россия  
Дата: 03.02.12 20:39
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Появились лямбы, а с ними (правда, уже давно в виде обобщенного программирования) — функциональное программирование.


Иии... ??
Matrix has you...
Re[5]: И снова про ц++
От: Sheridan Россия  
Дата: 03.02.12 20:44
Оценка:
Здравствуйте, blackhearted, Вы писали:

B>Но дядя Линус

Вы наивно, мсье, полагаете, что это имя для меня имеет какойто вес...
Matrix has you...
Re[6]: И снова про ц++
От: hattab  
Дата: 03.02.12 20:46
Оценка:
Здравствуйте, Artifact, Вы писали:

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


H>>А нельзя примером каким нибудь пояснить, а то общие слова можно как угодно интерпретировать?


A>Тот же "Hello world!" на C++ можно написать по-крайне мере 4-мя отличающимися способами. А на других языках?


О-о-о... Аргументы что надо На дельфях это тоже можно изобразить не меньшим числом вариантов
Re[5]: И снова про ц++
От: Artifact  
Дата: 03.02.12 21:11
Оценка:
Здравствуйте, hattab, Вы писали:

H>А нельзя примером каким нибудь пояснить, а то общие слова можно как угодно интерпретировать?


Тот же "Hello world!" на C++ можно написать по-крайне мере 4-мя отличающимися способами. А на других языках?
__________________________________
Не ври себе.
Re[11]: И снова про ц++
От: okman Беларусь https://searchinform.ru/
Дата: 04.02.12 05:44
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Не вижу разницы. Одинаково понятно.


Как по мне, лучше было бы так:
var fileContent = File.Read();

fileContent.RemoveDuplicates();
fileContent.Compress();
fileContent.ToBase64();
fileContent.SendToServer();
Re[2]: И снова про ц++
От: okman Беларусь https://searchinform.ru/
Дата: 04.02.12 05:47
Оценка:
Здравствуйте, Young, Вы описывали какие-то ужасы.
Как то:

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


Y>Это же лепота — присвоил переменной значение — и уверен что ее никто уже не поменяет, вызвал функцию — и уверен, что она ни на что не повлияет.


Можете пояснить, каким боком тут всеми любимый С++ ?
Потому что к описанным проблемам язык программирования имеет очень посредственное отношение.

Y>А ц++, что — каждый чих потенциально может изменить логику программы в любом месте.


Для этого давно придумали разделение ответственности и инкапсуляцию.
Re[8]: И снова про ц++
От: okman Беларусь https://searchinform.ru/
Дата: 04.02.12 06:04
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Попроси что бы ктото убил тебя. Понавыбираете а потом интеграция превращается в переписывание.


Бедненький.
Как же тебе тяжело с нами.
Re[11]: И снова про ц++
От: Cadet  
Дата: 04.02.12 06:08
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Да ладно? У строки есть метод sendtoserver? Пример крайне неудачен.

Ну дык вылазь в реальный мир из своих грез. Такой код вполне реальность не в плюсах. И в плюсах мог бы быть реальностью.

S>Не вижу разницы. Одинаково понятно.

Ага, в плюсах этого нет, значит этого не надо . А вообще забавно смотреть, как плюсовики, ранее кричавшие про ненужность var в шарпе к примеру, резко полюбили auto с выходом С++ 11. Это же не var, это auto, разница огромна .
... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
Re[8]: И снова про ц++
От: Sheridan Россия  
Дата: 04.02.12 06:09
Оценка:
А с каких это пор мощность и универсальность языка ВНЕЗАПНО стала недостатком?
Matrix has you...
Re[4]: И снова про ц++
От: okman Беларусь https://searchinform.ru/
Дата: 04.02.12 10:34
Оценка:
Здравствуйте, Young, Вы писали:

O>>Можете пояснить, каким боком тут всеми любимый С++ ?

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

Y>Не понял.... Собственно речь как раз и идет о том, что язык должен обеспечивать невозможность сайд-эффектов.


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

Y>>>А ц++, что — каждый чих потенциально может изменить логику программы в любом месте.


O>>Для этого давно придумали разделение ответственности и инкапсуляцию.


Y>О! А как ответственность и инкапсуляция поможет мне при использовании сторонней функции которая тупо гадит в память?


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

Y>В ц++ вызов любой функция может потенциально иметь сайд-эффекты на все остальные данные.


bool is_local_address(IP_ADDRESS Address)
{
    if ( (Address == "127.0.0.1") || (Address == "localhost") )
    {
        return true;
    }

    return false;
}

Ну покажите, как вот эта функция будет вызывать сайд-эффекты на все остальные данные.
Re[12]: И снова про ц++
От: Sheridan Россия  
Дата: 04.02.12 10:51
Оценка:
Здравствуйте, Cadet, Вы писали:

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


S>>Да ладно? У строки есть метод sendtoserver? Пример крайне неудачен.

C>Ну дык вылазь в реальный мир из своих грез. Такой код вполне реальность не в плюсах. И в плюсах мог бы быть реальностью.
Да дело в том, что сущности путать не надо. Читается как Яблоко().ПромытьФорсунки()

S>>Не вижу разницы. Одинаково понятно.

C>Ага, в плюсах этого нет, значит этого не надо .
Чего нет? Я кажется показал уже как нэймспейсов класса в плюсах нет. Немного коряво в силу моей неопытности, конечно, но работает.
Дело в руках и голове, а не в языке.

C>А вообще забавно смотреть, как плюсовики, ранее кричавшие про ненужность var в шарпе к примеру, резко полюбили auto с выходом С++ 11. Это же не var, это auto, разница огромна .

Ну улучшили они с помощью auto читаемость кода. Дальше что? Смысл какой? В чем профит? Ведь можжно обойтись и typedef'ом, если громоздко получается объявить переменную.

Ты не на это смотри. Реально вкусное не тут а
std::vector<std::pair<int, std::string>> container;

// ...

for (const auto& i : container)
    std::cout << i.second << std::endl;

То есть range-based циклы, которые пришли на замену std::for_each
Matrix has you...
Re[12]: И снова про ц++
От: Sheridan Россия  
Дата: 04.02.12 11:06
Оценка:
Здравствуйте, okman, Вы писали:

O>Как по мне, лучше было бы так:

O>
O>fileContent.SendToServer();
O>


Яблоко().ПромытьФорсунки()
Я бы переписал так:

QFile file("filename");
ClientConnection.sendToServer(file.readAll().RemoveDuplicates().Compress().ToBase64());


А если уж совсем переводить на кутэ, то получится чуть по другому. Я не уверен в наличии метода удаления дубликатов — его видимо придется реализовывать. Но без него так:
QFile file("filename");
ServerConnection.send(qCompress(file.readAll()).toBase64());

И опять же, ничего не мешает унаследоваться, реализовать нужные методы и перевести на кутэ первоначальный вариант. По большому счету надо всего лишь унаследоваться от qbytearray и "реализовать" там compress.
Но опять же, на вкус и цвет. Мне без разницы как будет написано. Хоть через точку, хоть вложенные вызовы методов. Дело в том, что я когдато давно учился и знаю порядок выполнения кода, и поэтому способен его читать. Очевидно, что некоторые тут просто код читать не умеют. А может и умеют, но ленятся. В любом случае к языку это не относится, ибо на ц++ можно и так и так написать.
Matrix has you...
Re[3]: И снова про ц++
От: Ops Россия  
Дата: 04.02.12 12:27
Оценка:
Здравствуйте, trop, Вы писали:

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

IP>>С++ как высшая математика, не каждый его понимает и не каждому она доступна по умственному потенциалу, но с помощью него делаются реальные вещи.

T>тем не менее в серъезных областях его испольщуют минимаьлно или не используют

T>например в nasa запрет на c++ на любых аппаратах, то же самое в военной авионике,
T>в системах наведения ,робототехнике. ьам только с

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

T>напротив, lisp использовался по крайней мере на одном космическом аппарате, в виде модуля отладки

аргумент.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[9]: И снова про ц++
От: ambel-vlad Беларусь  
Дата: 04.02.12 13:03
Оценка:
Здравствуйте, okman, Вы писали:

I>>Попроси что бы ктото убил тебя. Понавыбираете а потом интеграция превращается в переписывание.


O>Бедненький.

O>Как же тебе тяжело с нами.

Не беспокойся, у него это перманентное состояние.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[10]: И снова про ц++
От: ambel-vlad Беларусь  
Дата: 04.02.12 13:44
Оценка:
Здравствуйте, Философ, Вы писали:

Ф>>>ржал аки конь


O>>Расскажи, что смешного — я тоже поржать люблю.


Ф>struct StringStruct

Ф>{
Ф>System.Int32 size;
Ф>System.IntPtr dataPointer;
Ф>System.IntPtr vtable;
Ф>}

Ф>StringStruct *str1;

Ф>sizeof(str1) + sizeof(StringStruct) == 16 байт

Ф>Фантастический оверхэд у вас!

Ф>целых 24 байта против самых минимальных 16

28 vs 16. И это на одном объекте. А если их значительно больше?
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[10]: И снова про ц++
От: Ops Россия  
Дата: 04.02.12 14:39
Оценка:
Здравствуйте, Философ, Вы писали:

Ф>>>ржал аки конь


O>>Расскажи, что смешного — я тоже поржать люблю.


Ф>struct StringStruct

Ф>{
Ф>System.Int32 size;
Ф>System.IntPtr dataPointer;
Ф>System.IntPtr vtable;
Ф>}

Ф>StringStruct *str1;

Ф>sizeof(str1) + sizeof(StringStruct) == 16 байт

Ф>Фантастический оверхэд у вас!

Ф>целых 24 байта против самых минимальных 16

Ну, во-первых, vtable там нет, если бы меньше философствовали, а познакомились с предметом, Вы бы это знали.
Во-вторых большинство реализаций std::string выглядят как-то так:
class string
{
  static const size_t magic = 16;
  char buf_[magic];
  size_t size_;
  char * data_;
}

При такой реализации не требуются лишние аллокации при работе с короткими строками, что очень ускоряет работу.
Кстати, при magic = 16 и 32-битной платформе получаем как раз 24 байта. Но все это сильно зависит от реализации, существуют и с большими буферами, и вообще без них.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[3]: И снова про ц++
От: FR  
Дата: 04.02.12 14:42
Оценка:
Здравствуйте, D.Lans, Вы писали:

DL>А какой есть аналог у C++?


http://www.d-programming-language.org/index.html
Re[12]: И снова про ц++
От: FR  
Дата: 04.02.12 14:51
Оценка:
Здравствуйте, Cadet, Вы писали:

S>>Не вижу разницы. Одинаково понятно.

C>Ага, в плюсах этого нет, значит этого не надо . А вообще забавно смотреть, как плюсовики, ранее кричавшие про ненужность var в шарпе к примеру, резко полюбили auto с выходом С++ 11. Это же не var, это auto, разница огромна .

Шарперы однако также весьма резко полюбили var когда он внезапно появился, а до этого на всякие let, where или def также морщили носы
Re[4]: И снова про ц++
От: FR  
Дата: 04.02.12 14:53
Оценка:
Здравствуйте, Young, Вы писали:


Y>Не понял.... Собственно речь как раз и идет о том, что язык должен обеспечивать невозможность сайд-эффектов.


То есть пишем только на сильно ограниченном подмножестве Хаскеля?
Re[9]: И снова про ц++
От: Artifact  
Дата: 04.02.12 15:10
Оценка:
Здравствуйте, hattab, Вы писали:

H>Делать так, разумеется, никто не станет, хотя это возможно.

Иненно об этом и речь, что не станет. Задумывались почему? Почему в других языках люди не стараются "удивить мир", а делают так, чтобы библиотека, которою они написали, максимально вписывалась в общую среду, выглядела как что-то привычное?

H>Это есть в любом языке с длинной историей.

Вы правы, конечно. Просто С++, в отличии от других, с этого начал. Это было в нём с самого начала.

H>И на дельфях народ пишет очень поразному. Кто-то пользуется рудиментарными Objects и строят на ни целые библиотеки (KOL тому пример). Кто-то использует только процедурное программирование, кто-то использует смесь из процедурного с объектно ориентированным. Кто-то пользуется файловыми потоками, кто-то функциями RTL для чтения файлов. О каком единстве можно говорить

О внешнем единстве. Разного рода WTF??? — у меня проскакивает, только когда я читаю С++ -ный код. Типа какого чёрта везде были классы и вдруг передача через указатель на void.

H>Ну это вообще не правда. Уж в чем в чем, а в правилах форматирования кода единства нет нигде, кроме случаев, когда оные определяются сверху.

Пишу о том, что вижу. Я не говорю о том, чтом в том же Дельфи нельзя тип полностью написать в верхнем регистре, я утверждаю, что так никто не делает.
__________________________________
Не ври себе.
Re[9]: И снова про ц++
От: Artifact  
Дата: 04.02.12 15:20
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>А с каких это пор мощность и универсальность языка ВНЕЗАПНО стала недостатком?


Просто, зная способности среднестатистических разработчиков, мне бы хотелось, чтобы они не увлекались мощью языка.
__________________________________
Не ври себе.
Re[5]: И снова про ц++
От: Young yunoshev.ru
Дата: 04.02.12 15:35
Оценка:
Здравствуйте, okman, Вы писали:

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


O>>>Можете пояснить, каким боком тут всеми любимый С++ ?

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

Y>>Не понял.... Собственно речь как раз и идет о том, что язык должен обеспечивать невозможность сайд-эффектов.


O>Тогда это не язык получится, а излишне заботливая нянька.

O>В нем все наиболее мощные возможности затолкают под капот, чтобы несчастные адепты не
O>отстрелили себе что-нибудь по неосторожности.

А какие возможности вам нужны — из тех которые наиболее часто вызывают сайд эффекты?


Возможность записать за пределы массива?
Возможность попортить стек?
Или вообще возможность писать в произвольное место памяти?


Y>>>>А ц++, что — каждый чих потенциально может изменить логику программы в любом месте.


O>>>Для этого давно придумали разделение ответственности и инкапсуляцию.


Y>>О! А как ответственность и инкапсуляция поможет мне при использовании сторонней функции которая тупо гадит в память?


O>А как в этом борются в других языках ? Там что — нельзя получить противоречивое состояние объекта или

O>выйти за пределы массива ?

А зачем нам получать противоречивое состояние объекта? Нет нельзя. Более того — даже изменить состояние переменной нельзя — она переменная в математическом смысле.

O>Или нельзя налепить глобальных переменных или механизмов, втягивающих в

O>зависимость внешние сборки ? Правильно, от этих вещей отказываются, зависимости стараются уменьшить,
O>"черновую" работу инкапсулировать в компоненты и подсистемы. Поэтому ошибка, в хоть сколько-нибудь
O>нормально спроектированных системах, часто имеет только локальные эффекты, и, как следствие,
O>большая часть таких ошибок относительно легко находятся и исправляются.

Все верно — у языка есть ряд вещей от которых избавляютя искуственным путем. Самый древний пример пожалуй с goto будет.

Y>>В ц++ вызов любой функция может потенциально иметь сайд-эффекты на все остальные данные.


O>
O>bool is_local_address(IP_ADDRESS Address)
O>{
O>    if ( (Address == "127.0.0.1") || (Address == "localhost") )
O>    {
O>        return true;
O>    }

O>    return false;
O>}
O>

O>Ну покажите, как вот эта функция будет вызывать сайд-эффекты на все остальные данные.

Во первых находим слово потенциально в моем утверждении. А во вторых — а как можно утверждать что у функции нету сайд эффекта — ничего не зная например о том как у IP_ADDRESS определен оператор сравнения?
Re[11]: И снова про ц++
От: Философ Ад http://vk.com/id10256428
Дата: 04.02.12 16:15
Оценка:
Здравствуйте, Ops, Вы писали:
Ops>Ну, во-первых, vtable там нет, если бы меньше философствовали, а познакомились с предметом, Вы бы это знали.

нуууууууууууууу во-первых я не писал что он там есть
были бы виртуальные функции — был бы и vtable


ЗЫ: кстати, , если вам так не нравится vtable, можете его убрать class __declspec(novtable)...
тогда ваши программы будут есть меньше памяти
Всё сказанное выше — личное мнение, если не указано обратное.
Re[6]: И снова про ц++
От: Sheridan Россия  
Дата: 04.02.12 16:32
Оценка:
Здравствуйте, jazzer, Вы писали:

S>>Дело в том, что ц++ переживет и земноводных и немерле с хаскелями, как уже пережил вижуалбэйсик например.

J>Ну так и лисп с фортраном успешно всех переживают, и даже кобол, прости господи
Возможно. Только ц++ всетаки популярнее...
Matrix has you...
Re[10]: И снова про ц++
От: okman Беларусь https://searchinform.ru/
Дата: 04.02.12 16:50
Оценка:
Здравствуйте, Философ, Вы писали:

Ф>Фантастический оверхэд у вас!

Ф>целых 24 байта против самых минимальных 16

Это не оверхед, это Small String Optimization.
Re[13]: И снова про ц++
От: Cyberax Марс  
Дата: 04.02.12 18:36
Оценка:
Здравствуйте, okman, Вы писали:

S>>>Да ладно? У строки есть метод sendtoserver? Пример крайне неудачен.

C>>Нет, есть extension-метод SendToServer.
O>Ну вот если вдуматься, такой метод у строки (пусть и extension) — это нормально ?
Для строки — слишком, но в целом полезно.

O>А если SendToServer занимает продолжительное время и ее надо будет использовать асинхронно ?

O>Что дальше — лепим туда еще и мьютекс, рабочий поток, нотификаторы и механизм отмены ?
А какая разница? То же самое будет, если используется helper-метод SendToServer.
Sapienti sat!
Re[6]: И снова про ц++
От: okman Беларусь https://searchinform.ru/
Дата: 04.02.12 18:46
Оценка:
Здравствуйте, Young, Вы писали:

Y>А какие возможности вам нужны — из тех которые наиболее часто вызывают сайд эффекты?


Y>Возможность записать за пределы массива?


Нет. Но отключить проверку выхода за пределы массива — да.

Y>Возможность попортить стек?


Нет. Но отключить проверку порчи стека — да.

Y>Или вообще возможность писать в произвольное место памяти?


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

Y>А зачем нам получать противоречивое состояние объекта? Нет нельзя. Более того — даже изменить состояние переменной нельзя — она переменная в математическом смысле.


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

Y>Все верно — у языка есть ряд вещей от которых избавляютя искуственным путем.

Y>Самый древний пример пожалуй с goto будет.

Да, goto. А еще break, continue, вложенные на много уровней if-else, невнятное
именование, злоупотребление наследованием, отсутствие инкапсуляции, дублирование и
многое другое — все это есть во многих языках, не только в C++.

Y>Во первых находим слово потенциально в моем утверждении.


Ок, погорячился.

Y>А во вторых — а как можно утверждать что у функции нету сайд эффекта — ничего не зная например о том как у IP_ADDRESS определен оператор сравнения?


Каким боком тут C++ ? Этот код мог быть на любом языке. И тоже бы имел
обозначенные Вами "сайд-эффекты".
Re[14]: И снова про ц++
От: okman Беларусь https://searchinform.ru/
Дата: 04.02.12 18:48
Оценка:
Здравствуйте, Cyberax, Вы писали:

O>>А если SendToServer занимает продолжительное время и ее надо будет использовать асинхронно ?

O>>Что дальше — лепим туда еще и мьютекс, рабочий поток, нотификаторы и механизм отмены ?
C>А какая разница? То же самое будет, если используется helper-метод SendToServer.

Да не, я о том, что данный функционал логичнее вынести в отдельную сущность, — какой-нибудь
Sender, — а не связывать его с классом строки.
Re[4]: И снова про ц++
От: okman Беларусь https://searchinform.ru/
Дата: 04.02.12 18:56
Оценка:
Здравствуйте, Young, Вы писали:

Y>Собственно речь как раз и идет о том, что язык должен обеспечивать невозможность сайд-эффектов.


Вот давайте порассуждаем над этим тезисом.
Итак, есть массив. Все согласны, что выход за границы массива — зло ? Ок.

Теперь предположим, что мы пишем некий алгоритм и точно знаем, что выход за границы
массива невозможен. Например, в этот массив попадают только символы английского алфавита.
Их 26. Вопрос — зачем нам лишние проверки на предмет выхода за его границы, если у нас
это условие обеспечивается корректностью самого алгоритма (да еще набором юнит-тестов в
придачу) ? В C++ такие проверки обычно не мешают, но в ряде случаев они становятся причиной
ухудшения производительности. И именно по этой причине массивы в C и C++ реализованы
наиболее близким и естественным для платформы способом — как последовательность ячеек памяти,
и никаких size(), capacity() и проверок индекса при попытке чтения-записи.
Кому надо — берет std::vector. Короче, в описанном примере сайд-эффектом как раз
является не выход за пределы массива, а лишние проверки, плохо влияющие на перфоманс.
Re[10]: И снова про ц++
От: okman Беларусь https://searchinform.ru/
Дата: 04.02.12 19:07
Оценка:
Здравствуйте, Философ, Вы писали:

Ф>Фантастический оверхэд у вас!

Ф>целых 24 байта против самых минимальных 16

У нас разные есть строки. Есть быстрые, есть маленькие, есть те, которые
можно передавать COM-объектам и прочие. Можно написать класс строки, объекты
которого будут занимать места не больше, чем указатель. Но тогда, к примеру,
придется каждый раз проходить по строке при вызове метода get_length.
Короче, оверхед — он разный бывает, где-то по производительности, где-то по памяти.
Re[10]: И снова про ц++
От: hattab  
Дата: 04.02.12 19:37
Оценка:
Здравствуйте, Artifact, Вы писали:

A> Иненно об этом и речь, что не станет. Задумывались почему?


Тут не о чем задумываться, в дельфийском варианте запись будет выглядеть крайне нелепо: Console Shl 'Hello, world!';

A> Почему в других языках люди не стараются "удивить мир", а делают так, чтобы библиотека, которою они написали, максимально вписывалась в общую среду, выглядела как что-то привычное?


Да нигде мир удивить не пытаются. Если пишется библиотека, всегда стараются придерживаться единого стиля хотя бы в рамках этой библиотеки. Ну а когда код пишется "для себя", тут уже все возможно.

A> Вы правы, конечно. Просто С++, в отличии от других, с этого начал. Это было в нём с самого начала.


В дельфях, чтоль, по другому? Вообще, в любом языке допускающем смешивание стилей и парадигм они будут смешаны.

A> О внешнем единстве. Разного рода WTF??? — у меня проскакивает, только когда я читаю С++ -ный код. Типа какого чёрта везде были классы и вдруг передача через указатель на void.


Мне кажется, ты излишне демонизируешь плюсы Качество кода зависит в первую очередь от программиста, а не от языка.

A> Пишу о том, что вижу. Я не говорю о том, чтом в том же Дельфи нельзя тип полностью написать в верхнем регистре, я утверждаю, что так никто не делает.


Делают еще и не так Имена типов в верхнем регистре? Да сколько угодно. Вообще все зарезервированные слова, бывает, пишут капсом. Некоторые, например, обрамляют одиночную строку составным оператором, а некоторые нет. Некоторые всегда начинают составной оператор с новой строки, а некоторые нет. Некоторые для освобождения объекта используют FreeAndNil, а некоторые просто Free. Некоторые используют групповое декларирование типа переменных, а некоторые нет. А уж про размер отступа я вообще молчу. Посмотрим на жабу. Сейчас заглянул в два разных жабьих исходника: в одном скобки отделяются пробелами — в другом нет, в одном фигурная скобка всегда на новой строке, в другом наоборот.
avalon 1.0rc3 build 428, zlib 1.2.3
Re[3]: И снова про ц++
От: hattab  
Дата: 04.02.12 19:37
Оценка:
Здравствуйте, D.Lans, Вы писали:

DL> А какой есть аналог у C++?


Pascal, yep!
avalon 1.0rc3 build 428, zlib 1.2.3
Re[5]: namespace'ы в классах
От: Mamut Швеция http://dmitriid.com
Дата: 04.02.12 19:40
Оценка:
S>Кстати, очень хочется увидеть реализацию пространства имен класса на эрланге.

В Erlang'е нет такого понятия, как класс.


dmitriid.comGitHubLinkedIn
Re[5]: namespace'ы в классах
От: Mamut Швеция http://dmitriid.com
Дата: 04.02.12 19:52
Оценка:
M>>Когда ты прекратишь слушать голоса в своей голове? То, что ты «нарисовал» — это страшный страх и ужасный ужас со всех сторон — от читаемости до поддержки в будущем

S>Я в тебе не сомневался, ты просто обязан был первым ответить на такое, особенно моё

S>Ничего тут страшного нет ни в читаемости, ни в поддержке, ибо кода в реализации кот наплакал

Ты хоть раз участвовал в проектах, в которых был больше, чем один программист, и как долго?


dmitriid.comGitHubLinkedIn
Re[11]: И снова про ц++
От: Artifact  
Дата: 04.02.12 20:34
Оценка:
Здравствуйте, hattab, Вы писали:

H>Да нигде мир удивить не пытаются. Если пишется библиотека, всегда стараются придерживаться единого стиля хотя бы в рамках этой библиотеки. Ну а когда код пишется "для себя", тут уже все возможно.

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

H>В дельфях, чтоль, по другому? Вообще, в любом языке допускающем смешивание стилей и парадигм они будут смешаны.

У Дельфи, образно говоря, география сужена до одной конторы. У плюсов различия начинаются уже с лёгкой руки разработчиков компиляторов. Правда это впоследствии привело к появлению стандарта, что исправило положение, но всё же ещё продолжает иметь место быть.

H>Мне кажется, ты излишне демонизируешь плюсы Качество кода зависит в первую очередь от программиста, а не от языка.

Во многих других языках компилятор вам просто не даст вам "выстрелить себе в ногу". В плюсах, как нигде, можно послать компилятор нафиг.

H>Делают еще и не так Имена типов в верхнем регистре? Да сколько угодно. Вообще все зарезервированные слова, бывает, пишут капсом. Некоторые, например, обрамляют одиночную строку составным оператором, а некоторые нет. Некоторые всегда начинают составной оператор с новой строки, а некоторые нет. Некоторые для освобождения объекта используют FreeAndNil, а некоторые просто Free. Некоторые используют групповое декларирование типа переменных, а некоторые нет.

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

H>А уж про размер отступа я вообще молчу. Посмотрим на жабу. Сейчас заглянул в два разных жабьих исходника: в одном скобки отделяются пробелами — в другом нет, в одном фигурная скобка всегда на новой строке, в другом наоборот.

Странно. Такое я видел, только когда проект на Джаве писали бывшие С++ программисты (кроме шуток).
__________________________________
Не ври себе.
Re[3]: И снова про ц++
От: Ночной Смотрящий Россия  
Дата: 04.02.12 21:08
Оценка:
Здравствуйте, netch80, Вы писали:

N>Если речь про схему в стиле Вирта


Думаю, речь про модульность, а не про "схему в стиле Вирта". Которая присутствует и в джаве и в дотнете.

N>Зато подход с заголовочными описаниями распространяется практически на все языки.


"Все языки" это С++ что ли?

XC>>Отсутствие методов-расширений, отсутствие возможности обращаться к методу класса как к статическому с явной (ручной) передачей this


N>Что такое методы-расширения я не понял.


Это синтаксический сахар для вызова статических методов (и, видимо, свободных функций в случае С++)

N>Вызов метода как статического — а зачем?


Нет — вызов статического метода. Автоматическая замена такого выражения:
X.A(Y.B(Z.C()))

На такое:
X.A().B().C();

Весьма помогает в ряде сценариев, например при использовании всяких монадных штук.

XC>>Отсутствие системы сообщений как в ObjectiveC, встроенной системы сигналов и слотов как в QT


N>Не вижу, почему это недостаток. Такие системы сообщений весьма специфичны для задачи и общая реализация на все случаи не имеет смысла, а для конкретной — есть библиотеки.


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

XC>>Отсутсвие вложенных функций (даже в турбо паскале вроде были),


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


Но очень удобно.

XC>> а лямбды в C++11 на редкость кривые

XC>>Отсутствие замыканий,
N>Вот для замыканий неплохо бы было увидеть библиотеку в стиле boost, но для C.
N>Чтобы умела хотя бы для основных платформ генерировать замыкания.

Без поддержки со стороны языка это будет очередной уродец.

XC>>Отсутствие опциональной возможности структуной типизации

N>?

Это, видимо, утиная типизация имеется в виду.

XC>>Отсутствие полноценной рефлексии и атрибутов (как в C#)


N>Это очень дорого


С чего ты взял?

N> и смысл сомнителен.


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

XC>>Отсутствие встроенной параллельности и каналов (как в Go)

N>Это возлагается на библиотеки.

Но поддержка со стороны языка была бы весьма пользительна. Хотя бы в виде шарповских async/await.
Re[13]: И снова про ц++
От: Cadet  
Дата: 04.02.12 21:10
Оценка:
Здравствуйте, okman, Вы писали:

O>Ну вот если вдуматься, такой метод у строки (пусть и extension) — это нормально ?

O>По-моему, это пример плохо продуманного дизайна.
O>А если SendToServer занимает продолжительное время и ее надо будет использовать асинхронно ?
O>Что дальше — лепим туда еще и мьютекс, рабочий поток, нотификаторы и механизм отмены ?

Тебе по сути экстеншн методов есть что сказать, или будем придираться к примеру?
... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
Re[3]: И снова про ц++
От: Ночной Смотрящий Россия  
Дата: 04.02.12 21:19
Оценка:
Здравствуйте, jazzer, Вы писали:

XC>>Отсутсвие вложенных функций (даже в турбо паскале вроде были), а лямбды в C++11 на редкость кривые

J>в чем кривость лямбд по сравнению с локальными функциями?

Продемонстрируй рекурсию на лямбдах.
Re[6]: namespace'ы в классах
От: Sheridan Россия  
Дата: 04.02.12 22:05
Оценка:
Здравствуйте, Mamut, Вы писали:

S>>Кстати, очень хочется увидеть реализацию пространства имен класса на эрланге.


M>В Erlang'е нет такого понятия, как класс.


Ужас! Кошмар!! Жуть!!! Вы все умрете!!!! Завтра!!!!!

Matrix has you...
Re[6]: namespace'ы в классах
От: Sheridan Россия  
Дата: 04.02.12 22:05
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Ты хоть раз участвовал в проектах, в которых был больше, чем один программист, и как долго?

Какой раз ты у меня это спрашиваешь и зачем спросил в этот раз?
Matrix has you...
Re[7]: namespace'ы в классах
От: Mamut Швеция http://dmitriid.com
Дата: 04.02.12 22:13
Оценка:
M>>Ты хоть раз участвовал в проектах, в которых был больше, чем один программист, и как долго?
S>Какой раз ты у меня это спрашиваешь и зачем спросил в этот раз?

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


dmitriid.comGitHubLinkedIn
Re[7]: namespace'ы в классах
От: Mamut Швеция http://dmitriid.com
Дата: 04.02.12 22:14
Оценка:
S>>>Кстати, очень хочется увидеть реализацию пространства имен класса на эрланге.

M>>В Erlang'е нет такого понятия, как класс.


S>Ужас! Кошмар!! Жуть!!! Вы все умрете!!!! Завтра!!!!!


S>


Ну и к чему эти вопли?


dmitriid.comGitHubLinkedIn
Re[8]: namespace'ы в классах
От: Mamut Швеция http://dmitriid.com
Дата: 04.02.12 22:22
Оценка:
M>>>Ты хоть раз участвовал в проектах, в которых был больше, чем один программист, и как долго?

C>>Помнится участвовал в Авалоне, был быстро с треском изгнан . Из-за стиля работы "пишу как хочу и класть мне на остальную команду".

S>Я привел ту зловонную свалку в порядок. Но этисамые к грязи привыкли. И не захотели жить в чистоте. Я на них не обижаюсь, такие сущности, что поделаешь. Доступ к репозиторию у меня емнип не забрали, перенесли мой код в отдельную ветку, развели грязь обратно. Их право.

Все было совсем наоборот. Потому что реальность всегда оказывается не такой, как тебе нашептывают голоса из космоса:
http://rsdn.ru/forum/janus/4192629.aspx
Автор: Sheridan
Дата: 13.03.11

http://rsdn.ru/forum/janus/3871764.1.aspx
Автор: Anton Batenev
Дата: 09.07.10

http://rsdn.ru/forum/janus/3486538.aspx
Автор: cencio
Дата: 30.07.09


Но да, д'Артаньян у нас только и исключительно ты, ага


dmitriid.comGitHubLinkedIn
Re[8]: namespace'ы в классах
От: Sheridan Россия  
Дата: 04.02.12 23:00
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Чтобы ты наконец-то перестал слушать голоса в своей голове и один раз послушал, что тебе говорят люди, у которых есть опыт работы в команде.

Никак не могу понять как связан опыт работы в команде и возможности языка.
Matrix has you...
Re[8]: namespace'ы в классах
От: Sheridan Россия  
Дата: 04.02.12 23:01
Оценка:
Здравствуйте, Mamut, Вы писали:

M>>>В Erlang'е нет такого понятия, как класс.

S>>Ужас! Кошмар!! Жуть!!! Вы все умрете!!!! Завтра!!!!!
M>Ну и к чему эти вопли?

К тому, что в сторону ц++ высказываются в похожем стиле.
Matrix has you...
Re[9]: namespace'ы в классах
От: Mamut Швеция http://dmitriid.com
Дата: 04.02.12 23:02
Оценка:
M>>Чтобы ты наконец-то перестал слушать голоса в своей голове и один раз послушал, что тебе говорят люди, у которых есть опыт работы в команде.
S>Никак не могу понять как связан опыт работы в команде и возможности языка.

Напрямую. Цитирую себя еще раз:

То, что ты «нарисовал» — это страшный страх и ужасный ужас со всех сторон — от читаемости до поддержки в будущем


Именно с точки зрения, в том числе, и разработки в команде. + Cadet написал
Автор: Cadet
Дата: 03.02.12


dmitriid.comGitHubLinkedIn
Re[9]: namespace'ы в классах
От: Mamut Швеция http://dmitriid.com
Дата: 04.02.12 23:03
Оценка:
M>>>>В Erlang'е нет такого понятия, как класс.
S>>>Ужас! Кошмар!! Жуть!!! Вы все умрете!!!! Завтра!!!!!
M>>Ну и к чему эти вопли?

S>К тому, что в сторону ц++ высказываются в похожем стиле.


Ну, если ты неспособен понять, что тебе пишут, то да, конечно, именно так и высказываются


dmitriid.comGitHubLinkedIn
Re[9]: namespace'ы в классах
От: Sheridan Россия  
Дата: 04.02.12 23:05
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Но да, д'Артаньян у нас только и исключительно ты, ага

А ты сам бы сравнил то что было (и к чему вернулись) с тем что я сделал. Работу проделал огромную, вдобавок прикрутил логгер, изменяемые меню, нормальные иконки. На все это практически наплевали.
Matrix has you...
Re[10]: namespace'ы в классах
От: Sheridan Россия  
Дата: 04.02.12 23:09
Оценка:
Здравствуйте, Mamut, Вы писали:

M>

M> То, что ты «нарисовал» — это страшный страх и ужасный ужас со всех сторон — от читаемости до поддержки в будущем

M>Именно с точки зрения, в том числе, и разработки в команде. + Cadet написал
Автор: Cadet
Дата: 03.02.12


Отлично читается и не вижу проблем в поддержке отлаженного однажды кода. Может у вас нет опыта работы с подобным? Ну так это не мои проблемы.
Matrix has you...
Re[10]: namespace'ы в классах
От: Sheridan Россия  
Дата: 04.02.12 23:10
Оценка:
Здравствуйте, Mamut, Вы писали:

S>>К тому, что в сторону ц++ высказываются в похожем стиле.

M>Ну, если ты неспособен понять, что тебе пишут, то да, конечно, именно так и высказываются

До сих пор никто не смог повторить на других языках реализацию нэймспейсов в классах. Да, конечно, мне не понять, ага.
Matrix has you...
Re[11]: namespace'ы в классах
От: Mamut Швеция http://dmitriid.com
Дата: 04.02.12 23:12
Оценка:
M>>

M>> То, что ты «нарисовал» — это страшный страх и ужасный ужас со всех сторон — от читаемости до поддержки в будущем

M>>Именно с точки зрения, в том числе, и разработки в команде. + Cadet написал
Автор: Cadet
Дата: 03.02.12


S>Отлично читается и не вижу проблем в поддержке отлаженного однажды кода. Может у вас нет опыта работы с подобным? Ну так это не мои проблемы.


К выделенному, повторю вопрос:

Ты хоть раз участвовал в проектах, в которых был больше, чем один программист, и как долго?



dmitriid.comGitHubLinkedIn
Re[11]: namespace'ы в классах
От: Mamut Швеция http://dmitriid.com
Дата: 04.02.12 23:15
Оценка:
S>>>К тому, что в сторону ц++ высказываются в похожем стиле.
M>>Ну, если ты неспособен понять, что тебе пишут, то да, конечно, именно так и высказываются

S>До сих пор никто не смог повторить на других языках реализацию нэймспейсов в классах. Да, конечно, мне не понять, ага.


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


dmitriid.comGitHubLinkedIn
Re[11]: namespace'ы в классах
От: Sheridan Россия  
Дата: 04.02.12 23:24
Оценка:
Здравствуйте, Mamut, Вы писали:

M>В итоге:

M>- ты не согласовал свои изменения с другими членами команды
Так вот почему разработка всегда затягивается — бюрократия везде, ага.

M>- вместо инекрементальных изменений ты все вывалил в кучу одним скопом, который невозможно смерджить в основную ветку без лома и такой-то матери

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

M>- попутно ты поломал ключевой функционал и отказался его чинить

Не лги. Починил. http://www.rsdn.ru/forum/janus/3488009.1.aspx
Автор: Sheridan
Дата: 31.07.09

А вот ты помогать отказывался
Автор: Mamut
Дата: 24.08.09
.
Matrix has you...
Re[12]: namespace'ы в классах
От: Sheridan Россия  
Дата: 04.02.12 23:28
Оценка:
Здравствуйте, Mamut, Вы писали:

S>>Отлично читается и не вижу проблем в поддержке отлаженного однажды кода. Может у вас нет опыта работы с подобным? Ну так это не мои проблемы.


M>К выделенному, повторю вопрос:

M>

M>Ты хоть раз участвовал в проектах, в которых был больше, чем один программист, и как долго?

Пойдем по кругу? Ну раз хочешь — давай.
Никак не могу понять как связан опыт работы в команде и возможности языка.
Могу добавить только еще вот что: если у тебя или у кого то еще возникают трудности с прочтением такого кода — то это лишь говорит о вашем малом опыте работы с таким кодом, только и всего. Отсюда вывод: вы не используете целиком возможности языка, предпочитая его ругать и поносить. Позиция ваша вполне ясна: "мне лень".
Matrix has you...
Re[12]: namespace'ы в классах
От: Sheridan Россия  
Дата: 04.02.12 23:31
Оценка:
Здравствуйте, Mamut, Вы писали:

S>>До сих пор никто не смог повторить на других языках реализацию нэймспейсов в классах. Да, конечно, мне не понять, ага.

M>До твоего ровного, не испоганеного присутсвием извилин мозга не доходит тот простейший факт, что в других языках это может быть нафиг не нужно.
Я не вижу особой необходимости этого и в ц++. Но как бы отсутствие такой возможности вменяли в минус ц++, поэтому я на этом примере наглядно показал, что язык гибок и вместо того чтобы хныкать об отсутствии фичи надо бы ее просто реализовать. Но нет же: "мне лень". Ругать — проще.
Matrix has you...
Re[6]: namespace'ы в классах
От: Sheridan Россия  
Дата: 04.02.12 23:33
Оценка:
Здравствуйте, Cadet, Вы писали:

C>Да в данном месте наплакал конечно. А в реальном проекте, с исходниками мегабайт ну скажем 5, один так наплакал в одном месте, другой в другом, третий в третьем. А потом ты рыдаешь, когда продираешься через это в поисках ошибки.

То есть ты предлагаешь не использовать целый огромный пласт возможностей языка, ссылаясь на лень? Ну-ну...
Matrix has you...
Re[13]: namespace'ы в классах
От: Mamut Швеция http://dmitriid.com
Дата: 04.02.12 23:52
Оценка:
S>>>До сих пор никто не смог повторить на других языках реализацию нэймспейсов в классах. Да, конечно, мне не понять, ага.
M>>До твоего ровного, не испоганеного присутсвием извилин мозга не доходит тот простейший факт, что в других языках это может быть нафиг не нужно.
S>Я не вижу особой необходимости этого и в ц++. Но как бы отсутствие такой возможности вменяли в минус ц++, поэтому я на этом примере наглядно показал, что язык гибок и вместо того чтобы хныкать об отсутствии фичи надо бы ее просто реализовать. Но нет же: "мне лень". Ругать — проще.

Нет, не "мне лень", а "нафига козе баян" если в других языках для этого есть удобные extension methods, миксины, и partial class definitions. Без необходимости писать кашу на define'ах


dmitriid.comGitHubLinkedIn
Re[12]: И снова про ц++
От: hattab  
Дата: 05.02.12 00:19
Оценка:
Здравствуйте, Artifact, Вы писали:

A> Я не имею ввиду стиль библиотеки. Я имею ввиду определённый общий стиль, благодоря которому все библиотеки выглядят похожими. Прослеживается некая общсность. В плюсах же я чаще вижу какой-то зоопарк.


У меня есть штук пять дельфийских врапперов для SQLite, там общности даже близко не видно, хотя задача в общем то одна

A> У Дельфи, образно говоря, география сужена до одной конторы. У плюсов различия начинаются уже с лёгкой руки разработчиков компиляторов. Правда это впоследствии привело к появлению стандарта, что исправило положение, но всё же ещё продолжает иметь место быть.


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

A> Во многих других языках компилятор вам просто не даст вам "выстрелить себе в ногу". В плюсах, как нигде, можно послать компилятор нафиг.


Послать компилятор можно с легкостью и в дельфях. Там низкоуровневых штучек более чем достаточно, одни только нетипизированные параметры чего стоят.

A> ОК, верю. Я с Дельфи сталкивался только в одной фирме, там было три проекта на Дельфи, начатые в разное время, да ещё и в разных странах, но выглядели они на удивление одинаково. Никакого единого стиля никто придерживаться не заставлял, но похоже все о нём знали.


Ну так в чем единство? Можно в нескольких словах объяснить?

A> Странно. Такое я видел, только когда проект на Джаве писали бывшие С++ программисты (кроме шуток).


Я не знаю, писали ли это бывшие плюсисты или нет, сравнивал Apache XML-RPC и Redstone XML-RPC.
avalon 1.0rc3 build 428, zlib 1.2.3
Re[13]: И снова про ц++
От: Artifact  
Дата: 05.02.12 01:33
Оценка:
Здравствуйте, hattab, Вы писали:

H>У меня есть штук пять дельфийских врапперов для SQLite, там общности даже близко не видно, хотя задача в общем то одна

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

H>Наличие ориентира, само по себе, еще ни чего не значит. Внутри конторы стиль тоже разный. Даже в рамках самой VCL можно найти модули выполненные ну очень не похожим на остальные способом.

И вы это как-то ощущаете? Вам не кажется, что как раз именно в Дельфи вам предлагается идти какой-то протарённой дорогой придуманной за вас разработчиками продукта?

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

И что, часто посылают?

H>Ну так в чем единство? Можно в нескольких словах объяснить?

ООП, CamelCase, префикс "Т" почти повсеместно, отступы, размещение begin-end, передача и возврат значения, единобразная работа со строками, обработка ошибок.

H>Я не знаю, писали ли это бывшие плюсисты или нет, сравнивал Apache XML-RPC и Redstone XML-RPC.

Судя по оформлению кода Redstone XML-RPC похоже плюсовики писали, я бы даже поспорил. Хотя и в Apache XML-RPC тоже нашёл странности.
__________________________________
Не ври себе.
Re[12]: И снова про ц++
От: Ops Россия  
Дата: 05.02.12 02:18
Оценка:
Здравствуйте, Философ, Вы писали:

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

Ops>>Ну, во-первых, vtable там нет, если бы меньше философствовали, а познакомились с предметом, Вы бы это знали.

Ф>нуууууууууууууу во-первых я не писал что он там есть

Ф>были бы виртуальные функции — был бы и vtable
А это что было?
> System.IntPtr vtable;

Вообще-то все, или почти все (навскидку не вспомню) классы из STL не содержат виртуальных функций. std::basic_string точно не содержит.

Ф>ЗЫ: кстати, , если вам так не нравится vtable, можете его убрать class __declspec(novtable)...

Ф>тогда ваши программы будут есть меньше памяти
Это к чему вообще? С чего вдруг мне не нравится vtable? Просто его там нет и быть не может, так в стандарте написано.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[12]: И снова про ц++
От: okman Беларусь https://searchinform.ru/
Дата: 05.02.12 07:40
Оценка:
Здравствуйте, Mamut, Вы писали:

O>>Эдак можно прийти к выводу, что linux тоже в глубоком ауте из-за разнообразия версий.

O>>А на самом деле обилие реализаций всего лишь отражает широту круга задач, которые ими решаются.

M>Нет, не отражают. Отражает только ровно один факт: в С++ нет нормального способа работать со строками. Все эти QString/CString/*string'и процентов на 80-90 ублируют функцинальность друг друга.


Не повторяйте себя.
Критерий нормальности строк мы уже обсудили.
Re[8]: И снова про ц++
От: okman Беларусь https://searchinform.ru/
Дата: 05.02.12 07:40
Оценка:
Здравствуйте, Young, Вы писали:

O>>Я, вообще-то, писал о том, что на любом языке можно написать код, провоцирующий


Y>Не на любом.


На каком нельзя ?

Y>Да, именно давайте запрещать глобальные переменные.


Что ж, логично. В Шарпе их запретили уже или еще нет ?

O>>Каким боком тут C++ ? Этот код мог быть на любом языке. И тоже бы имел

O>>обозначенные Вами "сайд-эффекты".

Y>Нет, в том то и дело. Более того — насколько я знаю, в ряде языков, есть возможность чисто математически это доказать — т.е. что код делает именно это и только это.


Y>Но не суть. Когда я в erlang-е вижу такое — мне как-то спокойнее насчет сайд эффектов


Y>
Y>is_local_address(IP_Adress) ->
Y>    case IP_Adress of
Y>        "localhost" -> true;
Y>        "127.0.0.1"    -> true;
Y>        _ -> false
Y>end.
Y>


К сожалению, я не знаком с Erlang, но разве и здесь определение IP_Address не может поменяться ?
Re[14]: И снова про ц++
От: okman Беларусь https://searchinform.ru/
Дата: 05.02.12 07:44
Оценка:
Здравствуйте, Cadet, Вы писали:

C>Тебе по сути экстеншн методов есть что сказать, или будем придираться к примеру?


Штука полезная. Никто не спорит. Но пример был неудачный.
Re[4]: И снова про ц++
От: FR  
Дата: 05.02.12 08:15
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:


НС>Продемонстрируй рекурсию на лямбдах.


Y–комбинаторы рулят:

fib = lambda n : (lambda func, n : func(n, func))(lambda x, rec : x < 2 and 1 or rec(x-1, rec) + rec(x-2, rec), n)


Думаю на C++11 лямбды перепишется, но станет в три раза страшней
Re[4]: И снова про ц++
От: enji  
Дата: 05.02.12 08:17
Оценка:
Здравствуйте, FR, Вы писали:

FR>Здравствуйте, D.Lans, Вы писали:


DL>>А какой есть аналог у C++?


FR>http://www.d-programming-language.org/index.html


Да какой же это аналог? Что написано на D, что у него с иде, с библиотеками, есть ли компиляторы под какой-нить арм, есть ли вообще устаканившаяся версия? То, что я слышал — там постоянная работа над языком, Д2 несовместим с Д и вообще все пока печально...
Re[5]: И снова про ц++
От: FR  
Дата: 05.02.12 08:35
Оценка:
Здравствуйте, enji, Вы писали:

FR>>http://www.d-programming-language.org/index.html


E>Да какой же это аналог? Что написано на D, что у него с иде, с библиотеками, есть ли компиляторы под какой-нить арм, есть ли вообще устаканившаяся версия? То, что я слышал — там постоянная работа над языком, Д2 несовместим с Д и вообще все пока печально...


Как язык вполне аналог, притом прилично улучшенный, остальное довольно печально.
Под арм есть gdc
Устаканившаяся версия http://digitalmars.com/d/1.0/index.html
Да и в 2.0 уже почти нет ломающих изменений давно.
IDE сейчас есть вполне приличное Visual D
Билиотеки сишные вполне можно использовать http://www.d-programming-language.org/interfaceToC.html
Re[4]: И снова про ц++
От: Abyx Россия  
Дата: 05.02.12 08:45
Оценка:
Здравствуйте, jazzer, Вы писали:

S>>>>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++?

AVL>>>слабая маркетинговая составляющая
S>>Каким боком маркетинг относится к языку программирования?
J>Гы. Ты считаешь, у жабы и шарпа был бы хоть один процент их нынешнего успеха, если бы за ними не стояли сан и мелкософт?
J>Вон Немерле — хороший язык, и где он? А если мелкософт его попиарит в стиле "больше шарпа не будет, следующий шарп — это Немерле" — угадай, насколько вырастет его доля через год-два, и на какой строчке он будет в каком-нть ТИОБЕ.

с F# почему-то так не произошло
In Zen We Trust
Re[5]: И снова про ц++
От: FR  
Дата: 05.02.12 08:48
Оценка:
Здравствуйте, Abyx, Вы писали:


J>>Гы. Ты считаешь, у жабы и шарпа был бы хоть один процент их нынешнего успеха, если бы за ними не стояли сан и мелкософт?

J>>Вон Немерле — хороший язык, и где он? А если мелкософт его попиарит в стиле "больше шарпа не будет, следующий шарп — это Немерле" — угадай, насколько вырастет его доля через год-два, и на какой строчке он будет в каком-нть ТИОБЕ.

A>с F# почему-то так не произошло


Особого пиара F# со стороны MS не видно, да и шарп не торопятся отменять в его пользу.
Re[9]: namespace'ы в классах
От: Privalov  
Дата: 05.02.12 08:52
Оценка:
Здравствуйте, netch80, Вы писали:

N>Мнэээ... спасибо, посмеялся — больше с AndrewVK и RSDN'овцев, чем с Шеридана. Ибо подобные вопросы при нормальном ведении проекта через сколь-нибудь внятную SCM//VCS (которых 6 лет назад уже было пруд пруди) в принципе не возникли бы.


Тут ты, конечно, прав, но не все так однозначно. Мне довелось работать над проектом, где версионник не использовался. Одновременно работали 3-5 человек, что в данном случае — огромная толпа. Это было в 21 веке. Но если меня кто-то спрашивал, что за фигня тут написана, то ответ в стиле "для меня это загадка", сам понимаешь, не принимался. А если версионник используется, то и тут не все просто. Например, я поправил какой-нибудь баг, но увидел в коде сомнительное место. Доверяя коллеге, работавшему с этим кодом до меня, я его не трогаю. А через некоторое время в этом месте вылезает еще бага. С вопросом "что за фигня", согласно записям в версионнике, прибегут все равно ко мне. И ответ "не знаю" вполне могут не принять и в этом случае.

N>А без SCM, конечно, уже через полгода забудешь, что делал и почему, при том, что часто смотришь на код годовой давности и думаешь "под какими веществами я был, когда писал это?" Так что jIMHO этот пример Шеридану только в плюс


Такие вещи, как правило, случаются, когда нужно что-нибудь срочно поправить или добавить фичу перед выпуском очередной версии. Код пишется абы как, лишь бы упал не сразу. И поправить не дают, потому как можно из графика выбиться. Тогда и правда, первый вопрос, который возникает: "Какой идиот это писал?" Второй вопрос, после просмотра истории, про вещества.

Ну и управление проектом играет свою роль. Мне как-то довелось услышать: "Нам на качество кода по фигу, главное — не выбиваться из графика".

А этот код вряд ли писался в таких условиях. Open Source, когда хочу, тогда и пишу. Торопиться некуда.

Вот недавно у меня спросили: "Ты помнишь, как делал такой-то модуль лет 6 назад?" Отвечаю вопросом на вопрос: "Что, я в самом деле такое писал?" Мне показывают исходники. Смотрю: почерк мой. Спрашиваю, что случилось. Говорят, все работает, просто хотелось бы добавить... И добавляю относительно легко, потому как при написании того кода я был в здравом уме и твердой памяти. До релиза далеко, спешить некуда. Красота. Но такое случается реже.

И таких страшных switch/case я в рабочий код выпустил всего один раз за всю свою практику, да и то через месяц плюнул на все и переделал на таблицы.
Re[5]: И снова про ц++
От: Ночной Смотрящий Россия  
Дата: 05.02.12 09:05
Оценка:
Здравствуйте, netch80, Вы писали:

N>Плюнь в глаза каждому, кто скажет, что в C или C++ нет модульности. Потому что она есть. Разные части кода можно раздельно компилировать, группировать в подключаемые библиотеки, описывать для них интерфейсы. Это и есть модульность.


Без возможности динамической загрузки это не модульность, а профанация.

N> То, что в Java или C# описание объявлений обязательно "впечатывается" в скомпилированный модуль, не увеличивает модульность, а уменьшает её — за счёт невозможности физически отделить описание интерфейса от содержания реализации.


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

N>Я сталкивался с заголовочными файлами, отдельными от собранных модулей, в: C, C++ (очевидно)


Это я уже понял.

N>ассемблерах


?

N>Fortran, Erlang


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

НС>>Это синтаксический сахар для вызова статических методов (и, видимо, свободных функций в случае С++)

N>Тогда непринципиально.

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

N>Понятно, тоже сахар (хоть и полезный). Но вообще-то эти выражения противоположны по порядку исполнения, по крайней мере в сишном синтаксисе.


И именно поэтому такой синтаксис намного лучше для continuation monad, к примеру.

НС>>Но единый и расширяемый синтаксис для сигналов был бы весьма полезен.

N>Хм, неужели недостаточно какого-нибудь hash<> в одном из полей класса и одного метода с простым лукапом?

Нет. Как минимум нужен минимальный синтаксис инициализации:
obj.MySignal = FooMethod;


НС>>Без поддержки со стороны языка это будет очередной уродец.


N>Оно просто будет платформенно-зависимо.


Главное — нужна синтаксическая поддержка. А внутреннюю реализацию можно и в библиотеку вынести.

N> Например, для i386 AKA x86-32 для стандартных конвенций вызова просто будет сгенерирован (при исполнении) код, который добавляет одно или несколько слов на стек между адресом возврата и первым параметром и делает переход на заданный адрес. Для других может быть сложнее (например, для amd64 придётся двигать регистры), но тоже беспроблемно реализуемо.


Не обязательно замыкания реализовывать в лоб. Дотнет вполне справляется и без двиганья регистров.

НС>>Но поддержка со стороны языка была бы весьма пользительна. Хотя бы в виде шарповских async/await.


N>Забавный сахар


ИМХО, это все таки больше чем сахар. Как и итераторы. Которые тоже неплохо бы поддержать в С++, только не в виде интерфейса IEnumerable, как в дотнете, а просто в виде функционального типа.
Re[13]: И снова про ц++
От: gegMOPO4  
Дата: 05.02.12 09:08
Оценка:
Здравствуйте, Ops, Вы писали:
Ops>Вообще-то все, или почти все (навскидку не вспомню) классы из STL не содержат виртуальных функций. std::basic_string точно не содержит.

Исключения, буфера В/В. Ещё с локалями что-то.
Re[14]: namespace'ы в классах
От: Sheridan Россия  
Дата: 05.02.12 09:15
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Нет, не "мне лень", а "нафига козе баян" если в других языках для этого есть удобные extension methods, миксины, и partial class definitions. Без необходимости писать кашу на define'ах


И я так и не увидел реализацию неймспейсов класса ни на одном языке.
Matrix has you...
Re[15]: namespace'ы в классах
От: Mamut Швеция http://dmitriid.com
Дата: 05.02.12 09:18
Оценка:
Здравствуйте, Sheridan, Вы писали:

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


M>>Нет, не "мне лень", а "нафига козе баян" если в других языках для этого есть удобные extension methods, миксины, и partial class definitions. Без необходимости писать кашу на define'ах


S>И я так и не увидел реализацию неймспейсов класса ни на одном языке.



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


dmitriid.comGitHubLinkedIn
Re[8]: namespace'ы в классах
От: Sheridan Россия  
Дата: 05.02.12 09:22
Оценка:
Здравствуйте, Mamut, Вы писали:

C>>>Да в данном месте наплакал конечно. А в реальном проекте, с исходниками мегабайт ну скажем 5, один так наплакал в одном месте, другой в другом, третий в третьем. А потом ты рыдаешь, когда продираешься через это в поисках ошибки.

S>>То есть ты предлагаешь не использовать целый огромный пласт возможностей языка, ссылаясь на лень? Ну-ну...

M>Шеридан, когда мы с тобой разговаривали про Калпу, я тебя попросил не ломиться отвечать сразу, а сделать хотя бы минимальное усилие над собой и попытаться понять, что тебе люди пишут. Выделенное != лень. Если ты не способен этого понять, пожалуйста, перестань вообще что-либо писать про программирование, умоляю.


Выделенное как раз таки лень. Я тупо называю вещи своими именами, не прикрываясь всякими "трудно поддерживать". И изза этой лени отказываются от огромного пласта возможностей языка. И мало того — и остальным советуют отказаться. Ну, чтобы в кругу таких же лентяев быть как все.
Так что нет. Ты неправ. И остальные неправы. И мне посрать на то что мне советуют бросить дефайны якобы опытные люди. Они может и опытные, но ленивые.
Matrix has you...
Re[5]: И снова про ц++
От: gegMOPO4  
Дата: 05.02.12 09:24
Оценка:
Здравствуйте, x-code, Вы писали:
XC>Здравствуйте, gegMOPO4, Вы писали:
MOP>>Есть два преимущества системы C — раздельная компиляция и совместимость со старым кодом на ассемблере и Фортране. Первое сейчас не критично, в память влазит полностью и файл-исходник, и выход, и промежуточное представление, и интерфейсы других модулей. Совместимость же сейчас интереснее с другими языками (Java, Python,...).
XC>Ну вот в C# вроде нормальная модульная система. Раздельная компиляция, но никаких include, То, что объявлено в одном файле, свободно доступно в другом. Я не думаю что такое сложно сделать для нативного языка типа С++.

Проблема циклических ссылок. Если файл А зависит от файла Б, а Б от А, то для компиляции необходимы оба файла одновременно.

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


Из Си можно вызвать подпрограмму, написанную на Фортране, или реализовать функцию для вызова из Фортрана. Аналогично с оговорками для ассемблера.
Re[16]: namespace'ы в классах
От: Sheridan Россия  
Дата: 05.02.12 09:35
Оценка:
Здравствуйте, Mamut, Вы писали:

S>>И я так и не увидел реализацию неймспейсов класса ни на одном языке.

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

Ты же занешь, что я не слежу за модой. Я не знаю тех языков, и знать не хочу. Ибо половину из них переживу сам. Покажи пожалуйста код. Или объясни почему там такого не надо и почему ВНЕЗАПНО оказалось нужно в ц++.
Matrix has you...
Re[15]: namespace'ы в классах
От: Sheridan Россия  
Дата: 05.02.12 09:43
Оценка:
Здравствуйте, FR, Вы писали:

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

S>>Вот когда мне будут за код платить деньги — я буду делать то что надо. До тех пор я буду делать то, что мне интересно.
FR>Не сможешь, во всяком случае сразу, программирование практический навык, и как любой навык базируется на привычках. Их перебарывать будет очень тяжело.

Возможно, но я буду очень стараться.
Matrix has you...
Re[17]: namespace'ы в классах
От: Mamut Швеция http://dmitriid.com
Дата: 05.02.12 09:47
Оценка:
S>>>И я так и не увидел реализацию неймспейсов класса ни на одном языке.
M>>Выделено. Если ты не способен понимать то, что тебе пишут, то надо или признаться, что ты дислексик, или идти лечиться.

S>Ты же занешь, что я не слежу за модой. Я не знаю тех языков, и знать не хочу.


Это — ключевое. И повторяемое тобой на протяжении шести-семи лет. Эта фраза полностью характеризует тебя. "Не знаю и знать не хочу. Я лучше буду выдавать за абсолютную истину все, что говорят голоса в голове, невзирая на реальность"

Ответь мне ровно на один вопрос: нахрена ткбк что-то объяснять, если ты не знаешь и знать не хочешь?


dmitriid.comGitHubLinkedIn
Re[5]: И снова про ц++
От: gegMOPO4  
Дата: 05.02.12 09:55
Оценка:
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, gegMOPO4, Вы писали:
MOP>>Здравствуйте, netch80, Вы писали:
N>>>Здравствуйте, x-code, Вы писали:
XC>>>>Ужасная система #include и препоцессора,
N>>>Для своих задач препроцессор вполне адекватен. С другой стороны, ничто не мешает при необходимости сделать над ним что-то своё. Например, на m4, не к ночи будь сказано (но всё равно для мелких задач начинают выбор с него) или на любом другом макропроцессоре, какой понравится.
MOP>>Проблема в том, что это слишком неформальная, свободная система, трудно автоматизировать построение зависимостей, особенно с учётом макроопределений. Поэтому для каждого нового набора опций сборки нужно отдельное дерево, и выгоды раздельной компиляции всё чаще идут лесом, и ошибиться легко, собрав несовместимые объектники.
N>Да, неформальная и свободная. Но для Си в общем-то другая и не пойдёт. Более того, постоянно возникает необходимость аналогичных средств к другим языкам — например, к Питону.
N>На сейчас приходится при необходимости выбирать реализацию на старте заниматься хаками типа вынести зависимое от внешних условий в мелкие функции и вызывать их по ссылке из основного кода. А это может заметно тормозить выполнение программы. При препроцессоре стиля Си условная компиляция с самого начала помогла бы сэкономить на этом.

Препроцессор в процессе установки (или пакетирования) — всего делов-то.

N>А описанные тобой ужасы, конечно, имеют место, но пока что в основном перекрываются выгодами.


Хотелось бы и на ёлку залезть, и задницу не ободрать.

XC>>>> отсутствие нормальной модульной системы

N>>>Если речь про схему в стиле Вирта (тут interface, а тут implementation), то несложно заметить, что почему-то она не прижилась в промышленности и не была принята ни в одном языке, начатом "с нуля", заведомо позже массового распространения Паскаля. Например, она не была принята ни в Java ни в C#. Зато подход с заголовочными описаниями распространяется практически на все языки. Я думаю, у "нормальной модульной системы" всё-таки есть какой-то фатальный недостаток.
MOP>>Где ещё, кроме C/C++ (и нескольких непродуманных язычков вроде PHP) используется «модульность» на основе #include? Как раз в Java отдельный файл — отдельный класс, единица трансляции, пространство имён, единица организации кода.

N>Не-а. Нормальная модульность была бы, если бы можно было отделить объявления от того, что их реализует. Например, есть модуль — вот вам список функций в нём, а сами функции где-то в другом месте. Никакая Java такого не умеет и не собирается, хочешь взять определения откуда-то — изволь принести полную реализацию. А заголовочные файлы для C/C++ хоть и бардачны, но позволяют именно это — в них только объявления функций, определения констант и enum'ов и тому подобное.


MOP>>Есть два преимущества системы C — раздельная компиляция и совместимость со старым кодом на ассемблере и Фортране. Первое сейчас не критично, в память влазит полностью и файл-исходник, и выход,

N>При чём тут влезает или не влезает в память? Есть куча причин не компилировать всё вместе. Только для студенческой песочницы годится требовать всё одним скопом, и то — ОС сюда уже никто не включает.

Так я же и не спорю. В той же Java (как пример мейнстримового отличного от Си подхода) одним скопом большие проекты тоже не собираются — делятся на библиотеки, зависимости между которыми проще.

Разница в том, что в Си программист отдельно пишет интерфейс и реализацию, удовлетворяющую его (но всё это неформально, язык не обеспечивает согласованность), а в Java оба генерируются из одного кода (но есть риск, что интерфейс поедет в процессе работы над реализацией). Идеальным была бы формализируемая языком модульность с чётким разделением (обеспечиваемым языком, а не организационно) на интерфейс и реализацию. Интерфейс для сборки не обязательно должен быть в исходниках, может быть и в бинарном виде (переносимые прекомпилированные хидеры), должна быть проверка согласованности интерфейса и реализации.

XC>>>>Невозможность создания namespace внутри класса (вспомните хотя-бы "главные оконные классы" разных библиотек — CWnd, QWidget... сотни методов, там разделение не помешало бы)

N>>>В принципе согласен. Более того, система namespace неудобна.
N>>>Постоянно хочется решений в стиле питоновского import X.Y.Z as W.
MOP>>
MOP>>namespace W = X::Y::Z;
MOP>>

N>Я уже давно объяснил в соседних сообщениях, что эта ерунда не имеет ничего общего с тем, что я хотел.
N>Читай с конца, не будешь повторять уже пережёванное.

Я как-то привык читать с начала.

Есть ещё using. Ну а переносить напрямую конструкции с одного языка в другой невозможно, в каждом монастыре свой устав.
Re[6]: И снова про ц++
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 05.02.12 09:58
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

N>>Плюнь в глаза каждому, кто скажет, что в C или C++ нет модульности. Потому что она есть. Разные части кода можно раздельно компилировать, группировать в подключаемые библиотеки, описывать для них интерфейсы. Это и есть модульность.

НС>Без возможности динамической загрузки это не модульность, а профанация.

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

N>> То, что в Java или C# описание объявлений обязательно "впечатывается" в скомпилированный модуль, не увеличивает модульность, а уменьшает её — за счёт невозможности физически отделить описание интерфейса от содержания реализации.

НС>Кто тебе такую глупость сказал? И в джаве в любом случае интерфейс будет отдельным модулем от его реализации,

Что-то не замечал ни разу. Обычно идёт в поставке jar-файл, в котором всё вместе. Дай ссылку на документацию или хотя бы по каким ключевым словам искать.

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


Что можно — уже хорошо. А кто-то это реально делает — так, чтобы поставлять от продукта отдельно эти метаданные?

N>>Я сталкивался с заголовочными файлами, отдельными от собранных модулей, в: C, C++ (очевидно)

НС>Это я уже понял.
N>>ассемблерах
НС>?

Что '?' ?

~/gitwork/linux/main>>
$ find arch/x86/ -name '*.S' | xargs fgrep '#include' | less
arch/x86/boot/compressed/head_32.S:#include <linux/init.h>
arch/x86/boot/compressed/head_32.S:#include <linux/linkage.h>
arch/x86/boot/compressed/head_32.S:#include <asm/segment.h>
arch/x86/boot/compressed/head_32.S:#include <asm/page_types.h>
arch/x86/boot/compressed/head_32.S:#include <asm/boot.h>
arch/x86/boot/compressed/head_32.S:#include <asm/asm-offsets.h>
arch/x86/boot/compressed/head_64.S:#include <linux/init.h>
arch/x86/boot/compressed/head_64.S:#include <linux/linkage.h>
arch/x86/boot/compressed/head_64.S:#include <asm/segment.h>
[срезал остаток, вообще-то тут вывода 364 строки]


Если ты привык к тем кошмарам, что зовутся ассемблерами в Dos/Windows мире, могу только посочувствовать, но в общем случае и там было стандартной практикой подключать файлы всяких макроопределений.

N>>Fortran, Erlang

НС>Не самые популярные на сегодняшний день языки.

А при чём тут вообще фактор популярности?

НС>>>Но единый и расширяемый синтаксис для сигналов был бы весьма полезен.

N>>Хм, неужели недостаточно какого-нибудь hash<> в одном из полей класса и одного метода с простым лукапом?

НС>Нет. Как минимум нужен минимальный синтаксис инициализации:

НС>
НС>obj.MySignal = FooMethod;
НС>


obj.addSignal(MySignal, FooMethod);


Разве это настолько хуже, чтобы требовался синтаксис твоего варианта?
А что в твоём случае будет, если в объекте будет несколько таких маппингов сигналов на слоты? Например, для разных режимов работы (в этом случае естественно будет совпадение сигналов в разных маппингах)?

N>> Например, для i386 AKA x86-32 для стандартных конвенций вызова просто будет сгенерирован (при исполнении) код, который добавляет одно или несколько слов на стек между адресом возврата и первым параметром и делает переход на заданный адрес. Для других может быть сложнее (например, для amd64 придётся двигать регистры), но тоже беспроблемно реализуемо.

НС>Не обязательно замыкания реализовывать в лоб. Дотнет вполне справляется и без двиганья регистров.

Покажи код (на его внутреннем языке)
The God is real, unless declared integer.
Re[18]: namespace'ы в классах
От: Sheridan Россия  
Дата: 05.02.12 10:00
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Ответь мне ровно на один вопрос: нахрена ткбк что-то объяснять, если ты не знаешь и знать не хочешь?


Делаю вывод что реализовать такое на других языках невозможно. Ну во всяком случае на тех, которые используешь ты. Иначе ты бы даавно показал пример, а не пытался бы сменить тему на "шеридан тупой идиот"
Matrix has you...
Re[8]: И снова про ц++
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 05.02.12 10:02
Оценка:
Здравствуйте, jazzer, Вы писали:

J>>>Всегда было, см. 7.3.2 [namespace.alias] в С++98.

N>>Что "всегда", не согласен, в первых версиях не было, а потом я с C++ настолько плотно не общался. Но идея ясна. И это не совсем то, что надо, хотя тоже помогает.
J>В каких таких "первых" версиях? Cfront?
J>В стандарте 98-го года это было, а в достандартном ARM пространств имен не было вообще

Я перестал коммерчески писать на C++ в 97-м. После этого общения с ним были малочисленными и только для себя.

N>>Или есть случаи, когда имя в пространстве само по себе безумно длинное, а удобно назвать его короче, или просто переименовать в пределах данного модуля в соответствии с более подходящим смыслом. Такое данным методом вообще не решается.

J>Ну так это ты плачешь об общей проблеме переименования (или даже о еще более общей проблеме выделения имени в первоклассную сущность), пространства имен тут ни при чем, эта же проблема у тебя будет и без них.

Да, будет. Но когда рядом видишь комплексное решение проблемы и переименования, и использования пространств имён, в удобном виде, а тут его вдруг нет, становится слегка обидно. И то, что проблема вообще не поставлена, хотя такие конфликты нередки — настроения не поднимает.

J>Действительно, общего решения этой проблемы нет.

J>Для частных случаев есть частные решения:
J> — Пространства имен: приведенный выше [namespace.alias]
J> — Типы: typedef
J> — Переменные: ссылки
J> — Шаблоны: алиасы шаблонов [temp.alias] (C++11)
J> — Функции: общего решения нет из-за наличия перегрузки, надо либо через указатели на функции, либо через библиотечные решения типа std::function/std::bind (C++11/ищщые)

Вот-вот
The God is real, unless declared integer.
Re[19]: namespace'ы в классах
От: Mamut Швеция http://dmitriid.com
Дата: 05.02.12 10:06
Оценка:
M>>Ответь мне ровно на один вопрос: нахрена тебе что-то объяснять, если ты не знаешь и знать не хочешь?

S>Делаю вывод что реализовать такое на других языках невозможно. Ну во всяком случае на тех, которые используешь ты. Иначе ты бы даавно показал пример, а не пытался бы сменить тему на "шеридан тупой идиот"


Я тебе уже русским языком два раза написал:

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

в других языках для этого есть удобные extension methods, миксины, и partial class definitions


Умный человек уже давно потратил максимум 15 минут времени, чтобы выяснить, что это такое, почему в других языках это может быть не нужно (за неимением в оных классов, например) и т.п.

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

Итак, повторяю вопрос: нахрена тебе что-то объяснять, если ты не знаешь и знать не хочешь?


dmitriid.comGitHubLinkedIn
Re[20]: namespace'ы в классах
От: Sheridan Россия  
Дата: 05.02.12 10:16
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Итак, повторяю вопрос: нахрена тебе что-то объяснять, если ты не знаешь и знать не хочешь?

Примеры будут? Или слив засчитаем таки? Код покажешь или продолжишь воздух сотрясать?
Matrix has you...
Re[10]: namespace'ы в классах
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 05.02.12 10:19
Оценка:
Здравствуйте, Privalov, Вы писали:

N>>Мнэээ... спасибо, посмеялся — больше с AndrewVK и RSDN'овцев, чем с Шеридана. Ибо подобные вопросы при нормальном ведении проекта через сколь-нибудь внятную SCM//VCS (которых 6 лет назад уже было пруд пруди) в принципе не возникли бы.

P>Тут ты, конечно, прав, но не все так однозначно. Мне довелось работать над проектом, где версионник не использовался. Одновременно работали 3-5 человек, что в данном случае — огромная толпа. Это было в 21 веке. Но если меня кто-то спрашивал, что за фигня тут написана, то ответ в стиле "для меня это загадка", сам понимаешь, не принимался.

Это уже административные заморочки. То же самое "ХЗ" (или длинно "для меня это загадка") в зависимости от местных порядков может быть от "ХЗ, сейчас этот вопрос у меня не в TODO" (и в некоторых местах это единственно правильный ответ") до "ХЗ, если надо — через час доложу в основах, через два — во всех деталях" или "ХЗ, если надо — к вечеру исправлю".

А неиспользование SCM в 21-м веке это уже просто нелепо, jIMHO. Если остальные его не используют, то это надо делать хотя бы для себя. Но лучше его форсировать. В этом случае просто за счёт того, что видны коммиты, можно отследить, кто чего поломал, даже если коммит формируется автоматически за кого-то или даже по времени. Я использую автокоммит по времени для администрирования (конфиги).

N>>А без SCM, конечно, уже через полгода забудешь, что делал и почему, при том, что часто смотришь на код годовой давности и думаешь "под какими веществами я был, когда писал это?" Так что jIMHO этот пример Шеридану только в плюс

P>А этот код вряд ли писался в таких условиях. Open Source, когда хочу, тогда и пишу. Торопиться некуда.

Если у него три жены много таких проектов, то есть куда

P>И таких страшных switch/case я в рабочий код выпустил всего один раз за всю свою практику, да и то через месяц плюнул на все и переделал на таблицы.


Ну тут по 3-4 пункта — ничего страшного. На таблицу не тянет.
The God is real, unless declared integer.
Re[6]: И снова про ц++
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 05.02.12 10:31
Оценка:
Здравствуйте, gegMOPO4, Вы писали:

N>>Да, неформальная и свободная. Но для Си в общем-то другая и не пойдёт. Более того, постоянно возникает необходимость аналогичных средств к другим языкам — например, к Питону.

N>>На сейчас приходится при необходимости выбирать реализацию на старте заниматься хаками типа вынести зависимое от внешних условий в мелкие функции и вызывать их по ссылке из основного кода. А это может заметно тормозить выполнение программы. При препроцессоре стиля Си условная компиляция с самого начала помогла бы сэкономить на этом.
MOP>Препроцессор в процессе установки (или пакетирования) — всего делов-то.

Нет, в описанных условиях мне нужен был при запуске.

N>>А описанные тобой ужасы, конечно, имеют место, но пока что в основном перекрываются выгодами.

MOP>Хотелось бы и на ёлку залезть, и задницу не ободрать.

Я как раз адекватно вижу и плюсы, и минусы.

MOP>Так я же и не спорю. В той же Java (как пример мейнстримового отличного от Си подхода) одним скопом большие проекты тоже не собираются — делятся на библиотеки, зависимости между которыми проще.

MOP>Разница в том, что в Си программист отдельно пишет интерфейс и реализацию, удовлетворяющую его (но всё это неформально, язык не обеспечивает согласованность),

Язык обеспечивает согласованность, если не заниматься явными хаками. Если функция будет объявлена с одним интерфейсом (в C) в заголовочном файле и с другим — в исходном, будет ошибка компиляции. Аналогично для C++ и классов. Да, один раз надо явно захотеть согласования (вынеся в заголовок), но без этого всё равно адекватное использование невозможно, и легко проверяется.

MOP> а в Java оба генерируются из одного кода (но есть риск, что интерфейс поедет в процессе работы над реализацией).


Этот риск есть везде.

MOP> Идеальным была бы формализируемая языком модульность с чётким разделением (обеспечиваемым языком, а не организационно) на интерфейс и реализацию. Интерфейс для сборки не обязательно должен быть в исходниках, может быть и в бинарном виде (переносимые прекомпилированные хидеры), должна быть проверка согласованности интерфейса и реализации.


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

MOP>Я как-то привык читать с начала.


В таких дискуссиях это вредно.

MOP>Есть ещё using. Ну а переносить напрямую конструкции с одного языка в другой невозможно, в каждом монастыре свой устав.


Мне не надо конструкцию, мне надо то, что она делает.
The God is real, unless declared integer.
Re[9]: И снова про ц++
От: Young yunoshev.ru
Дата: 05.02.12 10:54
Оценка:
Здравствуйте, okman, Вы писали:

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


O>>>Я, вообще-то, писал о том, что на любом языке можно написать код, провоцирующий


Y>>Не на любом.


O>На каком нельзя ?


Хаскель, Эрланг — сами языки своими средствами позволяют писать код которы гарантированно не содержит сайд эффектов.

Y>>Да, именно давайте запрещать глобальные переменные.


O>Что ж, логично. В Шарпе их запретили уже или еще нет ?


Понятия не имею. А чего вы шарп то все время тащите в обсуждение?

Y>>
Y>>is_local_address(IP_Adress) ->
Y>>    case IP_Adress of
Y>>        "localhost" -> true;
Y>>        "127.0.0.1"    -> true;
Y>>        _ -> false
Y>>end.
Y>>


O>К сожалению, я не знаком с Erlang, но разве и здесь определение IP_Address не может поменяться ?


Может — только тогда паттерн матчинг не пройдет, и мы получим false. Но суть не в этом — суть том что данная функция гарантированно ничего не может поменять вне своего контекста!
Re[21]: namespace'ы в классах
От: Mamut Швеция http://dmitriid.com
Дата: 05.02.12 11:03
Оценка:
M>>Итак, повторяю вопрос: нахрена тебе что-то объяснять, если ты не знаешь и знать не хочешь?
S>Примеры будут? Или слив засчитаем таки? Код покажешь или продолжишь воздух сотрясать?

Сотрясает воздух здесь ровно один человек: ты.

Миксины: http://en.wikipedia.org/wiki/Mixin
Extension methods: http://msdn.microsoft.com/en-us/library/bb383977.aspx
Partial classes and methods: http://msdn.microsoft.com/en-us/library/wa80x488.aspx

Но тебе эти ссылки будут бесполезны: ты не способен понять, о чем в них говорится


dmitriid.comGitHubLinkedIn
Re[14]: namespace'ы в классах
От: Cadet  
Дата: 05.02.12 11:16
Оценка:
Здравствуйте, Sheridan, Вы писали:

[skipped]

Ты знаком с понятием "медвежья услуга"?
... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
Re[10]: И снова про ц++
От: okman Беларусь https://searchinform.ru/
Дата: 05.02.12 11:19
Оценка:
Здравствуйте, Young, Вы писали:

Y>А чего вы шарп то все время тащите в обсуждение?


Ну так а что у нас на первых позициях во всяких там TIOBE ? Java с Шарпом.
По сути, все большие срачи на RSDN (вроде этого) разгораются между C++ и этими языками.

Y>>>
Y>>>is_local_address(IP_Adress) ->
Y>>>    case IP_Adress of
Y>>>        "localhost" -> true;
Y>>>        "127.0.0.1"    -> true;
Y>>>        _ -> false
Y>>>end.
Y>>>


O>>К сожалению, я не знаком с Erlang, но разве и здесь определение IP_Address не может поменяться ?


Y>Может — только тогда паттерн матчинг не пройдет, и мы получим false. Но суть не в этом — суть том что данная функция гарантированно ничего не может поменять вне своего контекста!


То же самое справедливо и для примера на C++, который я приводил.
Re[11]: И снова про ц++
От: Young yunoshev.ru
Дата: 05.02.12 11:23
Оценка:
Здравствуйте, okman, Вы писали:

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


Y>>А чего вы шарп то все время тащите в обсуждение?


O>Ну так а что у нас на первых позициях во всяких там TIOBE ? Java с Шарпом.

O>По сути, все большие срачи на RSDN (вроде этого) разгораются между C++ и этими языками.

И какое это имеет отношение к вопросу, что нам не нравится в ц++???

O>То же самое справедливо и для примера на C++, который я приводил.


Нет, же. Мы можем поменять код _вне_ функции, и это измнение приведет к изменению логики работы функции и любым побочным эффектам.
Начиная от произвольного дефайна (#define true false // happy debug) заканчивая переорпеделением метода ==, который может например иметь в себе багу и гадить в памятью.
Re[11]: namespace'ы в классах
От: Privalov  
Дата: 05.02.12 12:18
Оценка:
Здравствуйте, netch80, Вы писали:

N>Это уже административные заморочки. То же самое "ХЗ" (или длинно "для меня это загадка") в зависимости от местных порядков может быть от "ХЗ, сейчас этот вопрос у меня не в TODO" (и в некоторых местах это единственно правильный ответ") до "ХЗ, если надо — через час доложу в основах, через два — во всех деталях" или "ХЗ, если надо — к вечеру исправлю".


Оно, конечно, так, оно административное, но страдают от этого разработчики. Как когда-то вечно не хватало времени на профилактику, промывку головок дисководов, так и сейчас не хватает времени на всякие мелочи типа развертывания версионника. Сейчас, надо сказать, у меня с этим все в порядке. А вот ответ "Через час" у некоторых почему-то вызывает недоумение: "Как! Ты не помнишь? А у меня тут спрашивают срочно!"

N>А неиспользование SCM в 21-м веке это уже просто нелепо, jIMHO. Если остальные его не используют, то это надо делать хотя бы для себя.


Именно так и делаю. Но сейчас он, по крайней мере, развернут и работает. А тогда его вообще не было. Такое случается иногда в 21-м веке.

P>>А этот код вряд ли писался в таких условиях. Open Source, когда хочу, тогда и пишу. Торопиться некуда.


N>Если у него три жены много таких проектов, то есть куда


Однажды он сказал
Автор: Sheridan
Дата: 12.04.11
:

Скорость, качество — выберите одно. Это опенсорц.


Так что непонятно, есть куда торопиться или нет.

P>>И таких страшных switch/case я в рабочий код выпустил всего один раз за всю свою практику, да и то через месяц плюнул на все и переделал на таблицы.


N>Ну тут по 3-4 пункта — ничего страшного. На таблицу не тянет.


Как только case-ов становится больше двух — уже плохо. Пришлось на них пару раз наткнуться.
Re[14]: И снова про ц++
От: hattab  
Дата: 05.02.12 12:46
Оценка:
Здравствуйте, Artifact, Вы писали:

A> И что, хотите сказать, что в вашем проекте они будут смотреться как бананы на ёлке, что-ли? Какие там в принципе могут быть существенные отличия? Попробуйте библиотеку на Си подключить для сравнения.


Первое что бросается в глаза это использование символов "_" в названиях методов, в паскале так писать не принято. Ну и есть отличия в оформлении непосредственно враппера — кто-то реализует его в виде записи (структуры) с указателями на функции, кто-то в виде класса, у кого-то это просто набор глобальных переменных.

A> И вы это как-то ощущаете?


А то. У некоторых классов событиям могут быть назначены анонимные методы, у большинства нет. Где-то в качестве буфера используется AnsiString (строка с байтовым размером элемента), где-то TBytes (динамический массив байтов). Или, скажем, такая запись:
begin
 TRttiContext.Create.GetType(TButton).GetProperty('Caption').SetValue(Button1, 'RTTI');
end;

довольно нетипична для дельфей. Объект создается, но нигде не разрушается, не заносится ни в какой список и т.п. И утечки памяти это не вызывает. А дело в том, что это и не объект вовсе.

A> Вам не кажется, что как раз именно в Дельфи вам предлагается идти какой-то протарённой дорогой придуманной за вас разработчиками продукта?


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

A> H>Послать компилятор можно с легкостью и в дельфях. Там низкоуровневых штучек более чем достаточно, одни только нетипизированные параметры чего стоят.


A> И что, часто посылают?


Часто. Нетипизированный параметр присутствует в методе Dispatch любого объекта. Любой типизированный указатель имеет семантику массива и поддерживает адресную арифметику.

A> ООП, CamelCase, префикс "Т" почти повсеместно, отступы, размещение begin-end, передача и возврат значения, единобразная работа со строками, обработка ошибок.


ООП не всегда, более того, ООП не всегда на классах (хотя это не частое явление, да). Отступы, где 1, где 2, где 4 пробела, все очень по разному. С begin-end тоже не все просто:
 if ... then begin inc(a) end else begin dec(x) end;

 if ... then
  begin
   inc(a)
  end
 else
  begin
   dec(x)
  end;

 if ... then
  inc(a)
 else
  dec(x)

и есть еще вариации. Со строками, конечно, все проще, но ведь и там минимум 4 типа строк + массивы чаров совместимы со строками.
avalon 1.0rc3 build 428, zlib 1.2.3
Re[9]: И снова про ц++
От: hattab  
Дата: 05.02.12 12:46
Оценка:
Здравствуйте, enji, Вы писали:

e> A>По крайней мере на один меньше. Едва ли это считается нормальным в Дельфи выводить строку в консоль при помощи перегруженного оператора сдвига влево (если это вообще возможно).


e> В 2007 уже можно так сделать


C 2006
avalon 1.0rc3 build 428, zlib 1.2.3
Re[10]: И снова про ц++
От: FR  
Дата: 05.02.12 13:09
Оценка:
Здравствуйте, Young, Вы писали:

Y>Хаскель, Эрланг — сами языки своими средствами позволяют писать код которы гарантированно не содержит сайд эффектов.


D очень близкий родственник C++ это умеет

http://www.d-programming-language.org/function.html#pure-functions
http://www.d-programming-language.org/memory-safe-d.html

Если бы у комитета было бы желание уже в C++11 это могло бы быть.
Re[8]: И снова про ц++
От: enji  
Дата: 05.02.12 13:18
Оценка:
Здравствуйте, Young, Вы писали:

E>>Ну как-бы да. Список не дает быстрого доступа по индексу, кортеж — это фиксированное кол-во элементов разнотипных элементов.

E>>Вообще странное утверждение. Предположим у нас есть только яблоки и груши, но нет апельсинов — сильно хуже будет?
E>>Или вы намекаете на функциональное программирование? Тогда при чем тут С++? Чисто функциональные языки сейчас далеко не мейнстрим...

Y>Бррр....вообще какой то старный выверт разговора. А причем тут мейнстрим или не мейнстрим?

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

Y>Вот есть лисп — если смешать в кучу все его диалекты — то за все время получится обьем кода точно не меньший чем на ц++ (заметье мы ц++ обьсуждаем, а не ц). Но он таки не мейнстрим — и что?

Что, правда? Вы исследовали этот вопрос, у вас есть ссылки? Ни лисп, ни его диалекты никогда не были мэйнстримом, откуда под него возьмется куча кода?

Y>Изначально что спросили откуда такая нелюбовь. Я ответил — что нелюбовь от того, что при разработке на ц++ — и особенно при поддеживании чужого кода мы будем скорее решать технические проблемы связананные с выстрелами по памяти, порчей стека и т.п. — чем логические. А хочеться технические проблемы не решать и забыть о них.

Ну так а при чем тут си++? Это проблема любого натива — паскаль, с, си++, дельфи, с#+unsafe Опять же мой личный опыт показывает, что большинство проблем — логические, а не расстрелы памяти. Хотя конечно расстрелы тоже бывают

Y>И мне ей богу странно что с этим спорят. Что прет решать технические проблемы???


Y>>>Знаете, лет 15 назад я бы разделил вашу печаль..

Y>>>Но в текущий момент я (занимаясь разработкой игр под мобильные платформы замечу) — не могу представить себе реальной ситуации, в которой при размере массива в 26 ячеек мне было бы дело до того — есть там проверки или нету там проверок.

E>>А я занимаюсь микропроцессорами и вполне эту печаль разделяю К тому ж мобильные платформы — это сейчас несколько ядер и гигагерцы А возьмите какую-нить микроволновку или девайс с требованиями по электропотреблению — все сразу станет по другому...


E>>А иногда например, экономия пары баксов на процессоре при миллионных тиражах окупает даже разработку на голом асме. И такое бывает


Y>Бывает, да. Только зачем вам в случае микропроцессоров ц++? Чем вам ц99 не хватает то — если вы боритесь за производительность?

Неудобно У меня довольно большие программы на МК, мне удобно использовать ООП. В С++ ооп поддерживается компилятором, в С — нет. С++ шаблоны позволяют писать очень эффективный код по работе с регистрами, с другой стороны он понятнее и компактнее кода на С. К примеру Watchdog::start<1000>() на этапе компиляции развернется во что-то вроде
byte t = SREG;
WDTR = 0;
WDTR = 7; // 7 - это значение для задержки в примерно 1000 мс, вычисленное на этапе компиляции
SREG = t;


На макросах С вы такого не сделаете...

E>>Ключевая особенность С++ — не платишь за то, что не используешь. Нужны проверки — не вопрос, vector.at() или собственная обертка над массивом с проверками.

Y>Да елки-палки. Что значит не платишь — платишь, платишь потом сложными багами в чужих проектах, та же случайная, раз в месяц работы программы стрельба по памяти, приводящая не к крашу, а изменению данных.

Ну и что? В шарпе будет не аксесс виолатион, а исключение при попытке доступа к массиву или обращения по нулевому указателю. И какая разница пользователю моей программы? К тому ж, не везде допустима потеря в скорости или в объеме кода. Там где допустима, пользуются шарпом\явой...
Re[9]: И снова про ц++
От: Young yunoshev.ru
Дата: 05.02.12 14:15
Оценка:
Здравствуйте, enji, Вы писали:

Y>>Вот есть лисп — если смешать в кучу все его диалекты — то за все время получится обьем кода точно не меньший чем на ц++ (заметье мы ц++ обьсуждаем, а не ц). Но он таки не мейнстрим — и что?

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

Нет не исследовал, это мое оценочное суждение Но блин, когда я 15 лет назад начинал программировать вокруг были люди которые писла на лиспе, и сейчас есть люди вокруг меня которые пишут на лисп (ну ладно на clojure под android

Y>>Изначально что спросили откуда такая нелюбовь. Я ответил — что нелюбовь от того, что при разработке на ц++ — и особенно при поддеживании чужого кода мы будем скорее решать технические проблемы связананные с выстрелами по памяти, порчей стека и т.п. — чем логические. А хочеться технические проблемы не решать и забыть о них.

E>Ну так а при чем тут си++? Это проблема любого натива — паскаль, с, си++, дельфи, с#+unsafe Опять же мой личный опыт показывает, что большинство проблем — логические, а не расстрелы памяти. Хотя конечно расстрелы тоже бывают

Причем тут натив или не натив — вон тот же Ocaml — вполне себе нативный, та же scala и clojure — вполне себе компилирует в тот же java byte code что и джава.

Y>>>>Знаете, лет 15 назад я бы разделил вашу печаль..

Y>>>>Но в текущий момент я (занимаясь разработкой игр под мобильные платформы замечу) — не могу представить себе реальной ситуации, в которой при размере массива в 26 ячеек мне было бы дело до того — есть там проверки или нету там проверок.

E>>>А я занимаюсь микропроцессорами и вполне эту печаль разделяю К тому ж мобильные платформы — это сейчас несколько ядер и гигагерцы А возьмите какую-нить микроволновку или девайс с требованиями по электропотреблению — все сразу станет по другому...


E>>>А иногда например, экономия пары баксов на процессоре при миллионных тиражах окупает даже разработку на голом асме. И такое бывает


Y>>Бывает, да. Только зачем вам в случае микропроцессоров ц++? Чем вам ц99 не хватает то — если вы боритесь за производительность?

E>Неудобно У меня довольно большие программы на МК, мне удобно использовать ООП. В С++ ооп поддерживается компилятором, в С — нет. С++ шаблоны позволяют писать очень эффективный код по работе с регистрами, с другой стороны он понятнее и компактнее кода на С. К примеру Watchdog::start<1000>() на этапе компиляции развернется во что-то вроде
E>
E>byte t = SREG;
E>WDTR = 0;
E>WDTR = 7; // 7 - это значение для задержки в примерно 1000 мс, вычисленное на этапе компиляции
E>SREG = t;
E>


E>На макросах С вы такого не сделаете...


E>>>Ключевая особенность С++ — не платишь за то, что не используешь. Нужны проверки — не вопрос, vector.at() или собственная обертка над массивом с проверками.

Y>>Да елки-палки. Что значит не платишь — платишь, платишь потом сложными багами в чужих проектах, та же случайная, раз в месяц работы программы стрельба по памяти, приводящая не к крашу, а изменению данных.

E> Ну и что? В шарпе будет не аксесс виолатион, а исключение при попытке доступа к массиву или обращения по нулевому указателю. И какая разница пользователю моей программы? К тому ж, не везде допустима потеря в скорости или в объеме кода. Там где допустима, пользуются шарпом\явой...


Ну будет, а на erlang-е процесс будет прибит и востановлен — let it crash и все такое.
И опять же не понимаю почему бы опять переходим на шапр или яву — они ровно в такой же степени обладают озвученной мною проблемой
Re[9]: И снова про ц++
От: Young yunoshev.ru
Дата: 05.02.12 14:19
Оценка:
Здравствуйте, okman, Вы писали:

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


Y>>...нелюбовь от того, что при разработке на ц++ — и особенно при поддеживании чужого кода мы будем скорее решать технические проблемы связананные с выстрелами по памяти, порчей стека и т.п. — чем логические. А хочеться технические проблемы не решать и забыть о них.

Y>>И мне ей богу странно что с этим спорят. Что прет решать технические проблемы???

O>Инструмент не может быть проще предметной области, задачи которой он призван решать.

O>Если вы пишете системный софт, работаете с виртуализацией, прерываниями, вводом-выводом на
O>низком уровне, технические вопросы и технические проблемы будут окружать вас постоянно.
O>Они, так сказать, будут являться частью нормального рабочего окружения.
O>Попробуйте поставить какой-нибудь хук в kernel-mode, не зная про доступ к памяти или
O>calling convention — тут же отхватите BSOD (Blue Screen Of Death — синий экран смерти).

O>Короче, использование языков программирования низкого уровня — это во многих случаях не

O>прихоть программиста, а подчинение технической целесообразности. Вот почему бессмысленно
O>обвинять плюсовиков в тупости, консерватизме и нежелании поскорее пересаживаться на
O>новые технологии, точно также как бессмысленно спрашивать сторонников всяких управляемых
O>высокоуровневых языков про значение регистра LDTR под виртуальными машинами — им о
O>подобных вещах просто не приходится знать по специфике работы, а раз нет специфики,
O>нет и сопутствующих технических вопросов и проблем.


О! Мы тут пришли к мысли, что таки для каждой задачи наиболее оптимально подходят определенные языки. И для ц++ как правильно было замеченно подходят задачи "поставить какой-нибудь хук в kernel-mode" — ок, вот эту часть задачи можно написать на ц++ (хотя опять же почему бы не на ц). Ну так ради бога — нужен хук — написали его на ц++. Но зачем же деклалировать что ц++ это универсальный инструмент? Кувалда тоже универсальный инструмент, но часы с ее помощью чинить сложно.

Y>>Бывает, да. Только зачем вам в случае микропроцессоров ц++? Чем вам ц99 не хватает то — если вы боритесь за производительность?


O>Мне лично в C очень не хватает RAII (жить не могу) и какой-нибудь простенькой библиотеки

O>контейнеров по образцу vector/map/set/list. Без остального можно обходиться, в принципе.

Ей богу, не могу понять зачем в софте для микроволновки могут потребоватся map/set и RAII.
Но допустим — но я опять же не понимаю какое это имеет отношение к обсуждаемой проблеме?

Y>>Да елки-палки. Что значит не платишь — платишь, платишь потом сложными багами в чужих проектах, та же случайная, раз в месяц работы программы стрельба по памяти, приводящая не к крашу, а изменению данных.


O>Почему Вы отрицаете тот факт, что корректность функции нельзя доказать другими средствами,

O>нежели чисто языковыми (к примеру, набором юнит-тестов) ? Я о том, что когда такая гарантия
O>корректности есть, необходимость в накладных расходах, вызванных всякими проверками доступа к
O>памяти, стеку или выхода за границы массива, отпадает.
O>C++ позволяет отключать такие проверки, и это играет важную роль там, где производительность критична.
O>Поэтому в некоторых случаях выгоднее не платить за то, что не используется.

Стоп. Я ничего не отрицаю. Да, мы можем уменьшить потенциальный риск вызванные возможностями языка путем добавления дополнительного кода для проверки. Да (еще правда не забаем о второй итерации — типа ошибок в юнит тестах).

Но повторюсь — 90% задач в данный момент решаемых на ц++ — не имеют столь важных требований к производительности. Включение проверок чего удобно — не замедлит их на визуально различимое время.

Да и как с этим можно спорить то? Обьем того же кода python/ruby/ocaml/erlang растет чуть ли не экспонициально — ни это ли докозательство того что ц++ имеет проблемы?
Если ц++ настолько хорош, то почему появился erlang? Хотя задачи которые решает обычно erlang — они критичны к скорости выполнения?
Re[7]: И снова про ц++
От: Ночной Смотрящий Россия  
Дата: 05.02.12 15:17
Оценка:
Здравствуйте, netch80, Вы писали:

НС>>Без возможности динамической загрузки это не модульность, а профанация.


N>Эта модульность не мешает динамической загрузке.


Эта, она не мешает. Только вот без кроссплатформенного ABI нормальной модульности в С++ нет, есть только извращения типа СОМ или CORBA, требующие море обвязочного кода.

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


Для модульности — нужна, а вообще конечно не обязательна.

N> Например, она нафиг не нужна в железном раутере, в автомобильном инжекторе, или в карточке в кармане — в общем, там, где код целиком в (П)ПЗУ.


Ага, еще в АЭС, да.

НС>>Кто тебе такую глупость сказал? И в джаве в любом случае интерфейс будет отдельным модулем от его реализации,


N>Что-то не замечал ни разу.


А тут и замечать нечего. Джавовский интерфейс (который интерфейс как сущность) обязательно будет в отдельном файле с независимой загрузкой.

N> Обычно идёт в поставке jar-файл, в котором всё вместе.


jar это просто zip. Распаковываешь его и вперед. И там где нужно — укладывают отдельно модель в один jar, а конкретную реализацию в другой. И первый jar обычно стандартизован.

N> Дай ссылку на документацию или хотя бы по каким ключевым словам искать.


Я вот даже и не знаю, на что конкретно тебе дать ссылку. Ну, к примеру, все стандартные контракты EJB, Servlet/JSP серверов идут в составе J2EE, а их реализации — вполне отдельные продукты от сторонних поставщиков.

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


N>Что можно — уже хорошо. А кто-то это реально делает — так, чтобы поставлять от продукта отдельно эти метаданные?


МС сам делает. Для компилятора собственно исполняемый код не нужен, вот и отрезают его нафик.

N>Если ты привык к тем кошмарам, что зовутся ассемблерами в Dos/Windows мире, могу только посочувствовать, но в общем случае и там было стандартной практикой подключать файлы всяких макроопределений.


Так и пиши — макроассемблер.

НС>>Не самые популярные на сегодняшний день языки.

N>А при чём тут вообще фактор популярности?

А при чем тут, цитирую: "Зато подход с заголовочными описаниями распространяется практически на все языки"?

НС>>Нет. Как минимум нужен минимальный синтаксис инициализации:

НС>>
НС>>obj.MySignal = FooMethod;
НС>>


N>
N>obj.addSignal(MySignal, FooMethod);
N>


N>Разве это настолько хуже, чтобы требовался синтаксис твоего варианта?


Да, это хуже. Ну и с указателем на метод в С++ тоже не все шоколадно. Примерчик то можно и подправить слегка:
obj1.MySignal = obj2.FooMethod;
obj3.MySignal = x => obj4.FooMethod(x + 4);


N>А что в твоём случае будет, если в объекте будет несколько таких маппингов сигналов на слоты?


Что значит несколько? Мультикаст что ли? Ну так возьмем тот же шарп:
obj1.MySignal += obj2.FooMethod;


НС>>Не обязательно замыкания реализовывать в лоб. Дотнет вполне справляется и без двиганья регистров.

N>Покажи код (на его внутреннем языке)

var x = 4;
Func<int, int> inc = i => i + x;


IL_0007:  ldloc.1
IL_0008:  ldc.i4.4
IL_0009:  stfld      int32 ClosureTest.Program/'<>c__DisplayClass1'::x
IL_000e:  ldloc.1
IL_000f:  ldftn      instance int32 ClosureTest.Program/'<>c__DisplayClass1'::'<Main>b__0'(int32)
IL_0015:  newobj     instance void class [mscorlib]System.Func`2<int32,int32>::.ctor(object,
                                                                                     native int)
Re[14]: И снова про ц++
От: Ops Россия  
Дата: 05.02.12 15:18
Оценка:
Здравствуйте, gegMOPO4, Вы писали:

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

Ops>>Вообще-то все, или почти все (навскидку не вспомню) классы из STL не содержат виртуальных функций. std::basic_string точно не содержит.

MOP>Исключения, буфера В/В. Ещё с локалями что-то.


Ну да, просто я имел в виду только контейнеры.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[10]: И снова про ц++
От: okman Беларусь https://searchinform.ru/
Дата: 05.02.12 16:25
Оценка:
Здравствуйте, Young, Вы писали:

Y>О! Мы тут пришли к мысли, что таки для каждой задачи наиболее оптимально подходят определенные языки. И для ц++ как правильно было замеченно подходят задачи "поставить какой-нибудь хук в kernel-mode" — ок, вот эту часть задачи можно написать на ц++ (хотя опять же почему бы не на ц). Ну так ради бога — нужен хук — написали его на ц++. Но зачем же деклалировать что ц++ это универсальный инструмент? Кувалда тоже универсальный инструмент, но часы с ее помощью чинить сложно.


Именно эту точку зрения я и пытаюсь выражать в любом холиваре на подобные темы.
Один язык для одних задач, другой для других. Ругать глупо, лучше знать и уметь пользоваться обоими.
А про универсальность — это не ко мне, я такого не писал нигде и никогда.

Y>Стоп. Я ничего не отрицаю. Да, мы можем уменьшить потенциальный риск вызванные возможностями языка путем добавления дополнительного кода для проверки. Да (еще правда не забаем о второй итерации — типа ошибок в юнит тестах).


Y>Но повторюсь — 90% задач в данный момент решаемых на ц++ — не имеют столь важных требований к производительности. Включение проверок чего удобно — не замедлит их на визуально различимое время.


На счет производительности — да, соглашусь. Но это не единственный "камень преткновения".
Когда требуется очень плотное взаимодействие с интерфейсами операционной системы, или нужно
обеспечить какое-то редкое функциональное требование, у которого в высокоуровневых языках
отсутствует поддержка, тогда прямой путь использовать "естественные" языки системы.
Для большинства операционных систем это C, в первую очередь, ну и C++/asm.

Я мог бы привести в качестве примера задачи, с которыми сталкиваюсь сам и которые никакими
языками, кроме C/C++/asm, нормально решить не получится. Таких задач достаточно много и не
заметно, что в каком-то обозримом будущем ситуация сильно поменяется.

Y>Да и как с этим можно спорить то? Обьем того же кода python/ruby/ocaml/erlang растет чуть ли не экспонициально — ни это ли докозательство того что ц++ имеет проблемы?


Y>Если ц++ настолько хорош, то почему появился erlang? Хотя задачи которые решает обычно erlang — они критичны к скорости выполнения?


Очевидно потому, что для каких-то задач Erlang лучше любого другого языка.
Re[9]: И снова про ц++
От: x-code  
Дата: 05.02.12 18:56
Оценка:
Здравствуйте, Sheridan, Вы писали:

XC>>Красота языка определяется отсутствием таких вот обходных путей (а это именно обходной путь!). Да, в данном случае обойти просто... но это в данном случае, вполне могут быть случаи и посложнее. Мне нужен язык, в котором вообще ничего не нужно обходить.


S>Как страшно жить...

S>Еще раз: эту обертку делает IDE.

Речь не об IDE, а об языке. Эта обертка простая, но для каких-то других целей могут потребоваться более сложные обходные пути. И что, IDE мне будет вставлять простыни какого-то своего автоматически сгенерированного кода??? Мне это надо?
ИМХО, IDE вообще не должна лезть в код и что-то там делать.
Re[10]: И снова про ц++
От: Sheridan Россия  
Дата: 05.02.12 20:00
Оценка:
Здравствуйте, x-code, Вы писали:

XC>но для каких-то других целей могут потребоваться более сложные обходные пути. И что, IDE мне будет вставлять простыни какого-то своего автоматически сгенерированного кода???

А давай ка ты приведешь пример, дабы не быть голословным.
Matrix has you...
Re[10]: И снова про ц++
От: Sheridan Россия  
Дата: 05.02.12 20:54
Оценка:
Здравствуйте, Artifact, Вы писали:

S>>А с каких это пор мощность и универсальность языка ВНЕЗАПНО стала недостатком?

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

Ну так надо не языком ограничивать а правилами проекта.
Matrix has you...
Re[7]: namespace'ы в классах
От: Ночной Смотрящий Россия  
Дата: 05.02.12 23:43
Оценка:
Здравствуйте, Cadet, Вы писали:

C>Помнится участвовал в Авалоне, был быстро с треском изгнан . Из-за стиля работы "пишу как хочу и класть мне на остальную команду".


Он и в Янусе поучаствовал. Был выгнан по тем же причинам.
Re[9]: namespace'ы в классах
От: Ночной Смотрящий Россия  
Дата: 05.02.12 23:43
Оценка:
Здравствуйте, netch80, Вы писали:

N>Мнэээ... спасибо, посмеялся — больше с AndrewVK и RSDN'овцев, чем с Шеридана. Ибо подобные вопросы при нормальном ведении проекта через сколь-нибудь внятную SCM//VCS


А разве там не использовался Subversion, а потом Hg? Или это все невнятные?

N>А без SCM, конечно, уже через полгода забудешь, что делал и почему, при том, что часто смотришь на код годовой давности и думаешь "под какими веществами я был, когда писал это?"


Ты всерьез веришь, что там SCM не использовался? Сдается мне, это был риторический вопрос.
Re[3]: namespace'ы в классах
От: Sinclair Россия https://github.com/evilguest/
Дата: 06.02.12 01:46
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Ну если очень надо — можно и нарисовать, благо нетрудно. У меня — не программиста — ушло гдето минут 10...


S>Другое дело что на ненавистных местными дефайнах.... Ну уж это я считаю что они ими пользоваться не умеют...

В качестве упражнения — годится. В продакшн — вряд ли: слишком многословно и чревато ошибками.
Доступ к полям "объёмлющего" класса не вполне удобен, как и вызовы в "соседние" неймспейсы.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[10]: И снова про ц++
От: _d_m_  
Дата: 06.02.12 03:28
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>А, понял.

S>Актуально, если платят за размер кода, или например за количество непробельных символов
S>В любом случае нечитаемо при более-менее сложном коде

Ты реально похож на пингвина в подписи. Нечитаемо, это когда инклуды. И надо бегать по коду туда сюда.
Re[5]: И снова про ц++
От: _d_m_  
Дата: 06.02.12 03:37
Оценка:
Здравствуйте, netch80, Вы писали:

N>Не-а. Нормальная модульность была бы, если бы можно было отделить объявления от того, что их реализует. Например, есть модуль — вот вам список функций в нём, а сами функции где-то в другом месте. Никакая Java такого не умеет и не собирается, хочешь взять определения откуда-то — изволь принести полную реализацию. А заголовочные файлы для C/C++ хоть и бардачны, но позволяют именно это — в них только объявления функций, определения констант и enum'ов и тому подобное.


Да ты што!
Открой для себя интерфейсы C#. А заголовочные файлы — говно полное.
Re[4]: namespace'ы в классах
От: Sheridan Россия  
Дата: 06.02.12 04:09
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>>Другое дело что на ненавистных местными дефайнах.... Ну уж это я считаю что они ими пользоваться не умеют...

S>В качестве упражнения — годится. В продакшн — вряд ли: слишком многословно и чревато ошибками.
Ох да какже вы все дефайнов боитесь... о0

S>Доступ к полям "объёмлющего" класса не вполне удобен, как и вызовы в "соседние" неймспейсы.

Абсолютно согласен.
Matrix has you...
Re[11]: И снова про ц++
От: Sheridan Россия  
Дата: 06.02.12 04:19
Оценка:
Здравствуйте, _d_m_, Вы писали:

___>Ты реально похож на пингвина в подписи. Нечитаемо, это когда инклуды. И надо бегать по коду туда сюда.

Я это называю ленью.
Matrix has you...
Re[8]: namespace'ы в классах
От: Sheridan Россия  
Дата: 06.02.12 04:33
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Он и в Янусе поучаствовал. Был выгнан по тем же причинам.


Не искажай. Я сам ушел оттуда по причинам ухода из виндов в линукса.
Matrix has you...
Re[12]: И снова про ц++
От: Sheridan Россия  
Дата: 06.02.12 04:38
Оценка:
Здравствуйте, Young, Вы писали:

Y>Начиная от произвольного дефайна (#define true false // happy debug)

Найти по истории репозитория автора, спросить у ОК его адрес, приехать и набить морду.

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

О да, начинаем у ружей отпиливать курки дабы не отстрелить себе ноги? А то что ружье после этого не совсем уже и ружье — как бы остается без внимания.
Еще раз: с каких это пор мощность и универсальность языка ВНЕЗАПНО стало засчитываться в минусы этому языку?
Matrix has you...
Re[10]: И снова про ц++
От: enji  
Дата: 06.02.12 04:48
Оценка:
Здравствуйте, Young, Вы писали:

Y>>>Вот есть лисп — если смешать в кучу все его диалекты — то за все время получится обьем кода точно не меньший чем на ц++ (заметье мы ц++ обьсуждаем, а не ц). Но он таки не мейнстрим — и что?

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

Y>Нет не исследовал, это мое оценочное суждение Но блин, когда я 15 лет назад начинал программировать вокруг были люди которые писла на лиспе, и сейчас есть люди вокруг меня которые пишут на лисп (ну ладно на clojure под android


А я вот ни разу с такими не сталкивался, разный опыт видимо Ну и опять же, куча программ, которыми я пользуюсь, написана на с++. Лиспа я на десктопе что-то и не встречал. Про лисп на вебе я тож не слышал. Слышал, что был макроязык в автокаде (вроде бы) на основе лиспа. Но вроде как туда в конце концов всунули вба.

E>>Ну так а при чем тут си++? Это проблема любого натива — паскаль, с, си++, дельфи, с#+unsafe Опять же мой личный опыт показывает, что большинство проблем — логические, а не расстрелы памяти. Хотя конечно расстрелы тоже бывают


Y>Причем тут натив или не натив — вон тот же Ocaml — вполне себе нативный, та же scala и clojure — вполне себе компилирует в тот же java byte code что и джава.

scala и clojure — ни разу ни нативные. Про окамл — не знаю. Однако если он нативный, то возможность расстрелять память всяко есть. Возможно она несколько замаскирована

Y>И опять же не понимаю почему бы опять переходим на шапр или яву — они ровно в такой же степени обладают озвученной мною проблемой


Ну потому что вы говорите — я не люблю С++, потому что он императивный. Однако при чем тут С++? Тогда уж стоит завести тему — почему я не люблю императив
Re[13]: И снова про ц++
От: Cadet  
Дата: 06.02.12 04:48
Оценка:
Здравствуйте, Sheridan, Вы писали:

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


Y>>Начиная от произвольного дефайна (#define true false // happy debug)

S>Найти по истории репозитория автора, спросить у ОК его адрес, приехать и набить морду.

Да-да. Ты еще найди такую пасхалку в большом проекте. Она к примеру может хитро использоваться совместно с макросом __DATE__, и стрельнуть примерно через полгода после коммита.

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

S>О да, начинаем у ружей отпиливать курки дабы не отстрелить себе ноги? А то что ружье после этого не совсем уже и ружье — как бы остается без внимания.
S>Еще раз: с каких это пор мощность и универсальность языка ВНЕЗАПНО стало засчитываться в минусы этому языку?

С тех самых пор, как эта мощь и универсальность попала в руки Шериданам, неужели не понятно?
... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
Re[9]: И снова про ц++
От: Privalov  
Дата: 06.02.12 07:09
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Как страшно жить...

S>Еще раз: эту обертку делает IDE.

Ты совсем недавно утверждал, что IDE не нужны. Что-то с тех пор изменилось?
Re[13]: namespace'ы в классах
От: hattab  
Дата: 06.02.12 07:12
Оценка:
Здравствуйте, jazzer, Вы писали:

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


Type

 TParent = Class

  Private

   Type

    TNamespace = Class

     Function Func : String;

    End;

    TOtherNamespace = Class

     Function Func : String;

    End;

   Var

    FCount : Integer;

   Function GetNamespace : TNamespace; Inline;
   Function GetOtherNamespace : TOtherNamespace; Inline;

  Public

   Property Namespace : TNamespace Read GetNamespace;
   Property OtherNamespace : TOtherNamespace Read GetOtherNamespace;

 End;

Function TParent.TNamespace.Func : String;
Begin

 Result := 'Namespace: ' + IntToStr(TParent(Self).FCount);

End;

Function TParent.TOtherNamespace.Func : String;
Begin

 Result := 'Other namespace: ' + IntToStr(TParent(Self).FCount);

End;

Function TParent.GetNamespace : TNamespace;
Begin

 Result := TNamespace(Self);

End;

Function TParent.GetOtherNamespace : TOtherNamespace;
Begin

 Result := TOtherNamespace(Self);

End;
avalon 1.0rc3 build 428, zlib 1.2.3
Re[10]: namespace'ы в классах
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 06.02.12 07:26
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, netch80, Вы писали:


N>>Мнэээ... спасибо, посмеялся — больше с AndrewVK и RSDN'овцев, чем с Шеридана. Ибо подобные вопросы при нормальном ведении проекта через сколь-нибудь внятную SCM//VCS


НС>А разве там не использовался Subversion, а потом Hg?


Не знаю. У меня нет данных об этом, а искать это "со стороны", видимо, невозможно — слишком много мусора в поиске. Я опираюсь в своём предположении на постановку вопроса в процитированном сообщении: там вопрос 1) кто это сделал, 2) зачем (почему). При наличии SCM (её использовании как держателя кода проекта) и при её использовании участниками автор кода был бы найден сразу, также опознано, соответствует ли изменение содержанию комментария коммита, и если да — то логике. И тогда вопрос был бы не "Кто это сделал и зачем?", а "Ш-н, объясни, зачем это и откуда?"
Альтернативу, что SCM есть, но конкретный A.VK не умеет ею пользоваться, я отверг как нереальную.

НС> Или это все невнятные?


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

N>>А без SCM, конечно, уже через полгода забудешь, что делал и почему, при том, что часто смотришь на код годовой давности и думаешь "под какими веществами я был, когда писал это?"


НС>Ты всерьез веришь, что там SCM не использовался?


Сложно поверить, но у меня нет иного внятного варианта.

НС> Сдается мне, это был риторический вопрос.


Который именно?
The God is real, unless declared integer.
Re[14]: namespace'ы в классах
От: jazzer Россия Skype: enerjazzer
Дата: 06.02.12 07:42
Оценка:
Здравствуйте, hattab, Вы писали:

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


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


Хотел спросить, что это за язык, но судя по тегам, это паскаль
Если я правильно понял, что тут происходит (а я не очеь понял, какие в результате получаются взаимоотноения между классом TParent и TNamespace), то эта фича ортогональна плюсовым внутренним классам, которые никак не связаны с включающим их классом.
Т.е. здесь я вижу, что объект TNamespace — это всегда подобъект TParent и поэтому внутри TNamespace всегда можно конвертнуть Self в TParent.
А это, в свою очередь, означает, что TNamespace не может быть самостоятельным объектом.
Чтобы сделать внутренний класс как в С++, есть какой-то другой синтаксис или это невозможно?

А вообще такую радость можно и в плюсах легко сотворить:
struct TParent
{
  string FCount;
  
  struct TNamespace
  {
    TParent& p;
    string Func() { return "Namespace: " + p.FCount; }
  };
  struct TOtherNamespace
  {
    TParent& p;
    string Func() { return "Other namespace: " + p.FCount; }
  };
  
  TNamespace GetNamespace() { TNamespace ret = {*this}; return ret; }
  TOtherNamespace GetOtherNamespace() { TOtherNamespace ret = {*this}; return ret; }
};
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[11]: namespace'ы в классах
От: Privalov  
Дата: 06.02.12 07:46
Оценка:
Здравствуйте, netch80, Вы писали:

N>При наличии SCM (её использовании как держателя кода проекта) и при её использовании участниками автор кода был бы найден сразу, также опознано, соответствует ли изменение содержанию комментария коммита, и если да — то логике. И тогда вопрос был бы не "Кто это сделал и зачем?", а "Ш-н, объясни, зачем это и откуда?"


Вопрос был задан 12.03.05. Ответ пришел 14.03.05. За это время любой вменяемый разработчик способен вспомнить, что и зачем он делал. Так что ответ "Но что я там и как делал даже для меня теперь тайна на сей день" неприемлем даже здесь.
Re[15]: namespace'ы в классах
От: hattab  
Дата: 06.02.12 08:09
Оценка:
Здравствуйте, jazzer, Вы писали:

j> Хотел спросить, что это за язык, но судя по тегам, это паскаль


Это Delphi. Nested Types поддерживаются с 2005.

j> Т.е. здесь я вижу, что объект TNamespace — это всегда подобъект TParent и поэтому внутри TNamespace всегда можно конвертнуть Self в TParent.

j> А это, в свою очередь, означает, что TNamespace не может быть самостоятельным объектом.
j> Чтобы сделать внутренний класс как в С++, есть какой-то другой синтаксис или это невозможно?

Это и есть внутренние классы. У дельфей ссылочная модель объектов — любой объект указатель. Поэтому всегда можно любой объект небезопасно привести к любому другому. Т.к. тут в задачи неймспейсов не входит хранение состояния, то нет и смысла эти объекты реально создавать (хотя сделать это конечно можно, и они будут самостоятельными). Это просто трюкачество
avalon 1.0rc3 build 428, zlib 1.2.3
Re[6]: И снова про ц++
От: jazzer Россия Skype: enerjazzer
Дата: 06.02.12 09:35
Оценка:
Здравствуйте, Mamut, Вы писали:

M>>>>>И при этом ты поносишь браузеры и IDE, которые на этом самом С++ написаны. Нуну.

M>И про ФФ с Хромом.
Надо полагать, есть написанные на жаве браузеры, которые при той же функциональности работают в 128 раз быстрее и жрут в 256 раз меньше


S>>std::wstring?


M>И в любом случае они, в основном, позволяют хранить и выводить текст, но не позволяют других манипуляций. Не говоря уже о «удобстве» иметь два набора функций для манипуляции типа strlen и wcslen и т.п.


если ты юзаешь (w)string, то надо просто позвать у него метод size(), никаких двух наборов тут нет
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[10]: И снова про ц++
От: okman Беларусь https://searchinform.ru/
Дата: 06.02.12 09:54
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


Расслабься, сверхчеловек.
Re[6]: И снова про ц++
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 06.02.12 10:19
Оценка:
Здравствуйте, _d_m_, Вы писали:

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


N>>Не-а. Нормальная модульность была бы, если бы можно было отделить объявления от того, что их реализует. Например, есть модуль — вот вам список функций в нём, а сами функции где-то в другом месте. Никакая Java такого не умеет и не собирается, хочешь взять определения откуда-то — изволь принести полную реализацию. А заголовочные файлы для C/C++ хоть и бардачны, но позволяют именно это — в них только объявления функций, определения констант и enum'ов и тому подобное.


___>Да ты што! Открой для себя интерфейсы C#.


Тут уже рассказали, что в последних версиях это как-то реализовано (хоть и без подробностей). Что ж, могу поздравить — лучше позже, чем никому.

___> А заголовочные файлы — говно полное.


Какое взвешенное, обоснованное и корректное утверждение.
The God is real, unless declared integer.
Re[8]: И снова про ц++
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 06.02.12 10:34
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Без возможности динамической загрузки это не модульность, а профанация.

N>>Эта модульность не мешает динамической загрузке.
НС>Эта, она не мешает. Только вот без кроссплатформенного ABI нормальной модульности в С++ нет, есть только извращения типа СОМ или CORBA, требующие море обвязочного кода.

Кроссплатформенный это в данном случае между разными видами процессоров или между разными компиляторами?

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

НС>Для модульности — нужна, а вообще конечно не обязательна.
N>> Например, она нафиг не нужна в железном раутере, в автомобильном инжекторе, или в карточке в кармане — в общем, там, где код целиком в (П)ПЗУ.
НС>Ага, еще в АЭС, да.

Тип установки в целом тут мало влияет — на той же АЭС есть наверняка и система доступа охраны с учётом на чём-то весьма прикладном, и бухгалтерия на 1С, и ещё много чего.

НС>>>Кто тебе такую глупость сказал? И в джаве в любом случае интерфейс будет отдельным модулем от его реализации,

N>>Что-то не замечал ни разу.
НС>А тут и замечать нечего. Джавовский интерфейс (который интерфейс как сущность) обязательно будет в отдельном файле с независимой загрузкой.

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

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

N>>Что можно — уже хорошо. А кто-то это реально делает — так, чтобы поставлять от продукта отдельно эти метаданные?
НС>МС сам делает. Для компилятора собственно исполняемый код не нужен, вот и отрезают его нафик.

N>>Если ты привык к тем кошмарам, что зовутся ассемблерами в Dos/Windows мире, могу только посочувствовать, но в общем случае и там было стандартной практикой подключать файлы всяких макроопределений.

НС>Так и пиши — макроассемблер.

А что, последние 40 лет существуют какие-то другие (за пределами консольных и встроенных отладчиков)? Любой ассемблер, оформленный явно как отдельная тулза или в составе средств сборки (как GNU binutils), содержит макросредства.

НС>>>Не самые популярные на сегодняшний день языки.

N>>А при чём тут вообще фактор популярности?
НС>А при чем тут, цитирую: "Зато подход с заголовочными описаниями распространяется практически на все языки"?

Это не вопрос популярности, а вопрос принципиальной возможности распространения.

НС>>>Нет. Как минимум нужен минимальный синтаксис инициализации:

НС>>>
НС>>>obj.MySignal = FooMethod;
НС>>>


N>>
N>>obj.addSignal(MySignal, FooMethod);
N>>


N>>Разве это настолько хуже, чтобы требовался синтаксис твоего варианта?


НС>Да, это хуже.


Чем?

НС> Ну и с указателем на метод в С++ тоже не все шоколадно. Примерчик то можно и подправить слегка:

НС>
НС>obj1.MySignal = obj2.FooMethod;
НС>obj3.MySignal = x => obj4.FooMethod(x + 4);
НС>


Это вопрос построения тех же замыканий.

N>>А что в твоём случае будет, если в объекте будет несколько таких маппингов сигналов на слоты?


НС>Что значит несколько? Мультикаст что ли?


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

НС>>>Не обязательно замыкания реализовывать в лоб. Дотнет вполне справляется и без двиганья регистров.

N>>Покажи код (на его внутреннем языке)

НС>
НС>var x = 4;
НС>Func<int, int> inc = i => i + x;
НС>


НС>
НС>IL_0007:  ldloc.1
НС>IL_0008:  ldc.i4.4
НС>IL_0009:  stfld      int32 ClosureTest.Program/'<>c__DisplayClass1'::x
НС>IL_000e:  ldloc.1
НС>IL_000f:  ldftn      instance int32 ClosureTest.Program/'<>c__DisplayClass1'::'<Main>b__0'(int32)
НС>IL_0015:  newobj     instance void class [mscorlib]System.Func`2<int32,int32>::.ctor(object,
НС>                                                                                     native int)
НС>


Это код генерации, а я имел в виду код сгенерированного после new, или метода реализации вызова. Судя по этому коду, оно создаёт объект-помощник и заполняет его данные указанием, что и как вызывать при дёргании вызова.
Такое возможно и на C++, если сделать объект, который фиксирует данные о том, как распределены аргументы в исходном вызове, сколько и каких вдвигается и указатель на исходную функцию; но могут быть проблемы с его оформлением для компилятора, и любой такой вызов всё равно менее эффективен, чем порция сгенерированного кода.
The God is real, unless declared integer.
Re[11]: И снова про ц++
От: Ops Россия  
Дата: 06.02.12 11:14
Оценка:
Здравствуйте, enji, Вы писали:

E>А я вот ни разу с такими не сталкивался, разный опыт видимо Ну и опять же, куча программ, которыми я пользуюсь, написана на с++. Лиспа я на десктопе что-то и не встречал. Про лисп на вебе я тож не слышал. Слышал, что был макроязык в автокаде (вроде бы) на основе лиспа. Но вроде как туда в конце концов всунули вба.


Lisp на десктопе — это как минимум emacs.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[2]: Подытожим?
От: neFormal Россия  
Дата: 06.02.12 11:26
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Чтож, печально все. Основным минусом плюсов, как выясняется, является его мощность и универсальность.


основным минусом является сложность, растущая достаточно быстро при росте проекта..

S>Программисты боятся

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



S>А также выделением на первых порах большего времени на поиски багов.




почему ты не назвал более тривиальных и полезных вещей вроде автоматического тестирования?
толсто же, ну..
...coding for chaos...
Re[4]: Подытожим?
От: neFormal Россия  
Дата: 06.02.12 14:05
Оценка:
Здравствуйте, Ops, Вы писали:

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

Ops>При хорошей начальной архитектуре сложность неособо-то и растет.

плюсы неплохо живут, если рефакторинга мало.. в большом проекте при переделках сильно возрастает вероятность ошибки, уследить за всем становится трудно..
конечно, тут играет огромное значение архитектура, но также оказывают влияние иные факторы, как усталость автора, отвлекающие факторы, внимательность.. та же java менее требовательна к отсутствию "иных факторов", поэтому случайного выпадения в корку там не выйдет.. и отлаживать проще..
можно поспорить на тему личных качеств кодеров, но работу надо делать при любых условиях.. чем меньше возможностей сделать фатальную ошибку, тем лучше для продукта..
а написание кода на жаве и плюсах в схожем стиле (си с классами плюс немного макросни и шаблонов/бузда) практически ничем не отличается.. хотя временем компиляции

Ops>А если архитектура гавно, то ее никакой язык не спасет.


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

F>>почему ты не назвал более тривиальных и полезных вещей вроде автоматического тестирования?

Ops>Я что-то не заметил в топике ни одного поста про это.

а топик тут при чём?
Sheridan "открыл всем глаза" на то, как добиться лучшего качества плюсового кода.. что ж, поверим его солидному опыту..
мне же интересно, почему в списке средств улучшения нет тестов или хотя бы хорошей среды, которая подскажет тривиальные ошибки?
...coding for chaos...
Re[7]: И снова про ц++
От: Mamut Швеция http://dmitriid.com
Дата: 06.02.12 15:52
Оценка:
S>>>std::wstring?

M>>И в любом случае они, в основном, позволяют хранить и выводить текст, но не позволяют других манипуляций. Не говоря уже о «удобстве» иметь два набора функций для манипуляции типа strlen и wcslen и т.п.


J>если ты юзаешь (w)string, то надо просто позвать у него метод size(), никаких двух наборов тут нет


То есть strlen и ecslen мне приснились?


dmitriid.comGitHubLinkedIn
Re[2]: Подытожим?
От: Mamut Швеция http://dmitriid.com
Дата: 06.02.12 15:55
Оценка:
S>Чтож, печально все. Основным минусом плюсов, как выясняется, является его мощность и универсальность.
S>Программисты боятся
S>а) дефайнов
S>б) указателей
S>Также программистам неудобно программировать на плюсах ввиду отсутствия в нем некоторых ништяков, к которым они привыкли.

Если слушать только голоса в своей голове, как это делаешь ты, то да, к таким выводам можно прийти

S>Обе первые болезни вполне успешно лечатся изучением самого языка и предметной области более плотно. А также выделением на первых порах большего времени на поиски багов. Третья болезнь иногда может вылечиться реализацией отсутствующего функционала самостоятельно. Но чаще всего это просто некая привычка.

S>Как говорил товарищь Прутков — "зри в корень". И то и другое и третье имеют общий корень и имя ему — "лень"

Если слушать только голоса в своей голове, как это делаешь ты, то да, к такому выводу можно прийти


dmitriid.comGitHubLinkedIn
Re[13]: И снова про ц++
От: Mamut Швеция http://dmitriid.com
Дата: 06.02.12 16:14
Оценка:
O>>>Эдак можно прийти к выводу, что linux тоже в глубоком ауте из-за разнообразия версий.
O>>>А на самом деле обилие реализаций всего лишь отражает широту круга задач, которые ими решаются.

M>>Нет, не отражают. Отражает только ровно один факт: в С++ нет нормального способа работать со строками. Все эти QString/CString/*string'и процентов на 80-90 ублируют функцинальность друг друга.


O>Не повторяйте себя.

O>Критерий нормальности строк мы уже обсудили.

Я не повторяюсь. Я описываю реальность, данную нам в ощущениях ©

А реальность такова:
— в языках, где String реализован, в подавляющем большинстве случаев используется встроенный. Если сильно надо, реализуется свой.
— в С++ в подавляющем большинстве случаев используется тот или иной велосипед, на 80=100% повторяющий возможности других велосипедов, но при этом с ними не совместимый.


dmitriid.comGitHubLinkedIn
Re[14]: И снова про ц++
От: okman Беларусь https://searchinform.ru/
Дата: 06.02.12 17:42
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Я не повторяюсь. Я описываю реальность, данную нам в ощущениях ©


Мрак.

M>- в языках, где String реализован, в подавляющем большинстве случаев используется встроенный.


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

M>- в С++ в подавляющем большинстве случаев используется тот или иной велосипед, на 80=100% повторяющий возможности других велосипедов, но при этом с ними не совместимый.


Остальные 20 процентов — уникальные свойства, позволяющие идеально вписаться в требования.
Re[7]: И снова про ц++
От: Ночной Смотрящий Россия  
Дата: 06.02.12 17:49
Оценка:
Здравствуйте, netch80, Вы писали:

___>>Да ты што! Открой для себя интерфейсы C#.


N>Тут уже рассказали, что в последних версиях это как-то реализовано (хоть и без подробностей). Что ж, могу поздравить — лучше позже, чем никому.


Интерфейсы как отдельные сущности доступны и в джаве и в дотнете с самых первых версий.
Re[9]: И снова про ц++
От: Ночной Смотрящий Россия  
Дата: 06.02.12 17:49
Оценка:
Здравствуйте, netch80, Вы писали:

НС>>Эта, она не мешает. Только вот без кроссплатформенного ABI нормальной модульности в С++ нет, есть только извращения типа СОМ или CORBA, требующие море обвязочного кода.


N>Кроссплатформенный это в данном случае между разными видами процессоров или между разными компиляторами?


И то и то.

НС>>А тут и замечать нечего. Джавовский интерфейс (который интерфейс как сущность) обязательно будет в отдельном файле с независимой загрузкой.


N>То есть он будет кодом, который будет звать реальный код, явно загрузив его?


Нет, интерфейс никаким кодом не является. Это метаданные в чистом виде.

N>>>А при чём тут вообще фактор популярности?

НС>>А при чем тут, цитирую: "Зато подход с заголовочными описаниями распространяется практически на все языки"?
N>Это не вопрос популярности, а вопрос принципиальной возможности распространения.

Попробуй сказать то же самое по русски.

N>>>Разве это настолько хуже, чтобы требовался синтаксис твоего варианта?

НС>>Да, это хуже.
N>Чем?

Больше писанины, сложнее читать.

N>Это вопрос построения тех же замыканий.


Эти вопросы, конечно же, связаны. Тем хуже для С++.

НС>>Что значит несколько? Мультикаст что ли?

N>Нет. Мультикаст это фича даже не одного маппинга, а одного сигнала, а я про несколько разных отображений.

Тогда непонятно.

НС>>
НС>>var x = 4;
НС>>Func<int, int> inc = i => i + x;
НС>>


НС>>
НС>>IL_0007:  ldloc.1
НС>>IL_0008:  ldc.i4.4
НС>>IL_0009:  stfld      int32 ClosureTest.Program/'<>c__DisplayClass1'::x
НС>>IL_000e:  ldloc.1
НС>>IL_000f:  ldftn      instance int32 ClosureTest.Program/'<>c__DisplayClass1'::'<Main>b__0'(int32)
НС>>IL_0015:  newobj     instance void class [mscorlib]System.Func`2<int32,int32>::.ctor(object,
НС>>                                                                                     native int)
НС>>


N>Это код генерации, а я имел в виду код сгенерированного после new, или метода реализации вызова.


А что, есть какие то проблемы с пониманием того, что там будет сгенерено? Вызов '<>c__DisplayClass1'::'<Main>b__0'(int32), самый обычный.

N> Судя по этому коду, оно создаёт объект-помощник


Да.

N> и заполняет его данные указанием, что и как вызывать при дёргании вызова.


Не совсем так. Поля помощника заменяют локальные переменные, участвующие в замыкании. Это все, никаких специальных указаний.

N>Такое возможно и на C++


Разумеется. Об этом и речь.

N>, если сделать объект, который фиксирует данные о том, как распределены аргументы в исходном вызове, сколько и каких вдвигается и указатель на исходную функцию


Опять непонятно. Нет там никакой хитрости, просто замена внешних переменных на поля хелпера.
Re[11]: namespace'ы в классах
От: Ночной Смотрящий Россия  
Дата: 06.02.12 17:54
Оценка:
Здравствуйте, netch80, Вы писали:

НС>>А разве там не использовался Subversion, а потом Hg?


N>Не знаю.


Но уже сделал далеко идущие выводы.

НС>> Или это все невнятные?

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

Ну так можешь учесть простой факт — SCM там с рождения проекта есть.

НС>> Сдается мне, это был риторический вопрос.

N>Который именно?

Про то, кто это сделал.
Re[8]: И снова про ц++
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 06.02.12 18:09
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

___>>>Да ты што! Открой для себя интерфейсы C#.

N>>Тут уже рассказали, что в последних версиях это как-то реализовано (хоть и без подробностей). Что ж, могу поздравить — лучше позже, чем никому.
НС>Интерфейсы как отдельные сущности доступны и в джаве и в дотнете с самых первых версий.

А, эти интерфейсы... Понятно, но я такое считаю решением только наполовину, потому что требуют дополнительной прокладки в виде отдельного класса.
Хотя если их наличие обязательно для принятого стиля написания, то сойдёт.
The God is real, unless declared integer.
Re[10]: И снова про ц++
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 06.02.12 18:18
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Эта, она не мешает. Только вот без кроссплатформенного ABI нормальной модульности в С++ нет, есть только извращения типа СОМ или CORBA, требующие море обвязочного кода.

N>>Кроссплатформенный это в данном случае между разными видами процессоров или между разными компиляторами?
НС>И то и то.

И то и то не получится. Потому что между разными компиляторами оно ещё как-то реализуется, то между платформами в пределах одного процессора как-то нереально пока что.

НС>>>А тут и замечать нечего. Джавовский интерфейс (который интерфейс как сущность) обязательно будет в отдельном файле с независимой загрузкой.

N>>То есть он будет кодом, который будет звать реальный код, явно загрузив его?
НС>Нет, интерфейс никаким кодом не является. Это метаданные в чистом виде.

Я уже понял, о каком интерфейсе идёт речь, по соседнему письму. См. комментарии на него.

N>>>>А при чём тут вообще фактор популярности?

НС>>>А при чем тут, цитирую: "Зато подход с заголовочными описаниями распространяется практически на все языки"?
N>>Это не вопрос популярности, а вопрос принципиальной возможности распространения.
НС>Попробуй сказать то же самое по русски.

Это было по-русски. Попробуй прочитать ещё раз.

N>>>>Разве это настолько хуже, чтобы требовался синтаксис твоего варианта?

НС>>>Да, это хуже.
N>>Чем?
НС>Больше писанины, сложнее читать.

Мне — легче читать. Потому что назначение по твоему варианту сразу вызывает сомнения, что делают сигналы в пространстве имён методов класса и не дерутся ли они там с кем-то. А добавка одного слова — не так сложно.

НС>>>Что значит несколько? Мультикаст что ли?

N>>Нет. Мультикаст это фича даже не одного маппинга, а одного сигнала, а я про несколько разных отображений.
НС>Тогда непонятно.

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

НС>Опять непонятно. Нет там никакой хитрости, просто замена внешних переменных на поля хелпера.


Это то же самое, но другими словами. Тут вопросов нет.
The God is real, unless declared integer.
Re[9]: И снова про ц++
От: Ночной Смотрящий Россия  
Дата: 06.02.12 18:36
Оценка:
Здравствуйте, netch80, Вы писали:

N>А, эти интерфейсы... Понятно, но я такое считаю решением только наполовину, потому что требуют дополнительной прокладки в виде отдельного класса.


Какого такого отдельного класса?
Re[11]: И снова про ц++
От: Ночной Смотрящий Россия  
Дата: 06.02.12 18:36
Оценка:
Здравствуйте, netch80, Вы писали:

N>И то и то не получится.


У джавы получилось.

N>>>>>А при чём тут вообще фактор популярности?

НС>>>>А при чем тут, цитирую: "Зато подход с заголовочными описаниями распространяется практически на все языки"?
N>>>Это не вопрос популярности, а вопрос принципиальной возможности распространения.
НС>>Попробуй сказать то же самое по русски.

N>Это было по-русски. Попробуй прочитать ещё раз.


Пробовал. Распарсить не смог.

N>Мне — легче читать. Потому что назначение по твоему варианту сразу вызывает сомнения, что делают сигналы в пространстве имён методов класса и не дерутся ли они там с кем-то.


Ужас то какой. И как дотнет с эвентами живет?

N> А добавка одного слова — не так сложно.


Это пока примерчики примитивные. А когда попытаешься что то вроде Rx реализовать, мусор зальет все.

N>>>Нет. Мультикаст это фича даже не одного маппинга, а одного сигнала, а я про несколько разных отображений.

НС>>Тогда непонятно.

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


Зачем такой изврат? Сигнал должен присутствовать в метаданных и статически контроллироваться компилятором, а не фигурировать в каких то словарях. Соответственно и никаких описанных тобой проблем не будет. Как нет их в джавовских рукопашных лисенерах и дотнетовских эвентах.
Re[10]: namespace'ы в классах
От: Sheridan Россия  
Дата: 06.02.12 19:44
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Другие участники почему то говорят иное. И всю твою химию со string.Format из исходников тщательно выпилили. Можно было бы, конечно, списать на глупых разработчиков янусовых, но ведь в Авалоне все повторилось с точностью до деталей. А это уже тенденция — ты абсолютно бесполезен как программист.


Когда люди чего-то не понимают — они от этого стараются избавиться.
Matrix has you...
Re[3]: Подытожим?
От: Sheridan Россия  
Дата: 06.02.12 19:45
Оценка:
Здравствуйте, aloch, Вы писали:

A>Зачастую именно ЛЕНЬ — это двигатель прогресса...


Зачастую, ага.
Matrix has you...
Re[14]: namespace'ы в классах
От: Sheridan Россия  
Дата: 06.02.12 19:48
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Это гениально. Ничего, что изначально вопрос был совсем про другое — это раз. И что вообще я говорил Шеридану про другое — это два


Как ты там говоришь про голоса в голове? Я все никак не запишу...


Невозможность создания namespace внутри класса (вспомните хотя-бы "главные оконные классы" разных библиотек — CWnd, QWidget... сотни методов, там разделение не помешало бы)

там
Автор: x-code
Дата: 03.02.12
Matrix has you...
Re[8]: И снова про ц++
От: Sheridan Россия  
Дата: 06.02.12 19:57
Оценка:
Здравствуйте, Философ, Вы писали:

S>>Возможно. Только ц++ всетаки популярнее...

Ф>пока, к сожалению
Крепись...
Matrix has you...
Re[13]: namespace'ы в классах
От: Privalov  
Дата: 06.02.12 20:02
Оценка:
Здравствуйте, netch80, Вы писали:

N>Категорически не согласен. Когда вопрос был задан — не имеет значения. Имеет значение, когда вопрос был прочтён и начат к разбору по существу (в данном случае этот юридический термин подходит лучше всего).


Для спрашивающего имеет значение только содержание ответа.

N>Когда у нас всё "горит", я могу неделями на RSDN не заглядывать, и что — это потом будет значить, что я по две неделю ищу ответ на простой вопрос (или ночами не сплю, думая, как бы извернуться и прищучить собеседника, если начался спор с вывертами)?


Но ты и не пишешь первое, что придет в голову.

N>Такого рода отношение к проекту, в котором участвуешь, неприемлемо как для меня, независимо от того, он платный, бесплатный, открытый, или какой-то ещё.


Целая толпа народу пытается объяснить это мсье д'Артаньяну черт знает сколько времени.
Re[11]: namespace'ы в классах
От: Privalov  
Дата: 06.02.12 20:03
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Когда люди чего-то не понимают — они от этого стараются избавиться.


Ты всегда действуешь таким образим?
Re[15]: namespace'ы в классах
От: Mamut Швеция http://dmitriid.com
Дата: 06.02.12 20:05
Оценка:
M>>Это гениально. Ничего, что изначально вопрос был совсем про другое — это раз. И что вообще я говорил Шеридану про другое — это два

S>Как ты там говоришь про голоса в голове? Я все никак не запишу...



S>

S>Невозможность создания namespace внутри класса (вспомните хотя-бы "главные оконные классы" разных библиотек — CWnd, QWidget... сотни методов, там разделение не помешало бы)

S>там
Автор: x-code
Дата: 03.02.12


Потом ты показал решение, про которое я сказал что?

То, что ты «нарисовал» — это страшный страх и ужасный ужас со всех сторон — от читаемости до поддержки в будущем


Что предложил jazzer?

Продемонстрируй решение проблемы "автокомплит по группам методов" на других языках


Каким образом вопрос jazzer'а относится к предыдущим двум цитатам?


dmitriid.comGitHubLinkedIn
Re[14]: И снова про ц++
От: Sheridan Россия  
Дата: 06.02.12 20:05
Оценка:
Здравствуйте, Cadet, Вы писали:

C>Да-да. Ты еще найди такую пасхалку в большом проекте. Она к примеру может хитро использоваться совместно с макросом __DATE__, и стрельнуть примерно через полгода после коммита.

__DATE__ — это строка, в которой записана дата компиляция файла. Как ее можно использовать для "стрельнуть" — непонятно.
Matrix has you...
Re[5]: Подытожим?
От: Sheridan Россия  
Дата: 06.02.12 20:09
Оценка:
Здравствуйте, neFormal, Вы писали:

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

Верно. И про любой другой язык точно также верно.

F>а топик тут при чём?

F>Sheridan "открыл всем глаза" на то, как добиться лучшего качества плюсового кода.. что ж, поверим его солидному опыту..
Это где я там глаза кому открывал? Всего лишь называю все своими именами.
Matrix has you...
Re[23]: namespace'ы в классах
От: Mamut Швеция http://dmitriid.com
Дата: 06.02.12 20:15
Оценка:
M>>>>Итак, повторяю вопрос: нахрена тебе что-то объяснять, если ты не знаешь и знать не хочешь?
S>>>Примеры будут? Или слив засчитаем таки? Код покажешь или продолжишь воздух сотрясать?

M>>Сотрясает воздух здесь ровно один человек: ты.


M>>Миксины: http://en.wikipedia.org/wiki/Mixin

M>>Extension methods: http://msdn.microsoft.com/en-us/library/bb383977.aspx
M>>Partial classes and methods: http://msdn.microsoft.com/en-us/library/wa80x488.aspx

M>>Но тебе эти ссылки будут бесполезны: ты не способен понять, о чем в них говорится


S>Во всех трех так или иначе говорится о расширении существующего функционала классов, я правильно понимаю?


S>В любом случае я нацеливался на следующее поведение:

S>Если я изначально понял задачу — была жалоба на отсутствие неймспейсов внутри класса и вследствии этого неудобство использования данных классов, ежели в них over9k методов изза отсутствия возможности объединения схожих.
S>То что я реализовал — позволит разбить методы на группы и каждую группу положить в свой неймспейс, что потом при автокомплите не ковыряться, а сначала выбирать неймспейс, затем метод. Например widget->orientation->setPos() или socket->exchange->send() или database->query->execute()
S>И насколько я понимаю — чтото похожее на неймспейсы классов реализуется только в Partial classes and methods. И то — мне интересно как будет себя вести автокомплит в данном случае.

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

Изначально жалоба была следующей:

Невозможность создания namespace внутри класса (вспомните хотя-бы "главные оконные классы" разных библиотек — CWnd, QWidget... сотни методов, там разделение не помешало бы)


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

И extension methods и partial declarations это позволяют сделать. То, что это не выглядит так, как сделано в твоем решении — абсолютно нормально, потому что это — другое решение.

В любом случае автокомплит должен работать нормально. В C# типизация статическая, то есть информация о том, каке методы в данный момент доступны известны заранее.


dmitriid.comGitHubLinkedIn
Re[12]: так.
От: Sheridan Россия  
Дата: 06.02.12 20:16
Оценка:
Здравствуйте, Privalov, Вы писали:

S>>Когда люди чего-то не понимают — они от этого стараются избавиться.

P>Ты всегда действуешь таким образим?

Ну давай, покажи мне мои ошибки в моем коде. Именно мои и именно ошибки. Именно в том коде, который выкидывали. Давай. Без всякого "это неподдерживаемо" или "так не модно".
Покажи. Ошибки. В. Моем. Коде.

Любой просий ответ сюда требую считать сливом, ибо мне надоело твое постоянное съезжание на "шеридан — идиот".
И кстати, я до сих пор не видел реализации неймспейсов класса от тебя. Но это — в другом топике. Тут — мои ошибки в том коде который мой и который выкинули. Давай.
Matrix has you...
Re[15]: И снова про ц++
От: Mamut Швеция http://dmitriid.com
Дата: 06.02.12 20:18
Оценка:
Здравствуйте, okman, Вы писали:

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


M>>Я не повторяюсь. Я описываю реальность, данную нам в ощущениях ©


O>Мрак.


M>>- в языках, где String реализован, в подавляющем большинстве случаев используется встроенный.


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


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

В практическом смысле то означает:

в подавляющем большинстве случаев используется встроенный. Если сильно надо, реализуется свой.


Это про отвертку

M>>- в С++ в подавляющем большинстве случаев используется тот или иной велосипед, на 80=100% повторяющий возможности других велосипедов, но при этом с ними не совместимый.


O>Остальные 20 процентов — уникальные свойства, позволяющие идеально вписаться в требования.


Нет там уникальных свойств с требованиями. Остальное — это особенности того или иного велосипедостроителя


dmitriid.comGitHubLinkedIn
Re[6]: Подытожим?
От: Mamut Швеция http://dmitriid.com
Дата: 06.02.12 20:20
Оценка:
F>>а топик тут при чём?
F>>Sheridan "открыл всем глаза" на то, как добиться лучшего качества плюсового кода.. что ж, поверим его солидному опыту..
S>Это где я там глаза кому открывал? Всего лишь называю все своими именами.

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

Потому что:
— ты не программист (с) ты же
— у тебя ноль опыта в командной разработке

Откуда у тебя появится знание об именах?


dmitriid.comGitHubLinkedIn
Re[13]: так.
От: Privalov  
Дата: 06.02.12 20:20
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Любой просий ответ сюда требую считать сливом, ибо мне надоело твое постоянное съезжание на "шеридан — идиот".


Ссылку на мое сообщение, где я так сказал. Хотя бы одно. Иначе — слив.

Я уже не говорю, что твой ответ не имеет никакого отношения к поставленному мной вопросу.
Re[16]: да ладно?? о0
От: Sheridan Россия  
Дата: 06.02.12 20:23
Оценка:
Здравствуйте, Mamut, Вы писали:

S>>

S>>Невозможность создания namespace внутри класса (вспомните хотя-бы "главные оконные классы" разных библиотек — CWnd, QWidget... сотни методов, там разделение не помешало бы)

S>>там
Автор: x-code
Дата: 03.02.12


M>Потом ты показал решение, про которое я сказал что?

M>

M>То, что ты «нарисовал» — это страшный страх и ужасный ужас со всех сторон — от читаемости до поддержки в будущем


M>Что предложил jazzer?

M>

M> Продемонстрируй решение проблемы "автокомплит по группам методов" на других языках


M>Каким образом вопрос jazzer'а относится к предыдущим двум цитатам?


Да ладно? Ты правда думаешь что неймспейсы он захотел чтобы компилятору было легче?
Matrix has you...
Re[14]: Прошу прощения...
От: Sheridan Россия  
Дата: 06.02.12 20:24
Оценка:
Здравствуйте, Privalov, Вы писали:

S>>Любой просий ответ сюда требую считать сливом, ибо мне надоело твое постоянное съезжание на "шеридан — идиот".

P>Ссылку на мое сообщение, где я так сказал. Хотя бы одно. Иначе — слив.

Упс, прошу прощения. Я тебя с Мамутом перепутал несколько. Разрешай дать подзатыльник.
Matrix has you...
Re[17]: да ладно?? о0
От: Mamut Швеция http://dmitriid.com
Дата: 06.02.12 20:30
Оценка:
S>>>

S>>>Невозможность создания namespace внутри класса (вспомните хотя-бы "главные оконные классы" разных библиотек — CWnd, QWidget... сотни методов, там разделение не помешало бы)

S>>>там
Автор: x-code
Дата: 03.02.12


M>>Потом ты показал решение, про которое я сказал что?

M>>

M>>То, что ты «нарисовал» — это страшный страх и ужасный ужас со всех сторон — от читаемости до поддержки в будущем


M>>Что предложил jazzer?

M>>

M>> Продемонстрируй решение проблемы "автокомплит по группам методов" на других языках


M>>Каким образом вопрос jazzer'а относится к предыдущим двум цитатам?


S>Да ладно? Ты правда думаешь что неймспейсы он захотел чтобы компилятору было легче?


К вопросу о голосах. Где ты тут увидел, чтобы я говорил про компилятор?


dmitriid.comGitHubLinkedIn
Re[7]: Подытожим?
От: Sheridan Россия  
Дата: 06.02.12 20:36
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Откуда у тебя появится знание об именах?


А как еще можно относиться к фразе "это трудно поддерживается"? Вот смотри: Поддерживается? Да, поддерживается, но трудно. Нелегко. То есть поддерживается при условии более усердного труда. Следовательно прослеживается стремление трудиться меньше, раз возможности отметаются такой вот фразой. А вот стремление трудится меньше как раз и есть — лень.
Ты можешь возразить — "нооо каааакже, тут не лень, а стремление сделать больше за освободившееся время!!" и будешь прав где то процентов на 20. Остальные 80 — лень. Просто природа человека такая.

Ну а про 20 я не вспоминал до последнего момента оттого, что форум такой. Эти 20 сюда вряд ли попадут.

зы Ну ты в курсе про принцип Парето, да?
Matrix has you...
Re[18]: да ладно?? о0
От: Sheridan Россия  
Дата: 06.02.12 20:39
Оценка:
Здравствуйте, Mamut, Вы писали:

M>>>Каким образом вопрос jazzer'а относится к предыдущим двум цитатам?

S>>Да ладно? Ты правда думаешь что неймспейсы он захотел чтобы компилятору было легче?
M>К вопросу о голосах. Где ты тут увидел, чтобы я говорил про компилятор?

Эй, это я начал говорить про компилятор. И задал тебе вполне конкретный и имеющий смысл вопрос. Если ты его прочитаешь и подумаешь немного — ты поймешь, почему про неймспейсы в классах можно рассматривать практически исключительно как удобства именно программиста.
Matrix has you...
Re[18]: namespace'ы в классах
От: hattab  
Дата: 06.02.12 20:46
Оценка:
Здравствуйте, Mamut, Вы писали:

M> Тогда хз. Это, по-моему, вообще мало где реализуемо


Два варианта уже есть
avalon 1.0rc3 build 428, zlib 1.2.3
Re[12]: namespace'ы в классах
От: Sheridan Россия  
Дата: 06.02.12 20:46
Оценка:
Здравствуйте, Privalov, Вы писали:

S>>Когда люди чего-то не понимают — они от этого стараются избавиться.


P>Ты всегда действуешь таким образим?


Давай сначала.
Каким образом? Говорю обидные вещи? Даю посмотреть на ситуацию под другими точками зрения? Что именно ты хочешь знать?
Matrix has you...
Re[18]: Оооо, алилуйа!!!
От: Sheridan Россия  
Дата: 06.02.12 20:48
Оценка:
Matrix has you...
Re[15]: Прошу прощения...
От: Privalov  
Дата: 06.02.12 20:49
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Упс, прошу прощения. Я тебя с Мамутом перепутал несколько. Разрешай дать подзатыльник.


Обвиняя меня в том, чего я не делал, ты наврал. А если так, то и все твои остальные сообщения за чистую монету я принять не могу. Извини, но доверие, как и жизнь, теряется один раз.
Re[19]: да ладно?? о0
От: Mamut Швеция http://dmitriid.com
Дата: 06.02.12 20:49
Оценка:
M>>>>Каким образом вопрос jazzer'а относится к предыдущим двум цитатам?
S>>>Да ладно? Ты правда думаешь что неймспейсы он захотел чтобы компилятору было легче?
M>>К вопросу о голосах. Где ты тут увидел, чтобы я говорил про компилятор?

S>Эй, это я начал говорить про компилятор.


Правильно. Какое отношение имеет компилятор к процитированному мной? Никакого. Особенно в свете тут
Автор: Mamut
Дата: 07.02.12
и тут
Автор: Mamut
Дата: 07.02.12


S>И задал тебе вполне конкретный и имеющий смысл вопрос. Если ты его прочитаешь и подумаешь немного — ты поймешь, почему про неймспейсы в классах можно рассматривать практически исключительно как удобства именно программиста.


При чем тут компилятор, и откуда он взялся?
Ты действтельно считаешь, что я не понимаю, что это для удобства программиста?


dmitriid.comGitHubLinkedIn
Re[9]: Подытожим?
От: Sheridan Россия  
Дата: 06.02.12 21:00
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Знаешь, чем я занимался вчера? Я писал ровно три строчки кода.....

И что, все совершенно без комментариев? Две недели — с нуля? Может вам по горячим следам ревью кода сотворить, пока помните что куда лезет?
Matrix has you...
Re[10]: Подытожим?
От: Mamut Швеция http://dmitriid.com
Дата: 06.02.12 21:05
Оценка:
M>>Знаешь, чем я занимался вчера? Я писал ровно три строчки кода.....
S>И что, все совершенно без комментариев?

Комментариев достаточно мало. Те, что есть, иногда выглядят так:

The description of external pclasses. These may be wrong.

// и дальше — описание, которое может быть правильным, а може — и нет


S>Две недели — с нуля? Может вам по горячим следам ревью кода сотворить, пока помните что куда лезет?


Последние полгода так и делается. И тот страх и ужес что ты написал его бы не прошел ни разу. Причины я указал.

Итак, еще раз вопрос: так какой у тебя опыт в разработке, говоришь?


dmitriid.comGitHubLinkedIn
Re[16]: Прошу прощения...
От: Sheridan Россия  
Дата: 06.02.12 21:08
Оценка:
Здравствуйте, Privalov, Вы писали:

P>Обвиняя меня в том, чего я не делал, ты наврал. А если так, то и все твои остальные сообщения за чистую монету я принять не могу. Извини, но доверие, как и жизнь, теряется один раз.

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


Перепутал вот почему:

Мелкий шрифт и длинные расстояния в таблице.
Matrix has you...
Re[20]: да ладно?? о0
От: Sheridan Россия  
Дата: 06.02.12 21:09
Оценка:
Да вроде бы уже разобрались
Автор: Mamut
Дата: 07.02.12
, не?
Matrix has you...
Re[19]: namespace'ы в классах
От: Sheridan Россия  
Дата: 06.02.12 21:10
Оценка:
Здравствуйте, hattab, Вы писали:

M>> Тогда хз. Это, по-моему, вообще мало где реализуемо

H>Два варианта уже есть

Кстати, оба — на нативных языках
Matrix has you...
Re[21]: да ладно?? о0
От: Mamut Швеция http://dmitriid.com
Дата: 06.02.12 21:11
Оценка:
S>Да вроде бы уже разобрались
Автор: Mamut
Дата: 07.02.12
, не?


В любом случае, при чем тут компилятор, я так и не понял. Но уже не суть важно.


dmitriid.comGitHubLinkedIn
Re[11]: Подытожим?
От: Sheridan Россия  
Дата: 06.02.12 21:21
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Итак, еще раз вопрос: так какой у тебя опыт в разработке, говоришь?

Ты ответ знаешь, для чего постоянно спрашиваешь?

По проекту — сочувствую.
Matrix has you...
Re[22]: да ладно?? о0
От: Sheridan Россия  
Дата: 06.02.12 21:28
Оценка:
Здравствуйте, Mamut, Вы писали:

S>>Да вроде бы уже разобрались
Автор: Mamut
Дата: 07.02.12
, не?


M>В любом случае, при чем тут компилятор, я так и не понял. Но уже не суть важно.


Блин, ну на поверхности же... Почитай сначала первую часть моей фразы:

Да ладно? Ты правда думаешь что неймспейсы он захотел

А потом вторую часть, после небольшого обдумывания первой:

чтобы компилятору было легче?

Чтобы тебе было легче, вот тебе подсказка для второй части фразы:
Matrix has you...
Re[20]: namespace'ы в классах
От: hattab  
Дата: 06.02.12 21:29
Оценка:
Здравствуйте, Sheridan, Вы писали:

S> M>> Тогда хз. Это, по-моему, вообще мало где реализуемо


S> H>Два варианта уже есть


S> Кстати, оба — на нативных языках


Ну, это уж точно не определяющий фактор А кстати, ты наследование неймспейсов в своей схеме сделаешь?
avalon 1.0rc3 build 428, zlib 1.2.3
Re[21]: namespace'ы в классах
От: Sheridan Россия  
Дата: 06.02.12 21:38
Оценка:
Здравствуйте, hattab, Вы писали:

H>Ну, это уж точно не определяющий фактор А кстати, ты наследование неймспейсов в своей схеме сделаешь?

Гммм... Влет не скажу. Завтра попробую выделить время, поэксперементировать. Я честно говоря не помню механизма наследования вложенного класса....
Matrix has you...
Re[12]: Подытожим?
От: Mamut Швеция http://dmitriid.com
Дата: 06.02.12 21:38
Оценка:
M>>Итак, еще раз вопрос: так какой у тебя опыт в разработке, говоришь?
S>Ты ответ знаешь, для чего постоянно спрашиваешь?

Чтобы ты наконец-то сам понял: все, что ты безапелляционно заявляешь про что-то, в чем у тебя 0 опыта и в чем ты не разбираешься, является полной чушью.

S>По проекту — сочувствую.


Зато "код короткий, понятный и отлаженный" (с)

ЗЫ. Комментарии все равно помогают не всегда. Часто комментарии говорят, что код делает, но не говорят, как и/или зачем. В итоге достаточно парочки таких, как ты с "вы все недартаньяны, мой код хорош", чтобы:
— такие хаки, артефакты, куски неявных решений стали плодиться по всему коду
Автор: Ikemefula
Дата: 06.02.12
(Ikemefula)
— разбирательство в коде стало занимать слишком много времени
Автор: Cadet
Дата: 06.02.12
(Cadet)
— в больших проектах поиск ошибок стал интересным занятием
Автор: Cadet
Дата: 03.02.12
(Cadet)
— начали насаждаться привычки, которые сложно искоренить
Автор: FR
Дата: 05.02.12
(FR)
— начали использоваться неявные, ненужные и затрудняющие разработку/поддержку возможности языка
Автор: Mamut
Дата: 05.02.12
(Я)
плодились
Автор: Sinclair
Дата: 06.02.12
неявные ошибки и учатки кода, на которые слишком много завязано, что приводит к невозможности нормального изменения этого участка кода или рефакторинга (Sinclair)

Итого, пять человек четко и внятно показали тебе, почему этот код плох, почему он не годится в production и к командной разработке и т.п. В итоге мне пришлось тебе вообще пример из личной, так сказать, жизни приводить.

Но нет, "мы все — тупые, ленивые программисты, которые не хотят рабоать, один ты д'Артаньян, потому что у тебя 0 опыта, но ты точно знаешь лучше всех" ибо:

ХОТЬ Я И ДЕВСТВЕННИК, НО Я ТО ЗНАЮ ЧТО СТАЛКИР КРУЧЕ СЕКСА. (с)



dmitriid.comGitHubLinkedIn
Re[23]: да ладно?? о0
От: Mamut Швеция http://dmitriid.com
Дата: 06.02.12 21:39
Оценка:
S>>>Да вроде бы уже разобрались
Автор: Mamut
Дата: 07.02.12
, не?


M>>В любом случае, при чем тут компилятор, я так и не понял. Но уже не суть важно.


S>Блин, ну на поверхности же... Почитай сначала первую часть моей фразы:

S>

S>Да ладно? Ты правда думаешь что неймспейсы он захотел

S>А потом вторую часть, после небольшого обдумывания первой:
S>

S>чтобы компилятору было легче?

S>Чтобы тебе было легче, вот тебе подсказка для второй части фразы:
S>http://data.whicdn.com/images/12177979/sarcasmo-leonard_thumb.jpg

Звязь этого вопроса с процитированным все равно не прослеживается даже близко


dmitriid.comGitHubLinkedIn
Re[22]: namespace'ы в классах
От: hattab  
Дата: 06.02.12 21:45
Оценка:
Здравствуйте, Sheridan, Вы писали:

S> H>Ну, это уж точно не определяющий фактор А кстати, ты наследование неймспейсов в своей схеме сделаешь?


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


На дельфях легко
avalon 1.0rc3 build 428, zlib 1.2.3
Re[13]: Подытожим?
От: Sheridan Россия  
Дата: 06.02.12 21:51
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Итого, пять человек четко и внятно показали тебе, почему этот код плох, почему он не годится в production и к командной разработке и т.п. В итоге мне пришлось тебе вообще пример из личной, так сказать, жизни приводить.


Ты не сказал сколько по твоему мнению дартаньянов писало тот код.
Matrix has you...
Re[23]: namespace'ы в классах
От: Sheridan Россия  
Дата: 06.02.12 21:53
Оценка:
Здравствуйте, hattab, Вы писали:

H>На дельфях легко


Возможно, не буду спорить. В последний раз на делфи еще в школе писал...
Matrix has you...
Re[2]: шо, всего?? о0 (-)
От: Sheridan Россия  
Дата: 06.02.12 21:58
Оценка:
Matrix has you...
Re[15]: И снова про ц++
От: Cadet  
Дата: 07.02.12 05:13
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>__DATE__ — это строка, в которой записана дата компиляция файла. Как ее можно использовать для "стрельнуть" — непонятно.


А если слегка поднапрячься?
#if __DATE__ > "1 января 2012 года"
// Жрите сцуки через полгода после моего увольнения
#define true (rand() % 2)
#define false (rand() % 2)
#endif
... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
Re[6]: Подытожим?
От: neFormal Россия  
Дата: 07.02.12 05:31
Оценка:
Здравствуйте, Sheridan, Вы писали:

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

S>Верно. И про любой другой язык точно также верно.

нет, в управляемых языках вероятность возрастает меньше.. и рефакторинг проходит намного проще..

F>>а топик тут при чём?

F>>Sheridan "открыл всем глаза" на то, как добиться лучшего качества плюсового кода.. что ж, поверим его солидному опыту..
S>Это где я там глаза кому открывал? Всего лишь называю все своими именами.

совершенно не имея представления о "именах"..
не надо хвалиться ламерством, учись лучше..
...coding for chaos...
Re[15]: namespace'ы в классах
От: Privalov  
Дата: 07.02.12 06:43
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>А Дарт Аньян все никак не может донести толпе, что работать в сторону интереса намного продуктивнее, нежели работать в сторону необходимости. Например, сравни сколько жил авалон в мусорке и за сколько я его привел в порядок и добавил в туда несколько вкусных возможностей, а также намного улучшил его внешний вид. И сравни сколько изменилось после того как код мой убрали.


Чтобы ты знал, на моем нетбуке этот самый внешний вид нормально и не работал, а потому пришлось мне Авалона стереть. rojac, написанный на Java, намного лучше на том же нетбуке.
Re[16]: И снова про ц++
От: Sheridan Россия  
Дата: 07.02.12 06:50
Оценка:
Здравствуйте, Cadet, Вы писали:

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


S>>__DATE__ — это строка, в которой записана дата компиляция файла. Как ее можно использовать для "стрельнуть" — непонятно.


C>А если слегка поднапрячься?

C>
C>#if __DATE__ > "1 января 2012 года"
C>// Жрите сцуки через полгода после моего увольнения
C>#define true (rand() % 2)
C>#define false (rand() % 2)
C>#endif
C>


Ну те, кто не использует контроль версий — ССЗБ. А тот, к в этих условиях решится пакостить — вообще идиот.
Matrix has you...
Re[17]: И снова про ц++
От: Cadet  
Дата: 07.02.12 07:34
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Ну те, кто не использует контроль версий — ССЗБ. А тот, к в этих условиях решится пакостить — вообще идиот.


Умственные способности автора закладки обсуждать смысла нет, в злости или обиде человек что угодно может наделать. Системы контроля не панацея, ибо если изменение одиночное, то его легко заметить, и то при этом должен быть человек, который только и делает, что сидит и смотрит что закоммитили другие. Если коммит достаточно масштабный, с удалениями, добавлениями апдейтами мерджами и прочим, то велик шанс, что подобная закладка проскочит. И можно сказать что когда она выстрелит, проект будет парализован.
... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
Re[12]: И снова про ц++
От: enji  
Дата: 07.02.12 09:11
Оценка:
Здравствуйте, Ops, Вы писали:

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


E>>А я вот ни разу с такими не сталкивался, разный опыт видимо Ну и опять же, куча программ, которыми я пользуюсь, написана на с++. Лиспа я на десктопе что-то и не встречал. Про лисп на вебе я тож не слышал. Слышал, что был макроязык в автокаде (вроде бы) на основе лиспа. Но вроде как туда в конце концов всунули вба.


Ops>Lisp на десктопе — это как минимум emacs.


Кстати да, про емакс забыл. Пару раз пытался освоить его и вим, но сильно страшные для меня оказались
Re[13]: namespace'ы в классах
От: Privalov  
Дата: 07.02.12 09:17
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>>>Когда люди чего-то не понимают — они от этого стараются избавиться.


P>>Ты всегда действуешь таким образим?


S> Что именно ты хочешь знать?


Когда ты чего-то не понимаешь — ты от этого стараешься избавиться? Вот это я хочу знать.
Re[16]: И снова про ц++
От: enji  
Дата: 07.02.12 09:20
Оценка:
Здравствуйте, Cadet, Вы писали:

E>>Вы серьезно обсуждаете, что минус С++ — в том, что кто-то может написать #define true false? И скомбинировать это с макросом DATE?

E>>Что мешает мне написать какую-нить пакость в обычном коде на яве/питоне/шарпе, без использования препроцессора? И скомбинировать это с DateTime.Now или rand?

C>Ну напиши что ли, а потом обсудим, что сложнее поймать будет.



def someCalc(x, y, z):

  if rand % 100 == 57:
   return rand * 41
  
  return x + y + z



#define true (__LINE__ % 100 == 57 ? false : bool(1))


и? Если кода 5 строк, оба ловятся на ура. Если же это файл на 1500 строк, ловится уже сильно хуже. хидеры обычно короче реализаций, так что #define true возможно поймать даже проще

Да и вообще — сама тема обсуждения странная. Мы реально обсуждаем саботаж? Ну так а зачем саботировать в коде — можно вирь посадить или сорцы зашифровать...

Кстати
Re[16]: И снова про ц++
От: enji  
Дата: 07.02.12 09:30
Оценка:
Здравствуйте, Cadet, Вы писали:

C>А если слегка поднапрячься?

C>
C>#if __DATE__ > "1 января 2012 года"
C>// Жрите сцуки через полгода после моего увольнения
C>#define true (rand() % 2)
C>#define false (rand() % 2)
C>#endif
C>


ты это скомпилировать пробовал?
Re[18]: И снова про ц++
От: enji  
Дата: 07.02.12 09:32
Оценка:
Здравствуйте, Cadet, Вы писали:

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


S>>Ну те, кто не использует контроль версий — ССЗБ. А тот, к в этих условиях решится пакостить — вообще идиот.


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


Ага, а еще может зайти в серверную и отпинать сервер ногами. У нас например серверная не закрывается днем

Вы объясните, чем тут страшен именно #define?
Re[19]: И снова про ц++
От: Cadet  
Дата: 07.02.12 09:44
Оценка:
Здравствуйте, enji, Вы писали:

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


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


S>>>Ну те, кто не использует контроль версий — ССЗБ. А тот, к в этих условиях решится пакостить — вообще идиот.


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


E>Ага, а еще может зайти в серверную и отпинать сервер ногами. У нас например серверная не закрывается днем


E>Вы объясните, чем тут страшен именно #define?


Тем, что сидя в скрытом неочевидном месте, непрозрачным образом делает код разным для программиста и компилятора. Даже хуже операторов неявного преобразования, типа operator == и прочих, в них хоть отладчиком можно попасть.
... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
Re[17]: И снова про ц++
От: Cadet  
Дата: 07.02.12 09:45
Оценка:
Здравствуйте, enji, Вы писали:

E>ты это скомпилировать пробовал?


Нет, даже не пытался. Я идею показываю, а не рабочий код. Надо будет — скомпилирую.
... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
Re[14]: namespace'ы в классах
От: Sheridan Россия  
Дата: 07.02.12 09:51
Оценка:
Здравствуйте, Privalov, Вы писали:

P>Когда ты чего-то не понимаешь — ты от этого стараешься избавиться? Вот это я хочу знать.


Первое желание конечно — забить нафиг и забыть. Но как правило пересиливаю и осиливаю.
Matrix has you...
Re[20]: И снова про ц++
От: enji  
Дата: 07.02.12 10:34
Оценка:
Здравствуйте, Cadet, Вы писали:

E>>Вы объясните, чем тут страшен именно #define?


C>Тем, что сидя в скрытом неочевидном месте,

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

ИМХО, проблема с дефайнами сильно надумана. Если СЛЕДОВАТЬ_КОНВЕНЦИИ_ИХ_ИМЕНОВАНИЯ, багов нет. Закладка на макросе ничем не отличается от закладки в функции.

C>непрозрачным образом делает код разным для программиста и компилятора. Даже хуже операторов неявного преобразования, типа operator == и прочих, в них хоть отладчиком можно попасть.

В шарпе же можно перегрузить оператор +? Чем перегрузка оператора == хуже?
И кстати чем бага\закладка в операторе == хуже баги\закладки в функции someImportantCalc
Re[18]: И снова про ц++
От: enji  
Дата: 07.02.12 10:35
Оценка:
Здравствуйте, Cadet, Вы писали:

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


E>>ты это скомпилировать пробовал?


C>Нет, даже не пытался. Я идею показываю, а не рабочий код. Надо будет — скомпилирую.


ну дык твоя идея не работает. Покажи другую Тока сначала попробуй скомпилировать, вдруг она тож не работает
Re[14]: Подытожим?
От: Mamut Швеция http://dmitriid.com
Дата: 07.02.12 10:51
Оценка:
M>>Итого, пять человек четко и внятно показали тебе, почему этот код плох, почему он не годится в production и к командной разработке и т.п. В итоге мне пришлось тебе вообще пример из личной, так сказать, жизни приводить.

S>Ты не сказал сколько по твоему мнению дартаньянов писало тот код.


Как этот вопрос соотносится с той, которую ты оставил из моего сообщения? И вообще со всем моим предыдущим сообщением?


dmitriid.comGitHubLinkedIn
Re[15]: namespace'ы в классах
От: Mamut Швеция http://dmitriid.com
Дата: 07.02.12 10:56
Оценка:
N>>>Такого рода отношение к проекту, в котором участвуешь, неприемлемо как для меня, независимо от того, он платный, бесплатный, открытый, или какой-то ещё.
P>>Целая толпа народу пытается объяснить это мсье д'Артаньяну черт знает сколько времени.
S>А Дарт Аньян все никак не может донести толпе, что работать в сторону интереса намного продуктивнее, нежели работать в сторону необходимости. Например, сравни сколько жил авалон в мусорке и за сколько я его привел в порядок и добавил в туда несколько вкусных возможностей

Например, напрочь поломав кодировку старых сообщений и сам процесс сборки

S>, а также намного улучшил его внешний вид.


Да так, что все очстальные участники спросили: что за неотключаемое ненастраиваемое гуано, верни все назад.

S>И сравни сколько изменилось после того как код мой убрали.


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


dmitriid.comGitHubLinkedIn
Re[21]: И снова про ц++
От: Jesmus Россия  
Дата: 07.02.12 10:57
Оценка:
Здравствуйте, enji, Вы писали:

E>ИМХО, проблема с дефайнами сильно надумана. Если СЛЕДОВАТЬ_КОНВЕНЦИИ_ИХ_ИМЕНОВАНИЯ, багов нет.


Так проблема не в именовании — проблема в использовании. В том что дефайны выглядят как функции, ощущаются как функции — но их нельзя использовать как функции. Иначе — сразу "привет, счастливой отладки".

Просто сколько раз уже видел вызовы в духе:

positive_val = ABS(my_func());

Что называется — приехали. Просто человек забыл ограничения define и использовал его как функцию. Разумеется это простой и очевидный пример, но ведь бывают и позакрученее. И что самое противное — они могут и работать правильно. 98% времени. Особенно если работа на железо завязана.

Если еще правила наименования нарушить — то при просмотре кода проблема вообще видна не будет. Спрашивается — и ради чего такое счастье? Сколько там будет выигрыш относительно заинлайненной функции, котора гарантированно работает как функция.
Re[15]: namespace'ы в классах
От: Privalov  
Дата: 07.02.12 11:07
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>>Когда люди чего-то не понимают — они от этого стараются избавиться.

S>Первое желание конечно — забить нафиг и забыть. Но как правило пересиливаю и осиливаю.


Тебе нужно объяснять, почему по крайней мере одно высказывание здесь является ложным?
Re[22]: И снова про ц++
От: enji  
Дата: 07.02.12 11:15
Оценка:
Здравствуйте, Jesmus, Вы писали:


J>Просто сколько раз уже видел вызовы в духе:


J>positive_val = ABS(my_func());


J>Что называется — приехали. Просто человек забыл ограничения define и использовал его как функцию. Разумеется это простой и очевидный пример, но ведь бывают и позакрученее. И что самое противное — они могут и работать правильно. 98% времени. Особенно если работа на железо завязана.


Ну дык. Понятно, что макросы стоит использовать только там, где других средств не хватает и очень аккуратно. И уж точно не как замену инлайн-функции.

При чем тут железо — неясно.

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


Ну так не надо их нарушать...
Re[4]: И снова про ц++
От: B0FEE664  
Дата: 07.02.12 11:16
Оценка:
Здравствуйте, x-code, Вы писали:

XC>>>Отсутствие системы сообщений как в ObjectiveC, встроенной системы сигналов и слотов как в QT

LVV>>А где такое еще есть?
XC>Ну вот в ObjC и QT есть.

boost::signal чем не устраивает?
И каждый день — без права на ошибку...
Re[5]: И снова про ц++
От: B0FEE664  
Дата: 07.02.12 11:20
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Сигналы со слотами мне нравятся — это как-то сильно понятно... Даже новичкам в программировании...


Т.е. не нравятся как преподавателю ? Или ещё что-то? Почему не нравятся ?
И каждый день — без права на ошибку...
Re[16]: namespace'ы в классах
От: Sheridan Россия  
Дата: 07.02.12 11:26
Оценка:
Здравствуйте, Mamut, Вы писали:

N>>>>Такого рода отношение к проекту, в котором участвуешь, неприемлемо как для меня, независимо от того, он платный, бесплатный, открытый, или какой-то ещё.

P>>>Целая толпа народу пытается объяснить это мсье д'Артаньяну черт знает сколько времени.
S>>А Дарт Аньян все никак не может донести толпе, что работать в сторону интереса намного продуктивнее, нежели работать в сторону необходимости. Например, сравни сколько жил авалон в мусорке и за сколько я его привел в порядок и добавил в туда несколько вкусных возможностей

M>Например, напрочь поломав кодировку старых сообщений и сам процесс сборки

Например процесс сборки я перевел в cmake и даже скрипт нарисовал.
Также например кодировку я починил, но то что успело засинхронизироваться — уже было невозможно исправить.

S>>, а также намного улучшил его внешний вид.

M>Да так, что все очстальные участники спросили: что за неотключаемое ненастраиваемое гуано, верни все назад.
Я писал — правый клик по меню и настраивайте как вам надо.

S>>И сравни сколько изменилось после того как код мой убрали.

M>Ты не герой, и если в проекте мало движения, то не из-за того, что ты оттуда ушел.
Это изза того что никому ничего не нужно.
Matrix has you...
Re[6]: И снова про ц++
От: LaptevVV Россия  
Дата: 07.02.12 11:27
Оценка:
Здравствуйте, B0FEE664, Вы писали:

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


LVV>>Сигналы со слотами мне нравятся — это как-то сильно понятно... Даже новичкам в программировании...


BFE>Т.е. не нравятся как преподавателю ? Или ещё что-то? Почему не нравятся ?

Наоборот, нравятся...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[16]: namespace'ы в классах
От: Sheridan Россия  
Дата: 07.02.12 11:28
Оценка:
Здравствуйте, Privalov, Вы писали:

P>

S>>>Когда люди чего-то не понимают — они от этого стараются избавиться.

S>>Первое желание конечно — забить нафиг и забыть. Но как правило пересиливаю и осиливаю.


P>Тебе нужно объяснять, почему по крайней мере одно высказывание здесь является ложным?

Да уж постарайся как это получается, что мое согласие с первой фразой в применении себя плюс корректировка в плане стремления к исправлению данной ситуации внезапно оказывается ложным.
Matrix has you...
Re[6]: И снова про ц++
От: blackhearted Украина  
Дата: 07.02.12 11:28
Оценка:
Здравствуйте, Sheridan, Вы писали:

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


B>>Но дядя Линус

S>Вы наивно, мсье, полагаете, что это имя для меня имеет какойто вес...

только Генту, только хардкор?
Re[11]: И снова про ц++
От: blackhearted Украина  
Дата: 07.02.12 11:30
Оценка:
Здравствуйте, okman, Вы писали:

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


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


O>Расслабься, сверхчеловек.


Да просто его телоскиллы продаёт какая-то консалтерская контора.
Вот там, у клиентов на швейной фабрике, и всплывают проблемы, с которыми героически борется супермэн.
Re[23]: И снова про ц++
От: Jesmus Россия  
Дата: 07.02.12 11:33
Оценка:
Здравствуйте, enji, Вы писали:

E>Ну дык. Понятно, что макросы стоит использовать только там, где других средств не хватает и очень аккуратно. И уж точно не как замену инлайн-функции.


Угу, верно. Вот только именно такую точку зрения Sheridan и называет — "вы макросы боитесь использовать, наверное не осилили". А остальные пытаются доказать "что макросы стоит использовать только там, где других средств не хватает и очень аккуратно". Потому что понимают, что люди не роботы — и код подобный приведенному выше обязательно в проекте появится. Слишком уж макросы на функции похожи.

E>И уж точно не как замену инлайн-функции.


Кстати — ABS, MAX, MIN — они разве не как нетипизированная замена инлайн функций появились? Во всяком случае я их использование видел повсеместно, пока на managed не перескочил.

E>При чем тут железо — неясно.


Я имел в виду, что если func() из примера выше будет дергать железо (читать из порта, писать что-либо куда-либо) — то найти подобную бяку будет очень сложно. Ибо железо может выдавать подолгу один и тот же сигнал, и все тесты будут успешно пройдены. А потом произойдет скачок значений в момент вызова макроса...

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


E>Ну так не надо их нарушать...


И тем не менее в реальном мире нарушают Если это проект пришедший тебе по наследству, на поддержку — ты на это можешь только глобальными переименованиями повлиять.что макросы стоит использовать только там, где других средств не хватает и очень аккуратно
Re[24]: И снова про ц++
От: enji  
Дата: 07.02.12 11:40
Оценка:
Здравствуйте, Jesmus, Вы писали:

J>Кстати — ABS, MAX, MIN — они разве не как нетипизированная замена инлайн функций появились? Во всяком случае я их использование видел повсеместно, пока на managed не перескочил.


в голом С — да, в С++ они не нужны — есть шаблоны. Хотя где-то в хидерах visual-ки определяются min и max и отключаются только явным указанием какой-то опции.

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


E>>Ну так не надо их нарушать...


J>И тем не менее в реальном мире нарушают Если это проект пришедший тебе по наследству, на поддержку — ты на это можешь только глобальными переименованиями повлиять.


Ну на поддержке старых чужих проектов, имхо, макры — наименьшая из проблем. Там часто столько лапши за долгие годы жизни наросло...
Re[16]: Подытожим?
От: Mamut Швеция http://dmitriid.com
Дата: 07.02.12 12:08
Оценка:
S>>>Ты не сказал сколько по твоему мнению дартаньянов писало тот код.
M>>Как этот вопрос соотносится с той, которую ты оставил из моего сообщения? И вообще со всем моим предыдущим сообщением?
S>Я к тому, что если вокруг сплошные Дарт Аньяны, то может наоборот?

Но нет, "мы все — тупые, ленивые программисты, которые не хотят рабоать, один ты д'Артаньян, потому что у тебя 0 опыта, но ты точно знаешь лучше всех"



dmitriid.comGitHubLinkedIn
Re[25]: И снова про ц++
От: Jesmus Россия  
Дата: 07.02.12 12:09
Оценка:
Здравствуйте, enji, Вы писали:

E>в голом С — да, в С++ они не нужны — есть шаблоны. Хотя где-то в хидерах visual-ки определяются min и max и отключаются только явным указанием какой-то опции.


Не только в visual. Это стандартные макросы — их можно найти и в gnome lib, к примеру. Но суть не в данных конкретных макросах, а в противопоставлении двух подходов:

1) "использовать макросы только если без них ну никак, и крайне осторожно". (с)почти все.

2) "Если что-то можно записать на макросах — так и надо поступить. Это мощное и быстрое средство. Тот кто максимально избегает его — не осилил или лодырь" (с) Шеридан.

Я лично выступаю за первую позицию — ибо нагляделся и понимаю что код пишут люди очень разные, всех конролировать я не смогу. И если есть возможность не допустить появления дополнительного пласта багов — то так и надо поступать. В стратегическом плане (через год, два, пять) — это окупается уменьшением количества WTF при очередном допиливании. Разумеется есть места где препроцессор очень полезен и совсем его скидывать со счетов не стоит. Но каждый раз когда у меня чешутся руки написать макрос — стоит спросить себя "а можно ли обойтись без него".


E>Ну на поддержке старых чужих проектов, имхо, макры — наименьшая из проблем. Там часто столько лапши за долгие годы жизни наросло...


И опять категорически согласен Макросы действительно не самая большая из проблем. Просто это та проблема которая очень легко решается на самом старте проекта полным запретом макросов (если очень-очень нужно — докажи тимлиду). И в итоге потом (когда проект становится старым и чужим) на одну проблему у поддержки становится меньше.использовать макросы только если без них ну никак, и крайне осторожно
Re[17]: namespace'ы в классах
От: Mamut Швеция http://dmitriid.com
Дата: 07.02.12 12:14
Оценка:
N>>>>>Такого рода отношение к проекту, в котором участвуешь, неприемлемо как для меня, независимо от того, он платный, бесплатный, открытый, или какой-то ещё.
P>>>>Целая толпа народу пытается объяснить это мсье д'Артаньяну черт знает сколько времени.
S>>>А Дарт Аньян все никак не может донести толпе, что работать в сторону интереса намного продуктивнее, нежели работать в сторону необходимости. Например, сравни сколько жил авалон в мусорке и за сколько я его привел в порядок и добавил в туда несколько вкусных возможностей

M>>Например, напрочь поломав кодировку старых сообщений и сам процесс сборки

S>Например процесс сборки я перевел в cmake и даже скрипт нарисовал.
S>Также например кодировку я починил, но то что успело засинхронизироваться — уже было невозможно исправить.

О чем и речь

S>>>, а также намного улучшил его внешний вид.

M>>Да так, что все очстальные участники спросили: что за неотключаемое ненастраиваемое гуано, верни все назад.
S>Я писал — правый клик по меню и настраивайте как вам надо.

http://rsdn.ru/forum/janus/3482910.aspx
Автор: Anton Batenev
Дата: 28.07.09
(твой ответ показателен
Автор: Sheridan
Дата: 28.07.09
— мне так нарвится, идите нахрен)
Ну и вообще абсолютно верные замечания Антона Батенева http://rsdn.ru/forum/janus/3486316.1.aspx
Автор: Anton Batenev
Дата: 30.07.09
включая вопрос про GUI, но твоя реакция, как всегда, показательно. Звучит она так: «идите все нахрен».

S>>>И сравни сколько изменилось после того как код мой убрали.

M>>Ты не герой, и если в проекте мало движения, то не из-за того, что ты оттуда ушел.
S>Это изза того что никому ничего не нужно.

Перестань общаться с голосами в своей голове. Начинай общаться с реальными людьми. Хотя у тебя получается очень хреново
Автор: Sheridan
Дата: 30.07.09


dmitriid.comGitHubLinkedIn
Re: И снова про ц++
От: Tourist Россия  
Дата: 07.02.12 12:18
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++? Указатели? Да фигня это, на пару граблей наступить и рефлекс появится. Зато более шустрый софт получается.

S>Так все же?

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

Пытаться все писать на с++, можно, но зачем?
Re[12]: И снова про ц++
От: Sheridan Россия  
Дата: 07.02.12 12:34
Оценка:
Здравствуйте, blackhearted, Вы писали:

S>>Ну так надо не языком ограничивать а правилами проекта.

B>Так тебе ж на них пофигу.
B>"Если мне интересно — буду писать как хочу".
B>Или это бы не ты?

Ты "случайно" забыл еще одну мою цитату добавить.
Matrix has you...
Re[17]: Подытожим?
От: Sheridan Россия  
Дата: 07.02.12 12:35
Оценка:
Здравствуйте, Mamut, Вы писали:

S>>>>Ты не сказал сколько по твоему мнению дартаньянов писало тот код.

M>>>Как этот вопрос соотносится с той, которую ты оставил из моего сообщения? И вообще со всем моим предыдущим сообщением?
S>>Я к тому, что если вокруг сплошные Дарт Аньяны, то может наоборот?
M>

M>Но нет, "мы все — тупые, ленивые программисты, которые не хотят рабоать, один ты д'Артаньян, потому что у тебя 0 опыта, но ты точно знаешь лучше всех"

Я не это спрашивал.
Matrix has you...
Re[18]: Подытожим?
От: Mamut Швеция http://dmitriid.com
Дата: 07.02.12 12:57
Оценка:
S>>>>>Ты не сказал сколько по твоему мнению дартаньянов писало тот код.
M>>>>Как этот вопрос соотносится с той, которую ты оставил из моего сообщения? И вообще со всем моим предыдущим сообщением?
S>>>Я к тому, что если вокруг сплошные Дарт Аньяны, то может наоборот?
M>>

M>>Но нет, "мы все — тупые, ленивые программисты, которые не хотят рабоать, один ты д'Артаньян, потому что у тебя 0 опыта, но ты точно знаешь лучше всех"

S>Я не это спрашивал.

Я тебе описал объективную ситуацию, которую сейчас упорно и долго в моей компании решают.

Ответь на такой вопрос: почему, имея заплечами ровно ноль опыта, ты считаешь, что ты — единственный, кто говорит правду, только правду, и ничего, кроме правды, а все остальные — ленивые идиоты?


dmitriid.comGitHubLinkedIn
Re[19]: Подытожим?
От: Sheridan Россия  
Дата: 07.02.12 13:08
Оценка:
Здравствуйте, Mamut, Вы писали:

Я задал тебе конкретный вопрос: сколько по твоему счету Дарт Аньянов в твоих проектах и сколько не Дарт аньянов?
Matrix has you...
Re[19]: И снова про ц++
От: Cadet  
Дата: 07.02.12 15:49
Оценка:
Здравствуйте, enji, Вы писали:

E>ну дык твоя идея не работает. Покажи другую Тока сначала попробуй скомпилировать, вдруг она тож не работает


Ну вот тебе за 5 минут набросал, раз у тебя воображение атрофировано. Комбинация макрос + функция:
bool fakebool(bool val)
{
    bool isConditionHit = false;
    const char* pdate = __DATE__;        

    // используя pdate, который имеет фиксированное представление кстати,
    // рассчитываем условие, и еcли решили что время закладки пришло, то...
    // например срабатывать начиная с 12 года
    
    int year = ((int)(pdate[9])-48)*10 + (int)(pdate[10]);
    if (year >= 12)        
        isConditionHit = true;
    
    if (!isConditionHit)
        return val;
        
    return rand() % 100 < 95 ? val : !val;
}

#define true (fakebool(true))
#define false (fakebool(false))

Бабахнет начиная с 12 года. И крайне неприятно оно тем, что вылезет во всем проекте сразу. И никто сразу не подумает на true или false, так как все работало. Поди найди такую закладку в большом проекте.
... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
Re[20]: Подытожим?
От: Mamut Швеция http://dmitriid.com
Дата: 07.02.12 16:05
Оценка:
S>Я задал тебе конкретный вопрос: сколько по твоему счету Дарт Аньянов в твоих проектах и сколько не Дарт аньянов?

Какая тебе разница? Чтобы голоса в твоей голове что-то опять нашептали тебе.

Дартаньяны — это образ собирательный. Происходит из обыкновенной человеческой природы.

Сначала было 5 разработчиков, потом 20, сейчас — 120.

Пока разработчиков было 20, худо-бедно работала система «пишите так, чтобы тесты не падали». И тесты не падали. Но все держалось на 3-4 людях, которые знали все инклюды и странные вызовы. Трое из этих людей стали недоступны, все — работа (на данный момент — семерых человек в достаточно ключевых позициях) замерла надолго. Не говоря уже о проблемах с рефакторингом и т.п.

Но да, мотивация каждого неявного куска кода всегда была такой: «а что, маленький, отлаженный кусок кода»


dmitriid.comGitHubLinkedIn
Re[14]: И снова про ц++
От: Sheridan Россия  
Дата: 07.02.12 18:44
Оценка:
Здравствуйте, blackhearted, Вы писали:

Да ладно? Ты действительно не понимаешь, что "Если мне интересно — буду писать как хочу" работает до тех пор, пока "мне за код не платят деньги"?
Matrix has you...
Re[12]: И снова про ц++
От: ambel-vlad Беларусь  
Дата: 07.02.12 20:03
Оценка:
Здравствуйте, blackhearted, Вы писали:

B>консалтерская контора.


Да ты еще тот льстец.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[11]: namespace'ы в классах
От: Ночной Смотрящий Россия  
Дата: 07.02.12 21:23
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Когда люди чего-то не понимают — они от этого стараются избавиться.


Ты действительно считаешь, что те, кто писал янус, не понимают string.Format? Или ты неспособен физически написать код, который поймет кто то кроме тебя?
Re[18]: Прошу прощения...
От: jazzer Россия Skype: enerjazzer
Дата: 07.02.12 21:42
Оценка:
Здравствуйте, Privalov, Вы писали:

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


S>>Причину со следствием пожалуйста не путай. Обвиняя тебя, я не врал, так как считал что пишу ответ Мамуту. И сразу извинился после твоего ответа, так как раньше не заметил. Если бы заметил — просто удалил бы сообщение совсем.


P>Тебе надо чуть меньше торопиться и чуть больше думать, тогда тебе не придется сочинять такие отмазки. Таких отмазок мои дети уже давным-давно не приносят.


Он уже признал, что был неправ, и извинился. Чего тебе еще надо
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[15]: И снова про ц++
От: NikeByNike Россия  
Дата: 07.02.12 21:50
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Да ладно? Ты действительно не понимаешь, что "Если мне интересно — буду писать как хочу" работает до тех пор, пока "мне за код не платят деньги"?


Да ради бога — пиши как тебе в голову взбредёт. Только чтобы это было по кодинг-стандарту, код был очевиден, хорошо структурирован и именован, в соответствии с внятной архитектурой и с использованием типовых решений. А вообще, у нас, полная свобода кодогенерации за деньги оно пишется или нет.
Нужно разобрать угил.
Re[3]: namespace'ы в классах
От: landerhigh Пират  
Дата: 07.02.12 21:55
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Ну если очень надо — можно и нарисовать, благо нетрудно. У меня — не программиста — ушло гдето минут 10...


Все же этому сайту очень не хватает в качестве оценки напуганного смайлика с огромными от ужаса глазами.

У нас, программистов, такой "код" на код ревью летит в помойку, а его аффтар отправляется в ссылку править баги в быдлокоде.
www.blinnov.com
Re: И снова про ц++
От: ДимДимыч Украина http://klug.org.ua
Дата: 07.02.12 23:34
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Да фигня это, на пару граблей наступить и рефлекс появится. Зато более шустрый софт получается.


Встречный вопрос: почему ты скрипты автоматизации не на C/C++ пишешь? Ведь bash, а впрочем и остальные shell-интерпретаторы такие тормознутые по сравнению с нативным кодом.
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
Re[20]: И снова про ц++
От: enji  
Дата: 08.02.12 03:10
Оценка:
Здравствуйте, Cadet, Вы писали:

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


E>>ну дык твоя идея не работает. Покажи другую Тока сначала попробуй скомпилировать, вдруг она тож не работает


C>Ну вот тебе за 5 минут набросал, раз у тебя воображение атрофировано. Комбинация макрос + функция:

C>
C>bool fakebool(bool val)
C>{
C>    bool isConditionHit = false;
C>    const char* pdate = __DATE__;        

C>    // используя pdate, который имеет фиксированное представление кстати,
C>    // рассчитываем условие, и еcли решили что время закладки пришло, то...
C>    // например срабатывать начиная с 12 года
    
C>    int year = ((int)(pdate[9])-48)*10 + (int)(pdate[10]);
C>    if (year >= 12)        
C>        isConditionHit = true;
    
C>    if (!isConditionHit)
C>        return val;
        
C>    return rand() % 100 < 95 ? val : !val;
C>}

C>#define true (fakebool(true))
C>#define false (fakebool(false))
C>

C>Бабахнет начиная с 12 года. И крайне неприятно оно тем, что вылезет во всем проекте сразу. И никто сразу не подумает на true или false, так как все работало. Поди найди такую закладку в большом проекте.

В любом крупном проекте это бабахнет при первой же компиляции обычно. На чем-то вроде такого кода:
template<class T, bool doSomething=true>
struct SomeTemplate {
};
 
SomeTemplate<int> q;


Вторая идея тоже неудачна. Давай еще!
Re[21]: И снова про ц++
От: enji  
Дата: 08.02.12 03:22
Оценка:
Здравствуйте, enji, Вы писали:


C>>И крайне неприятно оно тем, что вылезет во всем проекте сразу. И никто сразу не подумает на true или false, так как все работало. Поди найди такую закладку в большом проекте.


На самом деле, даже если бы твоя идея сработала, нет совершенно никаких проблем найти такую закладку. Просто запускаешься под отладчиком, находишь первый бабах — а он найдется быстро на самом то деле — и смотришь туда. Изумляешься, смотришь снова. Снова изумляешься, смотришь асм. Думаешь, что нашел багу компилятора, но все таки смотришь в выхлоп препроцессора. Изумляешься еще больше, находишь макрос, смотришь в vcs кто автор.
Все этой займет ну максимум день. Скорее всего час-два.

Даже если автор закладки озаботится антиотладочными приемами, все равно все найдется за день-два.

Дальше сообщаешь начальству, берутся все коммиты этого автора и проходят ревью. Вот это уже может быть долго — смотря сколько кода он успел написать.

НО! Наделать мин можно на любом языке, причем тут С++?
Re[22]: namespace'ы в классах
От: hattab  
Дата: 08.02.12 07:22
Оценка:
Здравствуйте, Sheridan, Вы писали:

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


Есть результат?
avalon 1.0rc3 build 428, zlib 1.2.3
Re[12]: namespace'ы в классах
От: Sheridan Россия  
Дата: 08.02.12 07:39
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Ты действительно считаешь, что те, кто писал янус, не понимают string.Format?

Сам удивляюсь.

НС>Или ты неспособен физически написать код, который поймет кто то кроме тебя?

Да ничего сложного же не пишу.
Matrix has you...
Re[2]: И снова про ц++
От: Sheridan Россия  
Дата: 08.02.12 07:40
Оценка:
Здравствуйте, ДимДимыч, Вы писали:

ДД>Встречный вопрос: почему ты скрипты автоматизации не на C/C++ пишешь? Ведь bash, а впрочем и остальные shell-интерпретаторы такие тормознутые по сравнению с нативным кодом.

Иногда пишу, а что?
Matrix has you...
Re[23]: namespace'ы в классах
От: Sheridan Россия  
Дата: 08.02.12 07:40
Оценка:
Здравствуйте, hattab, Вы писали:

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


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


H>Есть результат?


Нет еще, не занимался
Matrix has you...
Re[22]: И снова про ц++
От: Cadet  
Дата: 08.02.12 08:43
Оценка:
Здравствуйте, enji, Вы писали:

E>НО! Наделать мин можно на любом языке, причем тут С++?


Напомню исходное сообщение, с которого пошло дело

Мы можем поменять код _вне_ функции, и это измнение приведет к изменению логики работы функции и любым побочным эффектам.
Начиная от произвольного дефайна (#define true false // happy debug) заканчивая переорпеделением метода ==, который может например иметь в себе багу и гадить в памятью.

Мне честно не удается припомнить бомбу схожей мощности и вредоносности в других языках. Проблема как обычно в том, что сторон у медалей две, и эти стороны неравнозначны. У С++ достаточно много подобных бомб, и куча шериданов, которые ими радостно пользуются. Взгляни хотя бы на его пример с неймспейсами — write only код. Языком слишком просто пользоваться неправильно — это недостаток С++.
... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
Re[23]: И снова про ц++
От: hattab  
Дата: 08.02.12 09:23
Оценка:
Здравствуйте, Cadet, Вы писали:

C>У С++ достаточно много подобных бомб, и куча шериданов, которые ими радостно пользуются. Взгляни хотя бы на его пример с неймспейсами — write only код.


У меня, паскалиста, проблем с чтением его кода не возникло Теперь вот жду варианта с поддержкой наследования
avalon 1.0rc3 build 428, zlib 1.2.3
Re[23]: И снова про ц++
От: enji  
Дата: 08.02.12 09:36
Оценка:
Здравствуйте, Cadet, Вы писали:

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


E>>НО! Наделать мин можно на любом языке, причем тут С++?


C>Напомню исходное сообщение, с которого пошло дело

C>

C>Мы можем поменять код _вне_ функции, и это измнение приведет к изменению логики работы функции и любым побочным эффектам.
C>Начиная от произвольного дефайна (#define true false // happy debug) заканчивая переорпеделением метода ==, который может например иметь в себе багу и гадить в памятью.

C>Мне честно не удается припомнить бомбу схожей мощности и вредоносности в других языках. Проблема как обычно в том, что сторон у медалей две, и эти стороны неравнозначны. У С++ достаточно много подобных бомб, и куча шериданов, которые ими радостно пользуются. Взгляни хотя бы на его пример с неймспейсами — write only код. Языком слишком просто пользоваться неправильно — это недостаток С++.

Функции во многих языках зависят от кода вне функции, С++ тут ничем особо не выделяется.
Произвольный дефайн #define true false // happy debug как мы выяснили, быстро находится и исправляется.
Операторы можно перегружать и в шарпе, в чем проблемы? В шарпе есть ансейф, который может гадить в память. В яве есть jni, которые тоже могут гадить в память. А можно не гадить в память, а неверно менять состояние объекта. Тут никакой ансейф не нужен. Последствия могут быть эквивалентны расстрелянной памяти.

Любым языком можно пользоваться неправильно У меня был в поддержке код на дельфе с тонной глобальных переменных. Точно такое можно написать на шарпе\яве.

Плюсы дают много возможностей, но и возлагают на программиста ответственность за их использование. Прострелить себе ногу в плюсах безусловно проще, чем в шарпе\яве, это да. И новый проект на плюсах под десктоп я бы сегодня не начал. Однако у плюсов есть свои ниши, в которых они хорошо себя чувствуют.
Re[23]: И снова про ц++
От: ambel-vlad Беларусь  
Дата: 08.02.12 09:44
Оценка:
Здравствуйте, Cadet, Вы писали:

E>>НО! Наделать мин можно на любом языке, причем тут С++?


C>Напомню исходное сообщение, с которого пошло дело

C>

C>Мы можем поменять код _вне_ функции, и это измнение приведет к изменению логики работы функции и любым побочным эффектам.
C>Начиная от произвольного дефайна (#define true false // happy debug) заканчивая переорпеделением метода ==, который может например иметь в себе багу и гадить в памятью.


Ну в C# тоже нечто подобное можно утворить. Например узаешь ты методы из System.Math. 99% что используется using. Дальше все элементарно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[24]: И снова про ц++
От: Cadet  
Дата: 08.02.12 10:00
Оценка:
Здравствуйте, enji, Вы писали:

E>Функции во многих языках зависят от кода вне функции, С++ тут ничем особо не выделяется.

E>Произвольный дефайн #define true false // happy debug как мы выяснили, быстро находится и исправляется.
Ну это ты на форуме его легко нашел и исправил. Ты всегда сразу ассемблер лезешь проверять?

E>Операторы можно перегружать и в шарпе, в чем проблемы?

В этом и проблемы. Я не говорил что шарп беспроблемный язык.

E>В шарпе есть ансейф, который может гадить в память.

Верно, только это видно глазами. В коде. Где ансейф там и проблемы. Чтоб разнести по сторонам ансейф и код, который он портит, надо очень-очень постараться.

E>Любым языком можно пользоваться неправильно У меня был в поддержке код на дельфе с тонной глобальных переменных. Точно такое можно написать на шарпе\яве.

Да, глобальное состояние суть зло.
... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
Re[24]: И снова про ц++
От: Cadet  
Дата: 08.02.12 10:00
Оценка:
Здравствуйте, ambel-vlad, Вы писали:

C>>

C>>Мы можем поменять код _вне_ функции, и это измнение приведет к изменению логики работы функции и любым побочным эффектам.
C>>Начиная от произвольного дефайна (#define true false // happy debug) заканчивая переорпеделением метода ==, который может например иметь в себе багу и гадить в памятью.


AV>Ну в C# тоже нечто подобное можно утворить. Например узаешь ты методы из System.Math. 99% что используется using. Дальше все элементарно.


Так-так, а чуть подробнее?
... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
Re[25]: И снова про ц++
От: ambel-vlad Беларусь  
Дата: 08.02.12 12:22
Оценка:
Здравствуйте, Cadet, Вы писали:

C>Здравствуйте, ambel-vlad, Вы писали:


C>>>

C>>>Мы можем поменять код _вне_ функции, и это измнение приведет к изменению логики работы функции и любым побочным эффектам.
C>>>Начиная от произвольного дефайна (#define true false // happy debug) заканчивая переорпеделением метода ==, который может например иметь в себе багу и гадить в памятью.


AV>>Ну в C# тоже нечто подобное можно утворить. Например узаешь ты методы из System.Math. 99% что используется using. Дальше все элементарно.


C>Так-так, а чуть подробнее?


А что тут поподробнее. Пишешь "using Math = Ptitsa.Oblomingo.Math;" И в своей "птице обломинго" пишешь точно такой же подарочек.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[26]: И снова про ц++
От: Cadet  
Дата: 08.02.12 12:41
Оценка:
Здравствуйте, ambel-vlad, Вы писали:

AV>>>Ну в C# тоже нечто подобное можно утворить. Например узаешь ты методы из System.Math. 99% что используется using. Дальше все элементарно.


C>>Так-так, а чуть подробнее?


AV>А что тут поподробнее. Пишешь "using Math = Ptitsa.Oblomingo.Math;" И в своей "птице обломинго" пишешь точно такой же подарочек.


Как минимум данную закладку нужно вставлять непосредственно в файл, в котором хочется поднасрать, что резко сужает область ее применимости, ограничивает эффект и повышает шанс обнаружения. Перестанет работать один кусочек кода, или перестанет работать всё у всех — чувствуешь разницу?
... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
Re[25]: И снова про ц++
От: enji  
Дата: 08.02.12 12:47
Оценка:
Здравствуйте, Cadet, Вы писали:

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


E>>Функции во многих языках зависят от кода вне функции, С++ тут ничем особо не выделяется.

E>>Произвольный дефайн #define true false // happy debug как мы выяснили, быстро находится и исправляется.
C>Ну это ты на форуме его легко нашел и исправил. Ты всегда сразу ассемблер лезешь проверять?
Если наблюдается мистика — лезу.

E>>Операторы можно перегружать и в шарпе, в чем проблемы?

C>В этом и проблемы. Я не говорил что шарп беспроблемный язык.
В яве — нельзя. Там тоже не все шоколадно Да и собственно говоря непонятно, чем ошибка в operator+ хуже ошибки в someFunc(). Надо просто помнить, что практически любой оператор — это вызов некоторой функции.

E>>В шарпе есть ансейф, который может гадить в память.

C>Верно, только это видно глазами. В коде. Где ансейф там и проблемы. Чтоб разнести по сторонам ансейф и код, который он портит, надо очень-очень постараться.
ХЗ, я не большой спец по шарпу. Ансейфом нельзя расстрелять память? Если можно — проблемы могут вылезти совсем не там, где ансейф.
Re[26]: И снова про ц++
От: _d_m_  
Дата: 08.02.12 13:24
Оценка:
Здравствуйте, enji, Вы писали:

E>>>В шарпе есть ансейф, который может гадить в память.

C>>Верно, только это видно глазами. В коде. Где ансейф там и проблемы. Чтоб разнести по сторонам ансейф и код, который он портит, надо очень-очень постараться.
E>ХЗ, я не большой спец по шарпу. Ансейфом нельзя расстрелять память? Если можно — проблемы могут вылезти совсем не там, где ансейф.

И сколько этого ансейфа в реальной жизни? Много лет пишу на шарпе еще ни разу не использовал — нет необходимости.
Re[13]: namespace'ы в классах
От: Ночной Смотрящий Россия  
Дата: 08.02.12 18:42
Оценка:
Здравствуйте, Sheridan, Вы писали:

НС>>Ты действительно считаешь, что те, кто писал янус, не понимают string.Format?

S>Сам удивляюсь.

Это неизлечимо.

НС>>Или ты неспособен физически написать код, который поймет кто то кроме тебя?

S>Да ничего сложного же не пишу.

А я и не говорил про сложное. Моток лески даже котенок способен запутать так, что потом взрослый человек несколько часов распутывать будет. Усилия надо прилагать для написания легко читаемого кода, а не наоборот.
Re[27]: И снова про ц++
От: ambel-vlad Беларусь  
Дата: 08.02.12 19:21
Оценка:
Здравствуйте, Cadet, Вы писали:

V>>>>Ну в C# тоже нечто подобное можно утворить. Например узаешь ты методы из System.Math. 99% что используется using. Дальше все элементарно.


C>>>Так-так, а чуть подробнее?


AV>>А что тут поподробнее. Пишешь "using Math = Ptitsa.Oblomingo.Math;" И в своей "птице обломинго" пишешь точно такой же подарочек.


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


Чувствую. Когда все перестает работать, то найти проще.

Напомню исходное сообщение, с которого пошло дело

C>Мы можем поменять код _вне_ функции, и это измнение приведет к изменению логики работы функции и любым побочным эффектам.


Так что при желании, свинью подложить можно в любом языке. А не только в плюсах.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[28]: И снова про ц++
От: Cadet  
Дата: 08.02.12 19:29
Оценка:
Здравствуйте, ambel-vlad, Вы писали:

AV>Чувствую. Когда все перестает работать, то найти проще.


Сомнительно, ибо непонятно где вообще ничинать искать.

AV>Напомню исходное сообщение, с которого пошло дело


AV>

C>>Мы можем поменять код _вне_ функции, и это измнение приведет к изменению логики работы функции и любым побочным эффектам.


AV> Так что при желании, свинью подложить можно в любом языке. А не только в плюсах.


Опять же, ты правда приравниваешь закладку, которая лежит в каком-нить инклюде, который к примеру даже напрямую не подставлен в проект IDE, и в файл попадает через 5-6 инклюдов в других хедерах, и закладку, которая лежит в том же файле, в котором пакостит?
... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
Re[29]: И снова про ц++
От: ambel-vlad Беларусь  
Дата: 08.02.12 19:36
Оценка:
Здравствуйте, Cadet, Вы писали:

AV>>Чувствую. Когда все перестает работать, то найти проще.


C>Сомнительно, ибо непонятно где вообще ничинать искать.


Да? Когда падает повсюду, то это хотя бы понятно что искать. А когда проблема в одном небольшом модульке, то это может существовать очень долго.

AV>>Напомню исходное сообщение, с которого пошло дело


AV>>

C>>>Мы можем поменять код _вне_ функции, и это измнение приведет к изменению логики работы функции и любым побочным эффектам.


AV>> Так что при желании, свинью подложить можно в любом языке. А не только в плюсах.


C>Опять же, ты правда приравниваешь закладку, которая лежит в каком-нить инклюде, который к примеру даже напрямую не подставлен в проект IDE, и в файл попадает через 5-6 инклюдов в других хедерах, и закладку, которая лежит в том же файле, в котором пакостит?


Мы уже начали обсуждать меру "подлости" закладки? А то в начале об этом ни слова. А когда оказалось, что подобного рода "закладки" отнюдь не особенность одного только C++, то уже начали вертеться как уж на сковородке.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[30]: И снова про ц++
От: Cadet  
Дата: 08.02.12 20:05
Оценка:
Здравствуйте, ambel-vlad, Вы писали:

AV>Да? Когда падает повсюду, то это хотя бы понятно что искать. А когда проблема в одном небольшом модульке, то это может существовать очень долго.


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

AV>Мы уже начали обсуждать меру "подлости" закладки? А то в начале об этом ни слова. А когда оказалось, что подобного рода "закладки" отнюдь не особенность одного только C++, то уже начали вертеться как уж на сковородке.


Закладка она подлая по определению. И смысла в закладке, которую найдет программист, просто открывший проект, нет. А вообще да, закладку можно написать на любом языке, вот тебе пример на С-подобном псевдоязыке:
void break_program()
{
    // write something wrong to global vars
}

void main()
{
    print("Do you want to break program?");    
    if (read_user_answer() == "yes")
        break_program();
        
    // rest of code
}

Ну прям убийственная вещь. Код ее перед глазами, падает только в одном конкретном случае — когда юзер скажет yes — ну прям 100 баллов из 100 по твоей шкале сложности поиска. . Можно искать годами.
... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
Re[31]: И снова про ц++
От: ambel-vlad Беларусь  
Дата: 08.02.12 20:35
Оценка:
Здравствуйте, Cadet, Вы писали:

AV>>Да? Когда падает повсюду, то это хотя бы понятно что искать. А когда проблема в одном небольшом модульке, то это может существовать очень долго.


C>И правда что, если падает какой-то конкретный модуль, то непонятно что искать. А если падает всё, причем рандомом то работает то не работает, то ты тут же найдешь в чем причина. Прям вундерпрограммист.


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

AV>>Мы уже начали обсуждать меру "подлости" закладки? А то в начале об этом ни слова. А когда оказалось, что подобного рода "закладки" отнюдь не особенность одного только C++, то уже начали вертеться как уж на сковородке.


C>Закладка она подлая по определению.


Тебе напомнить твое первоначальное утверждение? И утверждение, которое было сделано чуть-чуть попозже?
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[27]: И снова про ц++
От: rusted Беларусь  
Дата: 08.02.12 21:42
Оценка:
Здравствуйте, Cadet, Вы писали:

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


И это как раз на пользу C++ — если такая закладка будет в каком-то общем заголовочном файле, то она потянет за собой перекомпиляцию большей части проекта, что будет тут же замечено еще до того как "всё у всех перестанет работать". Сделать незаметно коммит, меняющий общий заголовочный файл, все-таки слишком сложно.
Re[14]: namespace'ы в классах
От: Sheridan Россия  
Дата: 09.02.12 03:58
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

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

Ну тогда, дабы не быть голословным, покажи мне мой трудночитаемый код.
Matrix has you...
Re[32]: И снова про ц++
От: Cadet  
Дата: 09.02.12 05:10
Оценка:
Здравствуйте, ambel-vlad, Вы писали:

AV>А почему ты решил, что твой конкретный модуль не будет падать рандомно? А теперь прикинь сколько таких модулей в программе. И что вероятнее обнаружится проблемы во всей программе или проблемы в маленьком модуле?


Ты похоже решил, что цель #define true false была в том, чтобы незаметно сидеть и не отсвечивать. Нет, было продемонстрировано, как можно парализовать работу кучи народу легким движением руки. И это я еще не заморачивался, а написал первое что в голову пришло.

AV>>>Мы уже начали обсуждать меру "подлости" закладки? А то в начале об этом ни слова. А когда оказалось, что подобного рода "закладки" отнюдь не особенность одного только C++, то уже начали вертеться как уж на сковородке.


C>>Закладка она подлая по определению.


AV>Тебе напомнить твое первоначальное утверждение? И утверждение, которое было сделано чуть-чуть попозже?


Да-да, напомни. Оба желательно. Но если ты посчитал что целью закладки было встраивание тетриса в программу, то можешь не утруждаться.
... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
Re[24]: После препроцессинга
От: Sheridan Россия  
Дата: 09.02.12 10:31
Оценка:
Кому интересно — после препроцессинга выглядит так:

class Parent
{
  public: class classSubNS { protected: Parent *m_Parent; public: classSubNS(Parent *v_Parent) { m_Parent = v_Parent; };
  void f();
  }; public: classSubNS *SubNS;

  public: class classOtherNameSpace { protected: Parent *m_Parent; public: classOtherNameSpace(Parent *v_Parent) { m_Parent = v_Parent; };
  void f();
  void other();
  }; public: classOtherNameSpace *OtherNameSpace;

  public:
  Parent() { SubNS = new classSubNS(this); OtherNameSpace = new classOtherNameSpace(this); }
  ~Parent() { delete SubNS; delete OtherNameSpace; }
  int c() { return 123; }
};

void Parent::classSubNS::f()
{
  cout << "Hi, " << m_Parent->c() << " from base!" << endl;
}

void Parent::classOtherNameSpace::other()
{
  cout << "Hi from base other!" << endl;
}

void Parent::classOtherNameSpace::f()
{
  cout << "Hi, " << m_Parent->c() << "! This is other namespace :))" << endl;
}


class Child : public Parent
{
  public: class classSubNS : public Parent::classSubNS { protected: Child *m_Child; public: classSubNS(Child *v_Child) : Parent::classSubNS(v_Child) {};
  void foo();
  }; public: classSubNS *SubNS;

  public:
  Child() { SubNS = new classSubNS(this); }
  ~Child() { delete SubNS; }
};

void Child::classSubNS::foo()
{
  cout << "Hi, " << m_Child->c() << " from child foo!" << endl;
}

class Deeper : public Child
{
  public: class classSubNS : public Child::classSubNS { protected: Deeper *m_Deeper; public: classSubNS(Deeper *v_Deeper) : Child::classSubNS(v_Deeper) {};
  void bar();
  }; public: classSubNS *SubNS;

  public: class classOtherNameSpace : public Child::classOtherNameSpace { protected: Deeper *m_Deeper; public: classOtherNameSpace(Deeper *v_Deeper) : Child::classOtherNameSpace(v_Deeper) {};
  void other();
  }; public: classOtherNameSpace *OtherNameSpace;

  public:
  Deeper() { SubNS = new classSubNS(this); OtherNameSpace = new classOtherNameSpace(this); }
  ~Deeper() { delete SubNS; delete OtherNameSpace; }
};

void Deeper::classSubNS::bar()
{
  cout << "Hi, " << m_Deeper->c() << " from Deeper bar!" << endl;
}

void Deeper::classOtherNameSpace::other()
{
  cout << "Hi from Deeper other!" << endl;
}


int main ()
{
  Parent *p = new Parent();
  p->SubNS->f();
  p->OtherNameSpace->other();
  p->OtherNameSpace->f();
  delete p;
  cout << "-------------------------" << endl;
  Child *c = new Child();
  c->SubNS->foo();
  c->SubNS->f();
  delete c;
  cout << "-------------------------" << endl;
  Deeper *d = new Deeper();
  d->SubNS->bar();
  d->SubNS->foo();
  d->SubNS->f();
  d->OtherNameSpace->other();
  delete d;
}
Matrix has you...
Re[4]: И снова про ц++
От: Sheridan Россия  
Дата: 09.02.12 10:40
Оценка:
Здравствуйте, ДимДимыч, Вы писали:

ДД>Почему иногда, а не всегда? Что застваляет в остальных случаях использовать bash? Лень?

Бывает и лень, а бывает и отсутствие компилятора...
Matrix has you...
Re[33]: И снова про ц++
От: ambel-vlad Беларусь  
Дата: 09.02.12 11:33
Оценка:
Здравствуйте, Cadet, Вы писали:

AV>>А почему ты решил, что твой конкретный модуль не будет падать рандомно? А теперь прикинь сколько таких модулей в программе. И что вероятнее обнаружится проблемы во всей программе или проблемы в маленьком модуле?


C>Ты похоже решил, что цель #define true false была в том, чтобы незаметно сидеть и не отсвечивать. Нет, было продемонстрировано, как можно парализовать работу кучи народу легким движением руки.


Вряд ли подобным сильно парализуешь. Как только сработает твоя бомба, то она быстро вычисляется и вычищается

C>И это я еще не заморачивался, а написал первое что в голову пришло.


Аналогично про C#.

AV>>>>Мы уже начали обсуждать меру "подлости" закладки? А то в начале об этом ни слова. А когда оказалось, что подобного рода "закладки" отнюдь не особенность одного только C++, то уже начали вертеться как уж на сковородке.


C>>>Закладка она подлая по определению.


AV>>Тебе напомнить твое первоначальное утверждение? И утверждение, которое было сделано чуть-чуть попозже?


C>Да-да, напомни. Оба желательно. Но если ты посчитал что целью закладки было встраивание тетриса в программу, то можешь не утруждаться.


C>Мы можем поменять код _вне_ функции, и это измнение приведет к изменению логики работы функции и любым побочным эффектам.


C>Мне честно не удается припомнить бомбу схожей мощности и вредоносности в других языках.

... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[24]: Наследование
От: hattab  
Дата: 09.02.12 11:59
Оценка:
Здравствуйте, Sheridan, Вы писали:

Жесткая жесть
avalon 1.0rc3 build 428, zlib 1.2.3
Re[24]: Наследование
От: hattab  
Дата: 09.02.12 12:04
Оценка:
Здравствуйте, Sheridan, Вы писали:

Я только не понял, а виртуальные методы тоже будут работать в такой схеме (т.е. если один из методов неймспейса будет виртуальный, а в неймспейсе потомка будет перекрыт)?
avalon 1.0rc3 build 428, zlib 1.2.3
Re[25]: Наследование
От: Sheridan Россия  
Дата: 09.02.12 12:16
Оценка:
Здравствуйте, hattab, Вы писали:

H>Я только не понял, а виртуальные методы тоже будут работать в такой схеме (т.е. если один из методов неймспейса будет виртуальный, а в неймспейсе потомка будет перекрыт)?

Должны...
Matrix has you...
Re[25]: Наследование
От: Sheridan Россия  
Дата: 09.02.12 12:16
Оценка:
Здравствуйте, hattab, Вы писали:

H>Жесткая жесть


Ну а как ты хотел?
Matrix has you...
Re[26]: Наследование
От: hattab  
Дата: 09.02.12 12:22
Оценка:
Здравствуйте, Sheridan, Вы писали:

S> H>Жесткая жесть


S> Ну а как ты хотел?


На дельфях оно выглядит человечнее
avalon 1.0rc3 build 428, zlib 1.2.3
Re[34]: И снова про ц++
От: Cadet  
Дата: 09.02.12 12:36
Оценка:
Здравствуйте, ambel-vlad, Вы писали:

C>>Ты похоже решил, что цель #define true false была в том, чтобы незаметно сидеть и не отсвечивать. Нет, было продемонстрировано, как можно парализовать работу кучи народу легким движением руки.


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


Ну я прям фигею с вас люди. Вам форумным воителям что ни ошибка — то отловить плевое дело, за утренним распиванием кофе левой пяткой любой баг находится. Откуда ж кривые проги и заковыристые ошибки берутся?

AV>

C>>Мы можем поменять код _вне_ функции, и это измнение приведет к изменению логики работы функции и любым побочным эффектам.

AV>

C>>Мне честно не удается припомнить бомбу схожей мощности и вредоносности в других языках.


Отлично. Ну давай похоливарим на тему, что веселее, обнаружить закладку, которая портит только тот файл, в котором она заложена, или ту, которая может портить в принципе все, до чего дотянулась через цепочку инклюдов. Кстати вполне можно бомбить не такую распространенную вещь как true/false, а точно так же как и в твоем примере тихой сапой подменить через дефайн класс. Или функцию. Тут сишный препроцессор практически неограничен, что хошь то и вороти.
... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
Re[35]: И снова про ц++
От: ambel-vlad Беларусь  
Дата: 09.02.12 12:52
Оценка:
Здравствуйте, Cadet, Вы писали:

C>>>Ты похоже решил, что цель #define true false была в том, чтобы незаметно сидеть и не отсвечивать. Нет, было продемонстрировано, как можно парализовать работу кучи народу легким движением руки.


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


C>Ну я прям фигею с вас люди. Вам форумным воителям что ни ошибка — то отловить плевое дело, за утренним распиванием кофе левой пяткой любой баг находится. Откуда ж кривые проги и заковыристые ошибки берутся?


Ты серьезно считаешь, что сложнее отловить и исправить закладку, которая наследила по всей программе, нежели закладку, которая проявляется в гораздо более редком кол-ве случаев?

AV>>

C>>>Мы можем поменять код _вне_ функции, и это измнение приведет к изменению логики работы функции и любым побочным эффектам.

AV>>

C>>>Мне честно не удается припомнить бомбу схожей мощности и вредоносности в других языках.


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


Угу. Одна закладка проявляется в 99% времени работы программы, а другая в 0.01%. Какую быстрее обнаружат?

C>Кстати вполне можно бомбить не такую распространенную вещь как true/false, а точно так же как и в твоем примере тихой сапой подменить через дефайн класс. Или функцию. Тут сишный препроцессор практически неограничен, что хошь то и вороти.


А никто и не говорил, что такое с плюсах невозможно. В отличии от обратного утверждения.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[24]: Немного причесал
От: Sheridan Россия  
Дата: 09.02.12 13:54
Оценка:
Теперь из "неймспейсов" есть доступ к закрытым членам "базового класса неймспейса", а также чуток меньше памяти будет кушать.

Собственно, макросы:
#define CLASS_NS_BASE(_ns) _ns##base()
#define CLASS_NS_CLASS_NAME(_ns) class_namespace_##_ns

#define CLASS_NS_BEGIN(_ns, _base) \
public: class CLASS_NS_CLASS_NAME(_ns) \
  { \
    private: \
      _base *m_namespace_base; \
    public: \
      CLASS_NS_CLASS_NAME(_ns)(_base *base##_base) { m_namespace_base = base##_base; }; \
      virtual ~CLASS_NS_CLASS_NAME(_ns)() { } \
      virtual _base *CLASS_NS_BASE(_ns) { return m_namespace_base; }

#define CLASS_NS_BEGIN_INHERITS(_ns, _base, _parent) \
public: class CLASS_NS_CLASS_NAME(_ns) : public _parent::CLASS_NS_CLASS_NAME(_ns) \
  { \
    public: \
      CLASS_NS_CLASS_NAME(_ns)(_base *base##_base) : _parent::CLASS_NS_CLASS_NAME(_ns)(base##_base) {} \
      virtual _base *CLASS_NS_BASE(_ns) { return static_cast<_base *>(_parent::CLASS_NS_CLASS_NAME(_ns)::CLASS_NS_BASE(_ns)); }

#define CLASS_NS_END(_ns) \
  }; \
  public: CLASS_NS_CLASS_NAME(_ns) *_ns; \
  friend class CLASS_NS_CLASS_NAME(_ns);

#define CLASS_NS_INIT(_ns) _ns = new CLASS_NS_CLASS_NAME(_ns)(this);
#define CLASS_NS_DELETE(_ns) delete _ns;
#define CLASS_NS_PATH(_ns, _base) _base::CLASS_NS_CLASS_NAME(_ns)


И использование.
#include <iostream>
#include "macros.h"
using namespace std;

// -----------------------------------------------------------------------------------------------------------------------------
class Parent
{
  CLASS_NS_BEGIN(SubNS, Parent)
  void f();
  CLASS_NS_END(SubNS)

  CLASS_NS_BEGIN(OtherNameSpace, Parent)
  void f();
  void other();
  CLASS_NS_END(OtherNameSpace)

  public:
  Parent() { CLASS_NS_INIT(SubNS) CLASS_NS_INIT(OtherNameSpace) }
  ~Parent() { CLASS_NS_DELETE(SubNS) CLASS_NS_DELETE(OtherNameSpace) }
  int c() { return 123; }
};
// ------------------------------------
void CLASS_NS_PATH(SubNS, Parent)::f()
{
  cout << "Hi, " << CLASS_NS_BASE(SubNS)->c()  << " from base!" << endl;
}

void CLASS_NS_PATH(OtherNameSpace, Parent)::other()
{
  cout << "Hi from base other!" << endl;
}

void CLASS_NS_PATH(OtherNameSpace, Parent)::f()
{
  cout << "Hi, " << CLASS_NS_BASE(OtherNameSpace)->c()  << "! This is other namespace :))" << endl;
}

// -----------------------------------------------------------------------------------------------------------------------------
class Child : public Parent
{
  CLASS_NS_BEGIN_INHERITS(SubNS, Child, Parent)
  void foo();
  CLASS_NS_END(SubNS)

  public:
  Child() { CLASS_NS_INIT(SubNS); m_int = 555555; }
  ~Child() { CLASS_NS_DELETE(SubNS) }
  private:
  int m_int;
};
// ------------------------------------
void CLASS_NS_PATH(SubNS, Child)::foo()
{
  cout << "Hi, " << CLASS_NS_BASE(SubNS)->c()  << " from child foo! private m_int: " << CLASS_NS_BASE(SubNS)->m_int << endl;
}

// -----------------------------------------------------------------------------------------------------------------------------
class Deeper : public Child
{
  CLASS_NS_BEGIN_INHERITS(SubNS, Deeper, Child)
  void bar();
  CLASS_NS_END(SubNS)

  CLASS_NS_BEGIN_INHERITS(OtherNameSpace, Deeper, Child)
  void other();
  CLASS_NS_END(OtherNameSpace)

  public:
  Deeper() { CLASS_NS_INIT(SubNS) CLASS_NS_INIT(OtherNameSpace) }
  ~Deeper() { CLASS_NS_DELETE(SubNS) CLASS_NS_DELETE(OtherNameSpace) }
};
// ------------------------------------
void CLASS_NS_PATH(SubNS, Deeper)::bar()
{
  cout << "Hi, " << CLASS_NS_BASE(SubNS)->c()  << " from Deeper bar!" << endl;
}

void CLASS_NS_PATH(OtherNameSpace, Deeper)::other()
{
  cout << "Hi from Deeper other!" << endl;
}

// -----------------------------------------------------------------------------------------------------------------------------
int main ()
{
  Parent *p = new Parent();
  p->SubNS->f();
  p->OtherNameSpace->other();
  p->OtherNameSpace->f();
  delete p;
  cout << "-------------------------" << endl;
  Child *c = new Child();
  c->SubNS->foo();
  c->SubNS->f();
  delete c;
  cout << "-------------------------" << endl;
  Deeper *d = new Deeper();
  d->SubNS->bar();
  d->SubNS->foo();
  d->SubNS->f();
  d->OtherNameSpace->other();
  delete d;
}
Matrix has you...
Re[25]: И после препроцессора, кстати...
От: Sheridan Россия  
Дата: 09.02.12 14:01
Оценка:
Кстати, вот как раз скажите: как без дефайнов вы сможете поддерживать вот такое??? Да и вообще, невозможно получается ориентироваться.
А уж если зайдет речь про некоторую переделку реализации этих неймспейсов, то вот тут вы и присядете надолго...


class Parent
{
  public: class class_namespace_SubNS { private: Parent *m_namespace_base; public: class_namespace_SubNS(Parent *baseParent) { m_namespace_base = baseParent; }; virtual ~class_namespace_SubNS() { } virtual Parent *SubNSbase() { return m_namespace_base; }
  void f();
  }; public: class_namespace_SubNS *SubNS; friend class class_namespace_SubNS;

  public: class class_namespace_OtherNameSpace { private: Parent *m_namespace_base; public: class_namespace_OtherNameSpace(Parent *baseParent) { m_namespace_base = baseParent; }; virtual ~class_namespace_OtherNameSpace() { } virtual Parent *OtherNameSpacebase() { return m_namespace_base; }
  void f();
  void other();
  }; public: class_namespace_OtherNameSpace *OtherNameSpace; friend class class_namespace_OtherNameSpace;

  public:
  Parent() { SubNS = new class_namespace_SubNS(this); OtherNameSpace = new class_namespace_OtherNameSpace(this); }
  ~Parent() { delete SubNS; delete OtherNameSpace; }
  int c() { return 123; }
};

void Parent::class_namespace_SubNS::f()
{
  cout << "Hi, " << SubNSbase()->c() << " from base!" << endl;
}

void Parent::class_namespace_OtherNameSpace::other()
{
  cout << "Hi from base other!" << endl;
}

void Parent::class_namespace_OtherNameSpace::f()
{
  cout << "Hi, " << OtherNameSpacebase()->c() << "! This is other namespace :))" << endl;
}


class Child : public Parent
{
  public: class class_namespace_SubNS : public Parent::class_namespace_SubNS { public: class_namespace_SubNS(Child *baseChild) : Parent::class_namespace_SubNS(baseChild) {} virtual Child *SubNSbase() { return static_cast<Child *>(Parent::class_namespace_SubNS::SubNSbase()); }
  void foo();
  }; public: class_namespace_SubNS *SubNS; friend class class_namespace_SubNS;

  public:
  Child() { SubNS = new class_namespace_SubNS(this);; m_int = 555555; }
  ~Child() { delete SubNS; }
  private:
  int m_int;
};

void Child::class_namespace_SubNS::foo()
{
  cout << "Hi, " << SubNSbase()->c() << " from child foo! private m_int: " << SubNSbase()->m_int << endl;
}


class Deeper : public Child
{
  public: class class_namespace_SubNS : public Child::class_namespace_SubNS { public: class_namespace_SubNS(Deeper *baseDeeper) : Child::class_namespace_SubNS(baseDeeper) {} virtual Deeper *SubNSbase() { return static_cast<Deeper *>(Child::class_namespace_SubNS::SubNSbase()); }
  void bar();
  }; public: class_namespace_SubNS *SubNS; friend class class_namespace_SubNS;

  public: class class_namespace_OtherNameSpace : public Child::class_namespace_OtherNameSpace { public: class_namespace_OtherNameSpace(Deeper *baseDeeper) : Child::class_namespace_OtherNameSpace(baseDeeper) {} virtual Deeper *OtherNameSpacebase() { return static_cast<Deeper *>(Child::class_namespace_OtherNameSpace::OtherNameSpacebase()); }
  void other();
  }; public: class_namespace_OtherNameSpace *OtherNameSpace; friend class class_namespace_OtherNameSpace;

  public:
  Deeper() { SubNS = new class_namespace_SubNS(this); OtherNameSpace = new class_namespace_OtherNameSpace(this); }
  ~Deeper() { delete SubNS; delete OtherNameSpace; }
};

void Deeper::class_namespace_SubNS::bar()
{
  cout << "Hi, " << SubNSbase()->c() << " from Deeper bar!" << endl;
}

void Deeper::class_namespace_OtherNameSpace::other()
{
  cout << "Hi from Deeper other!" << endl;
}


int main ()
{
  Parent *p = new Parent();
  p->SubNS->f();
  p->OtherNameSpace->other();
  p->OtherNameSpace->f();
  delete p;
  cout << "-------------------------" << endl;
  Child *c = new Child();
  c->SubNS->foo();
  c->SubNS->f();
  delete c;
  cout << "-------------------------" << endl;
  Deeper *d = new Deeper();
  d->SubNS->bar();
  d->SubNS->foo();
  d->SubNS->f();
  d->OtherNameSpace->other();
  delete d;
}
Matrix has you...
Re[25]: Наследование
От: Sheridan Россия  
Дата: 09.02.12 14:02
Оценка:
Здравствуйте, _d_m_, Вы писали:

___>Мда... Как сильно я отвык от ц++... Это не код, это какой-то брэйнфак.

Брейнфак после препроцессора, сам сравни
Matrix has you...
Re[26]: И после препроцессора, кстати...
От: hattab  
Дата: 09.02.12 14:30
Оценка:
Здравствуйте, Sheridan, Вы писали:

S> Кстати, вот как раз скажите: как без дефайнов вы сможете поддерживать вот такое??? Да и вообще, невозможно получается ориентироваться.

S> А уж если зайдет речь про некоторую переделку реализации этих неймспейсов, то вот тут вы и присядете надолго...

Хм, а в чем сложность сделать это без дефайнов? Я ведь уже показывал, на дельфях это даже проще делается чем ты показал, без создания объектов даже
avalon 1.0rc3 build 428, zlib 1.2.3
Re[36]: И снова про ц++
От: Cadet  
Дата: 09.02.12 14:51
Оценка:
Здравствуйте, ambel-vlad, Вы писали:

AV>Угу. Одна закладка проявляется в 99% времени работы программы, а другая в 0.01%. Какую быстрее обнаружат?


Ты правда rand() в моем примере здесь
Автор: Cadet
Дата: 07.02.12
не заметил, или даже не смотрел? Вероятность можно и сильно ниже поставить.

C>>Кстати вполне можно бомбить не такую распространенную вещь как true/false, а точно так же как и в твоем примере тихой сапой подменить через дефайн класс. Или функцию. Тут сишный препроцессор практически неограничен, что хошь то и вороти.


AV>А никто и не говорил, что такое с плюсах невозможно. В отличии от обратного утверждения.


Что возвращает нас к моему утверждению про бомбу схожей мощности и т.д. в НЕ с/с++. На сишном препроцессоре можно сделать все что можно в шарповом, и еще дополнительно кучу всего. Да так, что докапываться до причин глюков через ассемблер придется.
... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
Re[26]: И после препроцессора, кстати...
От: FR  
Дата: 09.02.12 15:08
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Кстати, вот как раз скажите: как без дефайнов вы сможете поддерживать вот такое??? Да и вообще, невозможно получается ориентироваться.

S>А уж если зайдет речь про некоторую переделку реализации этих неймспейсов, то вот тут вы и присядете надолго...

Без дефайнов, если нормально отформатировать проще и понятнее.
Re[27]: И после препроцессора, кстати...
От: Sheridan Россия  
Дата: 09.02.12 17:40
Оценка:
Здравствуйте, FR, Вы писали:

FR>Без дефайнов, если нормально отформатировать проще и понятнее.


Да ладно? Пару десятков классов например? ну-ну
Matrix has you...
Re[27]: И после препроцессора, кстати...
От: Sheridan Россия  
Дата: 09.02.12 17:42
Оценка:
Здравствуйте, hattab, Вы писали:

H>Хм, а в чем сложность сделать это без дефайнов? Я ведь уже показывал, на дельфях это даже проще делается чем ты показал, без создания объектов даже

ц++ не поскаль.
Matrix has you...
Re[15]: namespace'ы в классах
От: Ночной Смотрящий Россия  
Дата: 09.02.12 18:13
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Ну тогда, дабы не быть голословным, покажи мне мой трудночитаемый код.


Да ты в этом топике его сам привел. И другие приводили. Из януса, к примеру — это ж пестня.
Re[28]: И после препроцессора, кстати...
От: hattab  
Дата: 09.02.12 18:19
Оценка:
Здравствуйте, Sheridan, Вы писали:

S> H>Хм, а в чем сложность сделать это без дефайнов? Я ведь уже показывал, на дельфях это даже проще делается чем ты показал, без создания объектов даже


S> ц++ не поскаль.


И что вы этим хотели сказать, капитан?
avalon 1.0rc3 build 428, zlib 1.2.3
Re[28]: И после препроцессора, кстати...
От: FR  
Дата: 09.02.12 18:35
Оценка:
Здравствуйте, Sheridan, Вы писали:

FR>>Без дефайнов, если нормально отформатировать проще и понятнее.


S>Да ладно? Пару десятков классов например? ну-ну


Пара десятков подобных дефайнов намного хуже.
Re[16]: namespace'ы в классах
От: Sheridan Россия  
Дата: 09.02.12 20:57
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

S>>Ну тогда, дабы не быть голословным, покажи мне мой трудночитаемый код.

НС>Да ты в этом топике его сам привел. И другие приводили. Из януса, к примеру — это ж пестня.

Что тебе в коде непонятно?
Matrix has you...
Re[29]: И после препроцессора, кстати...
От: Sheridan Россия  
Дата: 09.02.12 20:57
Оценка:
Здравствуйте, hattab, Вы писали:

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


S>> H>Хм, а в чем сложность сделать это без дефайнов? Я ведь уже показывал, на дельфях это даже проще делается чем ты показал, без создания объектов даже


S>> ц++ не поскаль.


H>И что вы этим хотели сказать, капитан?


То и сказал. Без подтекста.
Matrix has you...
Re[30]: И после препроцессора, кстати...
От: hattab  
Дата: 09.02.12 21:01
Оценка:
Здравствуйте, Sheridan, Вы писали:

S> S>> ц++ не поскаль.


S> H>И что вы этим хотели сказать, капитан?


S> То и сказал. Без подтекста.


В таком случае, к чему ты это сказал?
avalon 1.0rc3 build 428, zlib 1.2.3
Re[29]: И после препроцессора, кстати...
От: Sheridan Россия  
Дата: 09.02.12 21:01
Оценка:
Здравствуйте, FR, Вы писали:

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


FR>>>Без дефайнов, если нормально отформатировать проще и понятнее.


S>>Да ладно? Пару десятков классов например? ну-ну


FR>Пара десятков подобных дефайнов намного хуже.


Тоесть до тебя не доходит что пара десятков дефайнов может использоваться в паре тысяч мест например и исправлением одного дефайна можно изменить весь тот остальной код?
Данная конкретная разминка для мозгов — чем плоха? Сравни код с дефайнами и код без дефайнов. Представь что таких классов — полсотни. Я пошлю все нафиг, если меня попросят такое поддерживать.

Не, ну правда, какието ну вообще идионты дефайны наверно писали, да? А другие идиоты все никак из стандарта не уберт, ага.
Matrix has you...
Re[31]: И после препроцессора, кстати...
От: Sheridan Россия  
Дата: 09.02.12 21:07
Оценка:
Здравствуйте, hattab, Вы писали:

S>> S>> ц++ не поскаль.

S>> H>И что вы этим хотели сказать, капитан?
S>> То и сказал. Без подтекста.
H>В таком случае, к чему ты это сказал?

К тому что ц++ не паскаль, чего неясного? Соответственно и реализация будет разная. Смешно от разных языков ждать синтаксически схожего кода.
Matrix has you...
Re[32]: И после препроцессора, кстати...
От: hattab  
Дата: 09.02.12 22:02
Оценка:
Здравствуйте, Sheridan, Вы писали:

S> H>В таком случае, к чему ты это сказал?


S> К тому что ц++ не паскаль, чего неясного?


C этим как раз все ясно

S> Соответственно и реализация будет разная. Смешно от разных языков ждать синтаксически схожего кода.


Ты же сам хотел вариантов на других языках, что не так?
avalon 1.0rc3 build 428, zlib 1.2.3
Re[26]: Наследование
От: _d_m_  
Дата: 10.02.12 01:18
Оценка:
Здравствуйте, Sheridan, Вы писали:

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


___>>Мда... Как сильно я отвык от ц++... Это не код, это какой-то брэйнфак.

S>Брейнфак после препроцессора, сам сравни

Нет. Брейнфак и до, и после.
Re[33]: И после препроцессора, кстати...
От: Sheridan Россия  
Дата: 10.02.12 04:01
Оценка:
Здравствуйте, hattab, Вы писали:

H>Ты же сам хотел вариантов на других языках, что не так?


Все так, просто твое замечание что в паскале все по другому — лишнее, Капитан.
Matrix has you...
Re[4]: И снова про ц++
От: vdimas Россия  
Дата: 10.02.12 05:06
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:


НС>Но поддержка со стороны языка была бы весьма пользительна. Хотя бы в виде шарповских async/await.


Поддержка со стороны языка обязательно будет опираться на некие глобальные данные, т.е. на некий глобальный контекст синхронизации, что не есть гут в современном многопроцессорном мире. Экземпляр контекста надо уметь протягивать явно. В дотнетных async/await содержится неполноценная реализация для бедных.
Re[6]: И снова про ц++
От: vdimas Россия  
Дата: 10.02.12 05:26
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

FR>>Y–комбинаторы рулят:


FR>>
FR>>fib = lambda n : (lambda func, n : func(n, func))(lambda x, rec : x < 2 and 1 or rec(x-1, rec) + rec(x-2, rec), n)
FR>>


НС>Они может и рулят, но тебе не кажется что вариант с локальной функцией будет читаться намного проще?


Если стек вышестоящей ф-ии не захватывать автоматически, а передавать зависимости явно, то вполне достаточна возможность объявления локальных типов (в т.ч. безымянных):
int factorial(int i){
  switch(i) {
  case 0: case 1: return 1;
  default:
    struct { int i; int weNeedToGoDeeper() { return i * factorial(i-1); } } tmp = {i};
    return tmp.weNeedToGoDeeper();
  };
}
Re[34]: И после препроцессора, кстати...
От: hattab  
Дата: 10.02.12 06:50
Оценка:
Здравствуйте, Sheridan, Вы писали:

S> H>Ты же сам хотел вариантов на других языках, что не так?


S> Все так, просто твое замечание что в паскале все по другому — лишнее, Капитан.


Не по другому, а:

Хм, а в чем сложность сделать это без дефайнов? Я ведь уже показывал, на дельфях это даже проще делается чем ты показал, без создания объектов даже


а если ты хотел примеров от других сишников, нужно было так и говорить.
avalon 1.0rc3 build 428, zlib 1.2.3
Re[35]: И после препроцессора, кстати...
От: Sheridan Россия  
Дата: 10.02.12 17:37
Оценка:
Здравствуйте, hattab, Вы писали:

H>Не по другому, а:

H>

Хм, а в чем сложность сделать это без дефайнов? Я ведь уже показывал, на дельфях это даже проще делается чем ты показал, без создания объектов даже

http://www.rsdn.ru/forum/etude/4611727.1.aspx
Автор: Erop
Дата: 10.02.12
Matrix has you...
Re[36]: И после препроцессора, кстати...
От: hattab  
Дата: 10.02.12 19:16
Оценка:
Здравствуйте, Sheridan, Вы писали:

S> H>Не по другому, а:

S> H>

Хм, а в чем сложность сделать это без дефайнов? Я ведь уже показывал, на дельфях это даже проще делается чем ты показал, без создания объектов даже


S> http://www.rsdn.ru/forum/etude/4611727.1.aspx
Автор: Erop
Дата: 10.02.12


А в компилируемом виде можно? Чтоб у методов были параметры + наследование неймспейсов.
avalon 1.0rc3 build 428, zlib 1.2.3
Re[37]: И после препроцессора, кстати...
От: Sheridan Россия  
Дата: 10.02.12 19:22
Оценка:
Здравствуйте, hattab, Вы писали:

S>> http://www.rsdn.ru/forum/etude/4611727.1.aspx
Автор: Erop
Дата: 10.02.12


H>А в компилируемом виде можно? Чтоб у методов были параметры + наследование неймспейсов.

Попробую. И автора тоже попроси, если не трудно — у него похоже побольше опыта.
Matrix has you...
Re[38]: И после препроцессора, кстати...
От: hattab  
Дата: 10.02.12 19:46
Оценка:
Здравствуйте, Sheridan, Вы писали:

S> H>А в компилируемом виде можно? Чтоб у методов были параметры + наследование неймспейсов.


S> Попробую. И автора тоже попроси, если не трудно — у него похоже побольше опыта.


Он же там дал понять, что прочие игрища без него
avalon 1.0rc3 build 428, zlib 1.2.3
Re[5]: И снова про ц++
От: Ночной Смотрящий Россия  
Дата: 10.02.12 20:34
Оценка:
Здравствуйте, vdimas, Вы писали:

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


Новый шарп вполне без этого обходится.

V> Экземпляр контекста надо уметь протягивать явно. В дотнетных async/await содержится неполноценная реализация для бедных.


Опять какие то фантазии?
Re[7]: И снова про ц++
От: Ночной Смотрящий Россия  
Дата: 10.02.12 20:34
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Если стек вышестоящей ф-ии не захватывать автоматически, а передавать зависимости явно, то вполне достаточна возможность объявления локальных типов (в т.ч. безымянных):


Джава уже продемонстрировала, что это не самый удобный способ.
Re[18]: namespace'ы в классах
От: Sheridan Россия  
Дата: 10.02.12 20:36
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, Sheridan, Вы писали:


НС>>>Да ты в этом топике его сам привел. И другие приводили. Из януса, к примеру — это ж пестня.


S>>Что тебе в коде непонятно?


НС>Самое главное — нафига этот изврат вообще.


А вот сейчас ты про какой код?
Matrix has you...
Re[19]: namespace'ы в классах
От: Ночной Смотрящий Россия  
Дата: 10.02.12 20:42
Оценка:
Здравствуйте, Sheridan, Вы писали:

НС>>Самое главное — нафига этот изврат вообще.


S>А вот сейчас ты про какой код?


http://rsdn.ru/forum/janus/1067624.all.aspx
Автор: AndrewVK
Дата: 12.03.05
Re[17]: И снова про ц++
От: Mamut Швеция http://dmitriid.com
Дата: 10.02.12 20:44
Оценка:
O>Некоторые люди разницу между std::string и CString из MFC очень хорошо ощущают и умеют использовать, а
O>то, что для кого-то все эти строки на одно лицо, еще ничего не значит.

Ну-ну. Опиши-ка мне эту разницу

http://msdn.microsoft.com/en-us/library/aa315043(v=vs.60).aspx
http://www.cplusplus.com/reference/string/string/


dmitriid.comGitHubLinkedIn
Re[37]: И после препроцессора, кстати...
От: Erop Россия  
Дата: 10.02.12 22:36
Оценка:
Здравствуйте, hattab, Вы писали:

H>А в компилируемом виде можно? Чтоб у методов были параметры + наследование неймспейсов.


Задачку лучше, наверное, в этюдах обсуждать...

А что такое "наследование неймспейсов"?..
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[20]: namespace'ы в классах
От: Sheridan Россия  
Дата: 11.02.12 05:12
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, Sheridan, Вы писали:


НС>>>Самое главное — нафига этот изврат вообще.


S>>А вот сейчас ты про какой код?


НС>http://rsdn.ru/forum/janus/1067624.all.aspx
Автор: AndrewVK
Дата: 12.03.05


Если мне не изменяет склероз — это копирование настроек их диалога экспорта в конфиг приложения. поля "имя файла", "формат файла", "что экспортировать?"
Это видно прямо из кода.
Matrix has you...
Re[38]: И после препроцессора, кстати...
От: hattab  
Дата: 11.02.12 07:03
Оценка:
Здравствуйте, Erop, Вы писали:

E> H>А в компилируемом виде можно? Чтоб у методов были параметры + наследование неймспейсов.


E> А что такое "наследование неймспейсов"?..


Это чтоб в классе потомке можно было дополнить "неймспейс" новыми методами, перекрыть виртуальные из неймспейса предка.
avalon 1.0rc3 build 428, zlib 1.2.3
Re[39]: И после препроцессора, кстати...
От: Erop Россия  
Дата: 11.02.12 07:15
Оценка:
Здравствуйте, hattab, Вы писали:

E>> А что такое "наследование неймспейсов"?..


H>Это чтоб в классе потомке можно было дополнить "неймспейс" новыми методами, перекрыть виртуальные из неймспейса предка.


Я не совсем понимаю задачу.
Вообще-то, если я верно понял суть проблемы, то достаточно все методы оозвать в стиле namespace_method...

Тогда всё можно.
Но у Шеридана стояло какое-то непонятное требование иметь какие-то подоия интерфейсов, собранных из методов объекта. Понятно, что наследники объекта могут переопределять его виртуальные методы. Наличие каких-то интерфейсов к методам объекта никак этому не мешает. А вот расширять интерфейсы в наследниках объекта -- это очень сложный концепт. Типа надо уметь делать наследников тех интерфейсов? Или что надо уметь?

Если я получил интерфейс от наследника нашего объекта, а потом хочу работать с ним, как с интерфейсом полученным от базового класса, то что должно быть?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[40]: И после препроцессора, кстати...
От: hattab  
Дата: 11.02.12 07:55
Оценка:
Здравствуйте, Erop, Вы писали:

E> Я не совсем понимаю задачу.


Более подробно о задаче.
Автор: hattab
Дата: 07.02.12


E> Вообще-то, если я верно понял суть проблемы, то достаточно все методы оозвать в стиле namespace_method...


Не, не решение

E> Но у Шеридана стояло какое-то непонятное требование иметь какие-то подоия интерфейсов, собранных из методов объекта. Понятно, что наследники объекта могут переопределять его виртуальные методы. Наличие каких-то интерфейсов к методам объекта никак этому не мешает. А вот расширять интерфейсы в наследниках объекта -- это очень сложный концепт. Типа надо уметь делать наследников тех интерфейсов? Или что надо уметь?


E> Если я получил интерфейс от наследника нашего объекта, а потом хочу работать с ним, как с интерфейсом полученным от базового класса, то что должно быть?


Вот задача и заключается в поиске решения при котором будет возможно обычное для ООП использование, в том числе возможность наследования. Понятно же, что нам может захотеться наследоваться от класса с неймспейсами, расширить неймспейс в потомке, перекрыть виртуальный метод неймспейса. Как при этом будут реализованы неймспейсы не говорится. Важно, чтоб задача решалась, и чем безгеморойнее тем лучше
avalon 1.0rc3 build 428, zlib 1.2.3
Re[31]: И после препроцессора, кстати...
От: Sheridan Россия  
Дата: 11.02.12 08:25
Оценка:
Здравствуйте, FR, Вы писали:

FR>Как разминка для мозгов вполне, как код в реальном проекте, к тому же на C++ а не Си, нафиг.

FR>Поддерживать как раз будет проще без дефайнов. Вот представь какой-то нехороший человек нагородил раз в десять
FR>больше и сложнее чем у тебя макросов, ты в первый раз жизни видишь этот код, тебе практически приходится изучить
FR>тот DSL который он наваял и который наверняка глобален для проекта. При этом тебе обычно надо сделать небольшое
FR>локальное исправление, а ошибка в макросе, самое веселое это когда в половине мест использования этого макроса
FR>надо править ошибку а в половине код уже завязан на эту багофичу. И вместо правки небольшого локального участка
FR>у тебя гемморой.

Не до конца понятно — при чем тут маакросы вообще? Можно и на багофичу-неверный результат метода полпроекта завязать, и на долгое удаелние объекта надеяться например. И будут ровно такие же проблемы.

FR>Да сразу скажу что я не абсолютный противник макросов, они вполне допустимы если действуют локально, например

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

S>>Не, ну правда, какието ну вообще идионты дефайны наверно писали, да? А другие идиоты все никак из стандарта не уберт, ага.

FR>Ну в общем да, полумеры какие-то, вообще стыд какой-то, если сравнить с макросами хотя бы из макроассемблеров
FR>не говоря уже скажем про camlp4. Ладно для Си простительно, а Страуструп куда смотрел?
Ну ежели тыт такой вот умный — чего ж свой язык не написал еще?
Matrix has you...
Re[41]: И после препроцессора, кстати...
От: Erop Россия  
Дата: 11.02.12 08:36
Оценка:
Здравствуйте, hattab, Вы писали:

E>> Я не совсем понимаю задачу.


H>Более подробно о задаче.
Автор: hattab
Дата: 07.02.12


Дык это же претензия к IDE, а не С++.

Кроме того, не указана IDE.
me какой-нибудь подойдёт? Я думаю, там можно накодить макрос, который по разметке вроде
///////////////////////
//groupName

соберёт простыню в дерево...

E>> Вообще-то, если я верно понял суть проблемы, то достаточно все методы оозвать в стиле namespace_method...


H>Не, не решение

Почему?

E>> Если я получил интерфейс от наследника нашего объекта, а потом хочу работать с ним, как с интерфейсом полученным от базового класса, то что должно быть?


H>Вот задача и заключается в поиске решения при котором будет возможно обычное для ООП использование, в том числе возможность наследования. Понятно же, что нам может захотеться наследоваться от класса с неймспейсами, расширить неймспейс в потомке, перекрыть виртуальный метод неймспейса. Как при этом будут реализованы неймспейсы не говорится. Важно, чтоб задача решалась, и чем безгеморойнее тем лучше


Дык namespace_method для всего годиться...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[32]: И после препроцессора, кстати...
От: FR  
Дата: 11.02.12 08:49
Оценка:
Здравствуйте, Sheridan, Вы писали:


S>Не до конца понятно — при чем тут маакросы вообще? Можно и на багофичу-неверный результат метода полпроекта завязать, и на долгое удаелние объекта надеяться например. И будут ровно такие же проблемы.


Искать и править ошибки в макросах гораздо тяжелее.

FR>>Да сразу скажу что я не абсолютный противник макросов, они вполне допустимы если действуют локально, например

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

Ничем в теории, а на практике если не останавливать и до такого доходит:

 void LispInit_isomorphic() {
   static LSymbol TREE1("TREE1");
   static LSymbol TREE2("TREE2");
   ////////////////////////////////////////////////
   //
   (L|DEFUN, ISOMORPHIC, (L|TREE1, TREE2),
     (L|COND, 
       (L|(L|ATOM, TREE1), (L|ATOM, TREE2)),
       (L|(L|ATOM, TREE2), NIL),
       (L|T, (L|AND,
         (L|ISOMORPHIC, (L|CAR, TREE1), 
                        (L|CAR, TREE2)),
         (L|ISOMORPHIC, (L|CDR, TREE1), 
                        (L|CDR, TREE2))
   )))).Evaluate();
   //
   ////////////////////////////////////////////////
 }


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

S>Ну ежели тыт такой вот умный — чего ж свой язык не написал еще?


Не нравится мне с бородой ходить
Re[5]: namespace'ы в классах
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 11.02.12 09:32
Оценка:
Здравствуйте, Sheridan, Вы писали:

L>>У нас, программистов, такой "код" на код ревью летит в помойку, а его аффтар отправляется в ссылку править баги в быдлокоде.

S>Измельчали программисты, измельчали. Очень наглядно сказывается понижение порога — в профессию лезут недоучки и их все больше. И все бы ничего, но эти самые недоучки начинают своей массой (не умом) выдавливать нормальных людей из профессии, попутно объявляя используемые более старшими программистами инструменты источником ошибок и тратой времени. Хотя на самом деле эти недоучки лишь не могут разобраться в этих инструментах, не знают с какого края подходить и соответственно не имеют опыта работы с ними.
S>Плохо. Очень плохо.
S>Я очень надеюсь что производительность компов упрется в потолок и наконецто придется писать нормальный софт, не надеясь на мощность компьютеров.

Хороший, годный прогон.
Только вот встречный вопрос: зачем ты на это надеешься? Если "производительность компов упрется в потолок", то плохо станет всем. И то, что для тебя сейчас игра, станет нудной обязанностью. Неужели это того для тебя стоит — всеобщие проблемы только чтобы показать некоторым остальным, в чём они, по-твоему, неправы?
The God is real, unless declared integer.
Re[21]: namespace'ы в классах
От: Ночной Смотрящий Россия  
Дата: 11.02.12 09:41
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Если мне не изменяет склероз — это копирование настроек их диалога экспорта в конфиг приложения. поля "имя файла", "формат файла", "что экспортировать?"

S>Это видно прямо из кода.

А просто присвоить, без свитчей, религия помешала?
Re[22]: namespace'ы в классах
От: Sheridan Россия  
Дата: 11.02.12 12:27
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>А просто присвоить, без свитчей, религия помешала?


А в шарпах энумы тоже числа?
Matrix has you...
Re[26]: Стоп
От: Sheridan Россия  
Дата: 11.02.12 12:35
Оценка:
Здравствуйте, Jesmus, Вы писали:

J>2) "Если что-то можно записать на макросах — так и надо поступить. ..." (с) Шеридан.

Стоп стоп. Давай ты сначала приведешь ссылочку в туда где я так говорил. А то у тебя получается классический политический ход: берем два общеизвестных факта, плюсуем к ним свою выдумку в начало и на выходе вполне правдиво звучащая фраза.
Matrix has you...
Re[23]: namespace'ы в классах
От: Cadet  
Дата: 11.02.12 14:01
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>А в шарпах энумы тоже числа?


Да уж, мужик. Нет слов даже.
enum Test
{
    Val1,
    Val2
}

class Program
{
    static void Main(string[] args)
  {
    Test tst = Test.Val1;
    System.Console.WriteLine((int)tst);
    
    int val = 1;
    System.Console.WriteLine((Test)val);
  }
}
... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
Re[24]: namespace'ы в классах
От: Sheridan Россия  
Дата: 11.02.12 15:33
Оценка:
Здравствуйте, Cadet, Вы писали:

S>>А в шарпах энумы тоже числа?

C>Да уж, мужик. Нет слов даже.
Ок. Я написал излишне объемный код вместо компактного. Можно я отрежу себе ухо?

Но у меня появляются два вопроса:
1. Почему этот код не переписал сам АВК, а предпочел спихнуть это на меня?
2. Почему эту мелочь вспоминают до сих пор, по истечении шести(?) лет?

Предполагаю ответы 1: лень. 2: больше ничего не нашли.
Matrix has you...
Re[24]: namespace'ы в классах
От: Sheridan Россия  
Дата: 11.02.12 15:34
Оценка:
Здравствуйте, Cadet, Вы писали:

S>>А в шарпах энумы тоже числа?

C>Да уж, мужик. Нет слов даже.
И да, я всетаки не шарпей, чтобы знать тонкости этого самого шарпа... Впрочем да, мог и догадаться...
Matrix has you...
Re[27]: Стоп
От: Mamut Швеция http://dmitriid.com
Дата: 12.02.12 08:28
Оценка:
J>>2) "Если что-то можно записать на макросах — так и надо поступить. ..." (с) Шеридан.
S>Стоп стоп. Давай ты сначала приведешь ссылочку в туда где я так говорил. А то у тебя получается классический политический ход: берем два общеизвестных факта, плюсуем к ним свою выдумку в начало и на выходе вполне правдиво звучащая фраза.

Почему тебе можно, а нам — нельзя?


dmitriid.comGitHubLinkedIn
Re[42]: И после препроцессора, кстати...
От: hattab  
Дата: 12.02.12 10:10
Оценка:
Здравствуйте, Erop, Вы писали:

E> H>Более подробно о задаче.
Автор: hattab
Дата: 07.02.12


E> Дык это же претензия к IDE, а не С++.


Вот жеж народ... Шеридан дважды уж написал, что это не корысти ради, а токмо волею пославшей мя жены не практическая задача, а так, разминка, нет упорно продолжают говорить об IDE (напоминаю: была претензия к языку, Шеридан хочет решение средствами языка. Кроме того, я сомневаюсь, что кто-то предложит решение подходящее для всех существующих IDE).

E> H>Вот задача и заключается в поиске решения при котором будет возможно обычное для ООП использование, в том числе возможность наследования. Понятно же, что нам может захотеться наследоваться от класса с неймспейсами, расширить неймспейс в потомке, перекрыть виртуальный метод неймспейса. Как при этом будут реализованы неймспейсы не говорится. Важно, чтоб задача решалась, и чем безгеморойнее тем лучше


E> Дык namespace_method для всего годиться...


Само именование в таком стиле негодное, из соображений сохранения стиля, положим.
avalon 1.0rc3 build 428, zlib 1.2.3
Re[28]: Стоп
От: Sheridan Россия  
Дата: 12.02.12 11:04
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Почему тебе можно, а нам — нельзя?

Это где я так делал?
Matrix has you...
Re[29]: Стоп
От: Mamut Швеция http://dmitriid.com
Дата: 12.02.12 11:09
Оценка:
M>>Почему тебе можно, а нам — нельзя?
S>Это где я так делал?

Везде, где выдаешь свои фантазии за абсолютную истину.


dmitriid.comGitHubLinkedIn
Re[43]: И после препроцессора, кстати...
От: Erop Россия  
Дата: 12.02.12 13:59
Оценка:
Здравствуйте, hattab, Вы писали:

E>> Дык это же претензия к IDE, а не С++.


H>Вот жеж народ... Шеридан дважды уж написал, что это не корысти ради, а токмо волею пославшей мя жены не практическая задача, а так, разминка, нет упорно продолжают говорить об IDE (напоминаю: была претензия к языку, Шеридан хочет решение средствами языка. Кроме того, я сомневаюсь, что кто-то предложит решение подходящее для всех существующих IDE).


Шеридан да одну формулировку, ты процитировал другую. Та, которую ты процитировал -- претензия чисто к IDE...

E>> H>Вот задача и заключается в поиске решения при котором будет возможно обычное для ООП использование, в том числе возможность наследования. Понятно же, что нам может захотеться наследоваться от класса с неймспейсами, расширить неймспейс в потомке, перекрыть виртуальный метод неймспейса. Как при этом будут реализованы неймспейсы не говорится. Важно, чтоб задача решалась, и чем безгеморойнее тем лучше


E>> Дык namespace_method для всего годиться...


H>Само именование в таком стиле негодное, из соображений сохранения стиля, положим.


Не понимаю. Вот положим я придумаю как назвать метоы в стие namespace::method, то чем это будет принципиально отличаться от namespace_method?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[45]: И после препроцессора, кстати...
От: Erop Россия  
Дата: 12.02.12 15:37
Оценка:
Здравствуйте, hattab, Вы писали:


E>> Шеридан да одну формулировку, ты процитировал другую. Та, которую ты процитировал -- претензия чисто к IDE...


H>Я цитировал с чего весь разговор начался, если ты не понял. Это была претензия к языку т.к. оно должно бы работать вне зависимости от IDE.


Кто там о чём м с кем говорил -- это факты вашей биографии и только. Если речь об ЭТЮДЕ, то некисло бы его сформулировать. У Шеридана была одна формулировка, неясна, но про текст на языке. А то, что ты процитировал -- это претензия к IDE...
А в чём этюд -- не ясно. Видимо в том, чтобы написать плагин к студии?

H>Наличием иерархии.

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

H>Впрочем, я тебя убеждать не собираюсь. Нет ответа ну и ладно.

Скорее у тебя нет вопроса
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[23]: namespace'ы в классах
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.02.12 16:16
Оценка:
Здравствуйте, Sheridan, Вы писали:

НС>>А просто присвоить, без свитчей, религия помешала?


S>А в шарпах энумы тоже числа?


Да.
Re[46]: И после препроцессора, кстати...
От: hattab  
Дата: 12.02.12 16:42
Оценка:
Здравствуйте, Erop, Вы писали:

E> H>Я цитировал с чего весь разговор начался, если ты не понял. Это была претензия к языку т.к. оно должно бы работать вне зависимости от IDE.


E> Кто там о чём м с кем говорил -- это факты вашей биографии и только.


Коли ты отвечаешь в топик, было бы неплохо полюбопытствовать, не считаешь? И еще раз обращаю твое внимание на выделенное.

E> H>Наличием иерархии.


E> С этого места, пожалуйста, поподробнее. Раз ты говоришь "иерархия", значит ты подразумеваешь возможность каких-то групповых операций, над уровнями иерархии. Каких конкретно?


Я тебе ответил чем отличаются два способа и только. Знаешь, так до бесконечности можно задавать вопрос типа: а еще чего нибудь? И этот процесс будет бесконечным.

E> H>Впрочем, я тебя убеждать не собираюсь. Нет ответа ну и ладно.


E> Скорее у тебя нет вопроса


А это и был не мой вопрос Мне просто интересно, как оно будет на сях++ решено, для сравнения.
avalon 1.0rc3 build 428, zlib 1.2.3
Re[47]: И после препроцессора, кстати...
От: Erop Россия  
Дата: 12.02.12 17:21
Оценка:
Здравствуйте, hattab, Вы писали:

H>Коли ты отвечаешь в топик, было бы неплохо полюбопытствовать, не считаешь? И еще раз обращаю твое внимание на выделенное.


Я предлагал тебе обсуждать этюд в "этюдах"...
Если ты не понял, меня ваш смешной срач про С++ не особо интересует. А этюды могут быть интересными...

H>Я тебе ответил чем отличаются два способа и только. Знаешь, так до бесконечности можно задавать вопрос типа: а еще чего нибудь? И этот процесс будет бесконечным.


Я не понимаю, чем "иерархия" namespace_method отличается от иерархии namespace::method.
Вот если бы со всем уровнем иерархии можно было что-то сделать тогда понятно бы было.

Кроме того, в оригинальном запросе вообще речь шла не про иерархию, а про ттрибутироваие уже имеющихся методов для IDE...

H>А это и был не мой вопрос Мне просто интересно, как оно будет на сях++ решено, для сравнения.

Чтобы что-то решить, надо понять что решать...

ты, в отличии от Шеридана, так и не смог внятно объяснить что реализовать-то надо? Плагин к вижуалке? Ну довольно прямо реализуется, вообще-то. Но это не интересно.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[24]: namespace'ы в классах
От: m e  
Дата: 12.02.12 17:57
Оценка:
S>>А в шарпах энумы тоже числа?

C>Да уж, мужик. Нет слов даже.


в жабке энумы это не числа (причем существенно не числа), так что слова есть
Re[48]: И после препроцессора, кстати...
От: hattab  
Дата: 12.02.12 19:25
Оценка:
Здравствуйте, Erop, Вы писали:

E> H>Коли ты отвечаешь в топик, было бы неплохо полюбопытствовать, не считаешь? И еще раз обращаю твое внимание на выделенное.


E> Я предлагал тебе обсуждать этюд в "этюдах"...


Да какая разница "где" В КСВ часто пишут т.к. именно тут можно получить быстрый ответ, а можно и...

E> Если ты не понял, меня ваш смешной срач про С++ не особо интересует. А этюды могут быть интересными...


Наш? Ты бы не обобщал... Я тут исключительно в ожидании решения.

E> Я не понимаю, чем "иерархия" namespace_method отличается от иерархии namespace::method.

E> Вот если бы со всем уровнем иерархии можно было что-то сделать тогда понятно бы было.

Ну так с уровнем иерархии вообще-то можно кое что делать. У уровня, например, может быть перечислитель. Скажем уровень Controls позволит перечислять контролы, и будет иметь методы типа Add, Insert, Remove и подобные.

E> Кроме того, в оригинальном запросе вообще речь шла не про иерархию, а про ттрибутироваие уже имеющихся методов для IDE...


Атрибутирование это только один из вариантов, и лишь как дополнительный
Автор: hattab
Дата: 07.02.12
. Но и для него решения не предложили

E> H>А это и был не мой вопрос Мне просто интересно, как оно будет на сях++ решено, для сравнения.


E> Чтобы что-то решить, надо понять что решать...


E> ты, в отличии от Шеридана, так и не смог внятно объяснить что реализовать-то надо?


Выше, по ссылочке, суть постановка задачи. Тут
Автор: hattab
Дата: 11.02.12
мои дополнительные пояснения. Если тебе еще что-то непонятно давай просто завяжем.

E> Плагин к вижуалке? Ну довольно прямо реализуется, вообще-то. Но это не интересно.


Сто раз уже сказал, что IDE тут ни причем. Говорим о решении вообще, средствами языка (ибо претензия к языку), а не о частном случае для какой либо IDE.
avalon 1.0rc3 build 428, zlib 1.2.3
Re[49]: И после препроцессора, кстати...
От: Erop Россия  
Дата: 12.02.12 20:15
Оценка:
Здравствуйте, hattab, Вы писали:

H>Коли ты отвечаешь в топнет ик, было бы неплохо полюбопытствовать, не считаешь? И еще раз обращаю твое внимание на выделенное.


E>> Я предлагал тебе обсуждать этюд в "этюдах"...


H>Да какая разница "где" В КСВ часто пишут т.к. именно тут можно получить быстрый ответ, а можно и...


Если нет разницы где отвечать не свисти про топик...

H>Я тут исключительно в ожидании решения.

Решения чего?

H>Ну так с уровнем иерархии вообще-то можно кое что делать. У уровня, например, может быть перечислитель. Скажем уровень Controls позволит перечислять контролы, и будет иметь методы типа Add, Insert, Remove и подобные.


Не понял. Речь идёт о интерфейсе для доступа к контролам, озволяющем их переислить, или о раздели методов класса, позволяющем перечислить методы? Если первое, то не ясно вообще при чём тут задача Шеридана, если второе, то как ты себе это вообще на С++ представлешь?

H>Сто раз уже сказал, что IDE тут ни причем. Говорим о решении вообще, средствами языка (ибо претензия к языку), а не о частном случае для какой либо IDE.


Тогда сформулируй задачу на уровне языка, не привлекая IDE в формулировку...

И лучше таки в "этюдах"...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[50]: И после препроцессора, кстати...
От: hattab  
Дата: 12.02.12 21:20
Оценка:
Здравствуйте, Erop, Вы писали:

E> E>> Я предлагал тебе обсуждать этюд в "этюдах"...


E> H>Да какая разница "где" В КСВ часто пишут т.к. именно тут можно получить быстрый ответ, а можно и...


E> Если нет разницы где отвечать не свисти про топик...


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

E> H>Я тут исключительно в ожидании решения.


E> Решения чего?




E> H>Ну так с уровнем иерархии вообще-то можно кое что делать. У уровня, например, может быть перечислитель. Скажем уровень Controls позволит перечислять контролы, и будет иметь методы типа Add, Insert, Remove и подобные.


E> Не понял. Речь идёт о интерфейсе для доступа к контролам, озволяющем их переислить, или о раздели методов класса, позволяющем перечислить методы?


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

E> Тогда сформулируй задачу на уровне языка, не привлекая IDE в формулировку...


E> И лучше таки в "этюдах"...


Если ты все перечитал и все еще не понял... Всем спасибо, все свободны.
avalon 1.0rc3 build 428, zlib 1.2.3
Re[8]: И снова про ц++
От: vdimas Россия  
Дата: 12.02.12 21:35
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

V>>Если стек вышестоящей ф-ии не захватывать автоматически, а передавать зависимости явно, то вполне достаточна возможность объявления локальных типов (в т.ч. безымянных):


НС>Джава уже продемонстрировала, что это не самый удобный способ.


Это было задолго до Явы, но и в Яве как анонимные классы, так и локальные весьма популярны, так же как в плюсах,
они позволяют меньше засорять общее пространство типов частностями. Да, решают ту же задачу, что и ФП-замыкания, только в ООП-стиле. И, в отличие от замыканий, позволяют переопределять виртуальные методы, что тоже порой оч удобно, коль речь именно об ООП.
Re[25]: namespace'ы в классах
От: Ночной Смотрящий Россия  
Дата: 12.02.12 22:13
Оценка:
Здравствуйте, m e, Вы писали:

ME>в жабке энумы это не числа (причем существенно не числа), так что слова есть


Не переживай, на джаве Шеридан вообще ничего не писал.
Re[5]: namespace'ы в классах
От: landerhigh Пират  
Дата: 12.02.12 22:46
Оценка:
Здравствуйте, Sheridan, Вы писали:

L>>У нас, программистов, такой "код" на код ревью летит в помойку, а его аффтар отправляется в ссылку править баги в быдлокоде.

S>Измельчали программисты, измельчали. Очень наглядно сказывается понижение порога — в профессию лезут недоучки и их все больше.

Какой хороший наброс! Долго сочинял?
www.blinnov.com
Re[6]: namespace'ы в классах
От: vdimas Россия  
Дата: 13.02.12 01:54
Оценка:
Здравствуйте, landerhigh, Вы писали:

L>>>У нас, программистов, такой "код" на код ревью летит в помойку, а его аффтар отправляется в ссылку править баги в быдлокоде.

S>>Измельчали программисты, измельчали. Очень наглядно сказывается понижение порога — в профессию лезут недоучки и их все больше.

L>Какой хороший наброс! Долго сочинял?


Да ты тоже как бы набросил перед этим... как-то по-детски, что-ле, отдает максимализмом и неопытностью. Очень похоже на аналог действия Саттера & Co на неокрепший ум буквально первые пару-тройку лет после прочтения... Так что получил заслуженно в ответ. Иногда дается задача и диктуется инструмент под нее (много чем может диктоваться). И вот видишь, что инструмент задаче не канает, а делать нефиг — закатываешь рукава и пашешь. А такие как ты канитель разводят, да об "идеальном коде" рассуждают. Хотя тот самый "идеальный код" в начале любых работ по улучшению эффективности продукта практически первым летит фтопку, бо лечению обычно не поддается... бо не является даже достаточным сниппетом, слишком много торчит "внутренних зависимостей", которые сугубо для простоты и читабельности скрывают много важных вещей, что в случае плюсов зачастую бывает приговором. Зато корявый с виду, но годный для доработки код, зачастую причесывается до состояния вменяемости и спокойно живет далее.

В приведенном Шериданом никакой сложности нет, даже смешно читать эти заламывания рук. Тьфу.
Понятно, что конкретно задача декомпозии жирных классов решается иначе, это я вообще про случаи, когда приходится решать задачи тем, что есть под руками или диктуется извне.
Re[7]: namespace'ы в классах
От: landerhigh Пират  
Дата: 13.02.12 02:36
Оценка:
Здравствуйте, vdimas, Вы писали:

L>>>>У нас, программистов, такой "код" на код ревью летит в помойку, а его аффтар отправляется в ссылку править баги в быдлокоде.

S>>>Измельчали программисты, измельчали. Очень наглядно сказывается понижение порога — в профессию лезут недоучки и их все больше.

L>>Какой хороший наброс! Долго сочинял?


V>Да ты тоже как бы набросил перед этим... как-то по-детски, что-ле, отдает максимализмом и неопытностью.


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

V>Очень похоже на аналог действия Саттера & Co на неокрепший ум буквально первые пару-тройку лет после прочтения... Так что получил заслуженно в ответ.


Что? Получил в ответ? Где? Не вижу!

V> Иногда дается задача и диктуется инструмент под нее (много чем может диктоваться). И вот видишь, что инструмент задаче не канает, а делать нефиг — закатываешь рукава и пашешь. А такие как ты канитель разводят, да об "идеальном коде" рассуждают.


Вот додумывание за собеседника плюс переход на личности и есть как раз признак юношеского максимализма и неопытности. Прощайте, молодой человек, можете даже не беспокоиться с ответом.
www.blinnov.com
Re[51]: И после препроцессора, кстати...
От: Erop Россия  
Дата: 13.02.12 02:41
Оценка:
Здравствуйте, hattab, Вы писали:

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


А не надо "одно и то же", надо внятно сформулировать этюд...

H>Ты чего такой трудный то? Про перечислитель я тебе намекнул, отвечая на твой вопрос, чтоб ты понял наконец зачем может быть нужна настоящая иерархия, а не псевдо-иерархия основанная на именовании методов. И речь не о перечислении методов, а о перечислении дочерних контролов, например. Еще раз повторяю для тебя — перечислитель это пример, изначально о нем речи не шло.


E>> Тогда сформулируй задачу на уровне языка, не привлекая IDE в формулировку...


E>> И лучше таки в "этюдах"...


H>Если ты все перечитал и все еще не понял... Всем спасибо, все свободны.


Если честно, то я совсем ничего не понял. У тебя какая-то мешанина из итераторов то ли методов то ли подобъектов, IDE и каких-то мутных претензий к с++...

Внятной формулировки этюда ни разу не видел...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[3]: namespace'ы в классах
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 13.02.12 10:51
Оценка:
Здравствуйте, Sheridan, Вы писали:

XC>>Невозможность создания namespace внутри класса (вспомните хотя-бы "главные оконные классы" разных библиотек — CWnd, QWidget... сотни методов, там разделение не помешало бы)


S>Ну если очень надо — можно и нарисовать, благо нетрудно. У меня — не программиста — ушло гдето минут 10...


"У меня — не программиста" — нынче ИТ устроен так, что админы, тестировщики, разработчики и даже безопасники по факту являются программистами. Очевидно, что не любой программист есть разработчик ПО. Так шта...
Re[4]: namespace'ы в классах
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 13.02.12 10:53
Оценка:
Здравствуйте, landerhigh, Вы писали:

L>Все же этому сайту очень не хватает в качестве оценки напуганного смайлика с огромными от ужаса глазами.


L>У нас, программистов, такой "код" на код ревью летит в помойку, а его аффтар отправляется в ссылку править баги в быдлокоде.


Оказывается быдлокод есть и в ваших проектах... Это что же, совсем недавно ты ты рассказывал нам сказки ?
Re[4]: namespace'ы в классах
От: Sheridan Россия  
Дата: 13.02.12 14:27
Оценка:
Здравствуйте, Ikemefula, Вы писали:

S>>Ну если очень надо — можно и нарисовать, благо нетрудно. У меня — не программиста — ушло гдето минут 10...


I>"У меня — не программиста" — нынче ИТ устроен так, что админы, тестировщики, разработчики и даже безопасники по факту являются программистами. Очевидно, что не любой программист есть разработчик ПО. Так шта...


Да не вопрос. "У меня — не разработчика ПО..."
Matrix has you...
Re: И снова про ц++
От: zverjuga Беларусь  
Дата: 13.02.12 15:44
Оценка:
язык С++ очень люблю. не нравится в нем только одна вещь — макросы (дефайны). считаю их вселенским злом, так как при освоении какой нить сторонней либы почему то любят в макросы запихивать столько шелухи, что надо серьезно поломать голову, чтобы заставить чужой проект работать в своем коде. в качестве примера могу привести практически любую кроссплатформенную графическую библиотеку.

что касается указателей, корректной работе с памятью (выделение и удаление), то не считаю это сложным. при соблюдении несложных правил, управление памятью в плюсах немногим сложнее работы с памятью в других языках (например, objective c). а если чел когда нить работал с ассмеблером, то для него указатели в плюсах — это родная стихия.
проклятый антисутенерский закон
Re[2]: И снова про ц++
От: Sheridan Россия  
Дата: 13.02.12 16:35
Оценка:
Здравствуйте, zverjuga, Вы писали:

Z>язык С++ очень люблю. не нравится в нем только одна вещь — макросы (дефайны). считаю их вселенским злом,

Мсье, целевой наброс?
Matrix has you...
Re[3]: И снова про ц++
От: zverjuga Беларусь  
Дата: 13.02.12 16:39
Оценка:
Здравствуйте, Sheridan, Вы писали:

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


Z>>язык С++ очень люблю. не нравится в нем только одна вещь — макросы (дефайны). считаю их вселенским злом,

S>Мсье, целевой наброс?

опыт.
проклятый антисутенерский закон
Re[4]: И снова про ц++
От: Sheridan Россия  
Дата: 13.02.12 16:43
Оценка:
Здравствуйте, zverjuga, Вы писали:

Z>>>язык С++ очень люблю. не нравится в нем только одна вещь — макросы (дефайны). считаю их вселенским злом,

S>>Мсье, целевой наброс?
Z>опыт.
Да ладно, не стесняйся, все свои
Matrix has you...
Re[5]: namespace'ы в классах
От: Tanker  
Дата: 13.02.12 18:38
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>>>Ну если очень надо — можно и нарисовать, благо нетрудно. У меня — не программиста — ушло гдето минут 10...


I>>"У меня — не программиста" — нынче ИТ устроен так, что админы, тестировщики, разработчики и даже безопасники по факту являются программистами. Очевидно, что не любой программист есть разработчик ПО. Так шта...


S>Да не вопрос. "У меня — не разработчика ПО..."


"У меня, не профессионального шофера, накачать камеру ..." Ну, ты понял
The animals went in two by two, hurrah, hurrah...
Re[5]: namespace'ы в классах
От: Privalov  
Дата: 13.02.12 20:18
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Измельчали программисты, измельчали. Очень наглядно сказывается понижение порога — в профессию лезут недоучки и их все больше. И все бы ничего, но эти самые недоучки начинают своей массой (не умом) выдавливать нормальных людей из профессии, попутно объявляя используемые более старшими программистами инструменты источником ошибок и тратой времени. Хотя на самом деле эти недоучки лишь не могут разобраться в этих инструментах, не знают с какого края подходить и соответственно не имеют опыта работы с ними.


А прикинь, как математики измельчали. Не хотят почему-то использовать римские цифры при записи чисел. Перешли на позиционные системы счисления. И теперь любой школьник выполняет арифметические действия без особых проблем. Не хотят разбираться в римских цифрах, считают их источником ошибок и тратой времени.

S>Плохо. Очень плохо.

S>Я очень надеюсь что производительность компов упрется в потолок и наконецто придется писать нормальный софт, не надеясь на мощность компьютеров.

Следует ли это понимать так, что ты хочешь ввести для разработчиков условия, о которых как-то писал Pavel Dvorkin здесь:

Вот если бы было введено ограничение по количеству переменных в программе (вот тебе 100 на программу и крутись как хочешь ,


Если так, то кому от этого станет легче? А если нет, что ты сам можешь предложить? Или ты просто поговорить?
Re[6]: namespace'ы в классах
От: Sheridan Россия  
Дата: 13.02.12 22:04
Оценка:
Здравствуйте, Tanker, Вы писали:

T>"У меня, не профессионального шофера, накачать камеру ..." Ну, ты понял

Нет, не понял. А вот ты понял, вообще читал топик? Чегото я тебя не вижу в нем, вообще. Ты кто?
Но лучше не рассказывай про себя, а пойди вон покодь в углу попытайся, может там лучше получится, чем тут попытаться в разговор старших влезать
Matrix has you...
Re[8]: namespace'ы в классах
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 14.02.12 08:13
Оценка:
Здравствуйте, Tanker, Вы писали:

S>>Ой передергиваешь. Римские цифры от арабских отличаются только при письме. Считать надо ровно также уметь. И если математика попросить римскими цифрами писать — он недельку привыкать будет, а потом обратно в колею войдет.

S>>А вот ежели шарпея например или там заводчиков земноводных вдруг за ц++ посадить — ВНЕЗАПНО окажется что ой. Не хватает в головах и надо доучиваться.
T>Когда шарпей садится за с++ все что нужно это вспомнить указатели и забыть про вкусные фичи.

Интересно, как можно "вспомнить" то, что никогда не знал? Значительная часть "шарпеев", явистов и т.д. уже никогда не писала под языки, где указатели, ручное распределение памяти и явный вызов free().

T> А вот когда ц++ садится за чтото посильнее, начинается ОЙ — не хватает знаний по ООП, Дизайну.


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

T>ц++ путают ссылки с указателями,


Вот как раз выходцы с C++ их никогда не путают, потому что в C++ есть оба понятия и они заметно разнятся.

Ещё примеров? А то твой текущий набор как-то неубедителен.

T> кричат на каждом углу "александреску не нужен" и продолжают рожать монстров еще страшнее тех что у александреску. Твои макросы именно такие


Нормальные макросы. Я бы в таком виде, наверно, не делал, но мне и задача такая пока не приходила.
The God is real, unless declared integer.
Re[9]: namespace'ы в классах
От: Tanker  
Дата: 14.02.12 09:37
Оценка:
Здравствуйте, netch80, Вы писали:

S>>>А вот ежели шарпея например или там заводчиков земноводных вдруг за ц++ посадить — ВНЕЗАПНО окажется что ой. Не хватает в головах и надо доучиваться.

T>>Когда шарпей садится за с++ все что нужно это вспомнить указатели и забыть про вкусные фичи.

N>Интересно, как можно "вспомнить" то, что никогда не знал? Значительная часть "шарпеев", явистов и т.д. уже никогда не писала под языки, где указатели, ручное распределение памяти и явный вызов free().


Значительная часть шарпеев это бывшие ц++. Вдобавок, указатели в шарпе имеются, сюрприз ! Явное управление ресурсами это the must — IDisposable. Вот с конструкторами-десктрукторами и исключениями могут быть проблемы. Шарпею и в голову может не прийти, что исключения могут работать наполовину

N>В чём-то, наверно, не хватает. Только не в ООП или дизайне, а в специфике реализации. Я тут в соседней дискуссии упорно называл интерфейсы классами, потому что для меня это специальные варианты класса, а собеседники не понимали — у них это уже несочетаемые понятия. Вот на таком — да, можно нарваться. Или в специфических шарповских фичах вроде делегатов или Linq. А при чём тут дизайн или ООП в общем?


при том, что ц++ обычно работают на низком уровне. ха-ха.

T>>ц++ путают ссылки с указателями,


N>Вот как раз выходцы с C++ их никогда не путают, потому что в C++ есть оба понятия и они заметно разнятся.


Высказывания "Banned by IT" хороший пример ?
* и & это фигня. Сама идея получать указатель по ссылке однозначно демонстрирует ущербность реализации. Ссылка это всегда идентити, а в с++ ссылка неразрывно связана с указателями, а потому чуть более чем все ц++ яростно доказывают что это вообще одно и то же
The animals went in two by two, hurrah, hurrah...
Re[17]: namespace'ы в классах
От: blackhearted Украина  
Дата: 14.02.12 09:49
Оценка:
Здравствуйте, Sheridan, Вы писали:

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


N>>>>>Такого рода отношение к проекту, в котором участвуешь, неприемлемо как для меня, независимо от того, он платный, бесплатный, открытый, или какой-то ещё.

P>>>>Целая толпа народу пытается объяснить это мсье д'Артаньяну черт знает сколько времени.
S>>>А Дарт Аньян все никак не может донести толпе, что работать в сторону интереса намного продуктивнее, нежели работать в сторону необходимости. Например, сравни сколько жил авалон в мусорке и за сколько я его привел в порядок и добавил в туда несколько вкусных возможностей

M>>Например, напрочь поломав кодировку старых сообщений и сам процесс сборки

S>Например процесс сборки я перевел в cmake и даже скрипт нарисовал.
S>Также например кодировку я починил, но то что успело засинхронизироваться — уже было невозможно исправить.
Тесты тебя не учили писать?
Или "ну их нахрен"?
Re[18]: namespace'ы в классах
От: Sheridan Россия  
Дата: 15.02.12 05:20
Оценка:
Здравствуйте, blackhearted, Вы писали:

B>Тесты тебя не учили писать?

B>Или "ну их нахрен"?
А как ты думаешь я выяснил что не смогу поправить "??? ????? ?????" в уже полученных сообщениях?
Matrix has you...
Re[7]: namespace'ы в классах
От: Privalov  
Дата: 16.02.12 18:03
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Ой передергиваешь. Римские цифры от арабских отличаются только при письме. Считать надо ровно также уметь. И если математика попросить римскими цифрами писать — он недельку привыкать будет, а потом обратно в колею войдет.


Когда ты выучишь матчасть и узнаешь, в чем различие между непозиционными и позиционными системами счисления, тогда, возможно, тебе станет ясно, что ни фига я не передергиваю. А в качестве упражнения попробуй ответить на вопрос, который тебе по этому поводу задал netch80. Я и сам бы его задал, да был в отъезде пару дней, без всяких компьютеров, Интернета и прочей технологической ерунды.

S>А вот ежели шарпея например или там заводчиков земноводных вдруг за ц++ посадить — ВНЕЗАПНО окажется что ой. Не хватает в головах и надо доучиваться.


На это тебе тоже ответили, не буду повторяться.

P>>Следует ли это понимать так, что ты хочешь ввести для разработчиков условия, о которых как-то писал Pavel Dvorkin: Вот если бы было введено ограничение по количеству переменных в программе (вот тебе 100 на программу и крутись как хочешь


S>Я честно попытался представить себе ход твоих мыслей, которые привели тебя к этому умозаключению, но тщетно. Поведаешь как ты додумался до такого что я буду подобный бред разделять?


Потому что это сейчас кажется бредом, а в начале компьютеризации это была суровая реальность. Представь: машина с 64К памяти, 512 байт стека. Ее Basic поддерживал не 100, а, ЕМНИП, 206 переменных. В таких условиях люди писали весьма качественный софт. Проблема в том, что человек в этом случае должен был помнить целую кучу деталей, которые в условиях, например, PC, можно поручить машине.

И это ни фига не рассуждения теоретика. Мне довелось участвовать по крайней мере в одном промышленном проекте, который разрабатывался в таких условиях, был успешно выполнен, не содержал ни одной строки спагетти-кода. Я о нем несколько раз писал здесь, в КСВ.

S>Так ограничивать программиста не просто глупо, а граничит с шизофренией.


В современных условиях — да.
Re[2]: И снова про ц++
От: Dair Россия  
Дата: 16.02.12 21:51
Оценка:
XC>Ужасная система #include и препроцессора, отсутствие нормальной модульной системы
А чем ужасна система #include?
Что такое "модульная система"? Я компоную исходники по модулям так, как мне захочется. Компилирую их отдельно в библиотеки. Также делают и поставщики библиотек. Это не модульность?

XC>Отсутствие вложенных блочных комментариев

Их наличие уже лишь warning. Но, anyway, зачем они?

XC>Имя массива является адресом первого элемента массива (нелогично! со структурами же не так)

Собака виляет хвостом, когда радуется. Нелогично! У кошек же не так!
Иными словами — а почему должно быть так и в структурах?

XC>Отсутствие низкоуровневых возможностей: sizeof( ) от функции и блока кода

ЗАЧЕМ???

XC>goto на переменные метки (в gcc есть, но это нестандартно)

Goto, надеюсь, когда-нибудь вообще отменят.

XC>Невозможность передачи массивов в фигурных скобках "как есть" в функции Foo({1,2,3});

Вот с этим соглашусь.

XC>Отсутствие именованных блоков кода,

Это "функция" называется, не?

XC>соответственно невозможность сделать break и continue на именованный блок/из блока

Нипонел. break/continue делается на текущий цикл. Вы хотите чтобы break/continue выходил сразу из более чем одного цикла?

XC>Отсутствие методов-расширений, отсутствие возможности обращаться к методу класса как к статическому с явной (ручной) передачей this

"Методы-расширения" — это что?
Зачем надо обращаться к не-статическому?

XC>Отсутствие системы сообщений как в ObjectiveC, встроенной системы сигналов и слотов как в QT

То, что вы называете системой сообщений в ObjC — это про
[obj performSelector:@selector(mySelector)]
?

XC>Невозможность создания namespace внутри класса (вспомните хотя-бы "главные оконные классы" разных библиотек — CWnd, QWidget... сотни методов, там разделение не помешало бы)

Примите за правило не делать более N методов в классе. Получается больше — рефакторинг.

XC>Отсутсвие вложенных функций (даже в турбо паскале вроде были), а лямбды в C++11 на редкость кривые

С лямбдами не знаком вообще, а отсутствие вложенных функций — сомнительное неудобство. Какая разница? Объявил статической и ладно.

XC>Отсутствие замыканий, простого объявления функциональных типов (int=>int)

Что это и зачем это надо?

XC>Отсутствие кортежей, групповых операций над кортежами, невозможность вернуть из функции несколько значений напрямую

Что это и зачем это надо?

XC>Отсутствие опциональной возможности структуной типизации

Что это и зачем это надо?

XC>Оператор :: вместо точки (некрасиво)

Точка тоже есть. И ->

XC>Ужасно громоздкая система шаблонов (каждый раз писать template), и тенденция использования шаблонов не по назначению (метапрограммирование на них)

Да забудьте вы про Александреску, он ненормальный

XC>При этом отсутствие полноценной системы метапрограммирования (типа как в Nemerle, хотя я бы сделал еще лучше)

XC>Отсутствие полноценной рефлексии и атрибутов (как в C#)
XC>Отсутствие встроенной параллельности и каналов (как в Go)
XC>Отсутствие свойств (properties) как в C# (хотя и в C# можно еще кое-что улучшить)

Про это я вообще не в курсе, так что вообще ничего не скажу.
Re[3]: И снова про ц++
От: Ночной Смотрящий Россия  
Дата: 16.02.12 22:36
Оценка:
Здравствуйте, Dair, Вы писали:

XC>>Ужасная система #include и препроцессора, отсутствие нормальной модульной системы

D>А чем ужасна система #include?

Тормозами и отсутствие контроля соответствия хидера бинарнику.

D>Что такое "модульная система"? Я компоную исходники по модулям так, как мне захочется. Компилирую их отдельно в библиотеки. Также делают и поставщики библиотек. Это не модульность?


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

XC>>Отсутствие методов-расширений, отсутствие возможности обращаться к методу класса как к статическому с явной (ручной) передачей this

D>"Методы-расширения" — это что?

Я на этот вопрос в топике уже отвечал.

D>Зачем надо обращаться к не-статическому?


Чтобы получить более читаемый код.

XC>>Отсутсвие вложенных функций (даже в турбо паскале вроде были), а лямбды в C++11 на редкость кривые

D>С лямбдами не знаком вообще

Так познакомься, тем паче что в свеженьком С++ они есть — http://en.wikipedia.org/wiki/C%2B%2B11#Lambda_functions_and_expressions .

D>, а отсутствие вложенных функций — сомнительное неудобство. Какая разница?


В чистоте синтаксиса разница. Ряд задач вложенные функции позволяют описывать чище и красивее.

XC>>Отсутствие замыканий, простого объявления функциональных типов (int=>int)

D>Что это и зачем это надо?

Долго объяснять. Начни с лямбд.

XC>>Отсутствие кортежей, групповых операций над кортежами, невозможность вернуть из функции несколько значений напрямую

D>Что это и зачем это надо?

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

XC>>При этом отсутствие полноценной системы метапрограммирования (типа как в Nemerle, хотя я бы сделал еще лучше)

XC>>Отсутствие полноценной рефлексии и атрибутов (как в C#)
XC>>Отсутствие встроенной параллельности и каналов (как в Go)
XC>>Отсутствие свойств (properties) как в C# (хотя и в C# можно еще кое-что улучшить)

D>Про это я вообще не в курсе


Суров.
Re[4]: И снова про ц++
От: Dair Россия  
Дата: 16.02.12 22:45
Оценка:
XC>>>Ужасная система #include и препроцессора, отсутствие нормальной модульной системы
D>>А чем ужасна система #include?
НС>Тормозами и отсутствие контроля соответствия хидера бинарнику.
На это есть линковка, не?

D>>Что такое "модульная система"? Я компоную исходники по модулям так, как мне захочется. Компилирую их отдельно в библиотеки. Также делают и поставщики библиотек. Это не модульность?

НС>http://en.wikipedia.org/wiki/Modular_programming
Удобно. А .so (dll в win, dylib в OSX) и заголовочные файлы не то же самое?

XC>>>Отсутствие методов-расширений, отсутствие возможности обращаться к методу класса как к статическому с явной (ручной) передачей this

D>>"Методы-расширения" — это что?

НС>Я на этот вопрос в топике уже отвечал.


D>>Зачем надо обращаться к не-статическому?

НС>Чтобы получить более читаемый код.
А можно пример?
Поясню недоумение: метод класса — он и есть метод класса, т.е., некая операция, которую осуществляет этот класс.
Статические методы — это, кмк, такой костыль, которым иногда можно пользоваться для группировки методов по классам.

XC>>>Отсутсвие вложенных функций (даже в турбо паскале вроде были), а лямбды в C++11 на редкость кривые

D>>С лямбдами не знаком вообще
НС>Так познакомься, тем паче что в свеженьком С++ они есть — http://en.wikipedia.org/wiki/C%2B%2B11#Lambda_functions_and_expressions .
Это я читал, спасибо.
Практического применения не вижу ни одного пока что.

D>>, а отсутствие вложенных функций — сомнительное неудобство. Какая разница?

НС>В чистоте синтаксиса разница. Ряд задач вложенные функции позволяют описывать чище и красивее.
Beauty is in the eye of the beholder. Но — соглашусь, иногда может быть удобнее. Я не встречал.

XC>>>Отсутствие замыканий, простого объявления функциональных типов (int=>int)

D>>Что это и зачем это надо?
НС>Долго объяснять. Начни с лямбд.


XC>>>Отсутствие кортежей, групповых операций над кортежами, невозможность вернуть из функции несколько значений напрямую

D>>Что это и зачем это надо?
НС>Для алгоритмов, которые оперируют большим количеством кортежей разных типов, чтобы не описывать каждый такой тип отдельной структурой.
Меня смутило незнакомое мне слово "кортеж". Да, проблема есть, согласен.

XC>>>При этом отсутствие полноценной системы метапрограммирования (типа как в Nemerle, хотя я бы сделал еще лучше)

XC>>>Отсутствие полноценной рефлексии и атрибутов (как в C#)
XC>>>Отсутствие встроенной параллельности и каналов (как в Go)
XC>>>Отсутствие свойств (properties) как в C# (хотя и в C# можно еще кое-что улучшить)

D>>Про это я вообще не в курсе


НС>Суров.

Увы, за свою скромную карьеру я познакомился не со всеми языками. На C# написал пару простейших вещей, Nemerle и go не видел вообще. Основным языком уже много лет остается C++. И ещё ObjectiveC. И немного perl/python/bash/Java.
Re[5]: И снова про ц++
От: Ночной Смотрящий Россия  
Дата: 16.02.12 23:01
Оценка:
Здравствуйте, Dair, Вы писали:

НС>>Тормозами и отсутствие контроля соответствия хидера бинарнику.

D>На это есть линковка, не?

Линковка тоже явно версии не отслеживает, просто пишет что функция не найдена.

НС>>http://en.wikipedia.org/wiki/Modular_programming

D>Удобно. А .so (dll в win, dylib в OSX) и заголовочные файлы не то же самое?

Если это обернуть нормальными метаданными и получить что то вроде СОМ или CORBA, то это оно. Но какой ценой ...

НС>>Чтобы получить более читаемый код.

D>А можно пример?

Пример я тоже уже приводил.

D>Практического применения не вижу ни одного пока что.


Тут я вряд ли чем смогу помочь. ФП — тема объемная, не для форума.
Re[7]: namespace'ы в классах
От: _d_m_  
Дата: 17.02.12 02:02
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>А вот ежели шарпея например или там заводчиков земноводных вдруг за ц++ посадить — ВНЕЗАПНО окажется что ой. Не хватает в головах и надо доучиваться.


Май йанг френд...
Я после це-пэ-пэ стал уже шарпеем. И обратно не хочу очень сильно.
Re[4]: И снова про ц++
От: jyuyjiyuijyu  
Дата: 19.02.12 22:21
Оценка:
Ф>>строки должны быть единственными
Ф>>а тут только в std уже 2 варианта

O>Спорно.

O>Допустим, для какой-то задачи мне нужны очень компактные, пусть и не быстрые, строки.
O>Стандартная std::string не подходит, так как на 32-битных системах весит "аж" 24 байта.
O>Зато есть CString (MFC), QString (Qt) и всякие велосипеды, при желании можно найти или
O>собрать реализацию с объектами размером в указатель.
O>Прелесть в том, что C++ позволяет выбирать.

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



да что тут спорить это как в спорте и в жизни есть пилоты
и есть любители у пилота в каре движок наполовину в машине
и ему в кайф управлять каждым винтиком в этой машине за
каждое движение например не вовремя отжатое сцепление он
отвечает головой он чувствует машину сердце стучит в такт
с мотором рука сростается с рычагом переключения скоростей
пилот и машина становится единым целым

а есть просто любители которым надо
доехать на машине до работы одни других никогда
не поймут

отсюда и не любовь к си и си++ (только непоятно
зачем тогда вообще программировать если это не в кайф?)
Re[9]: namespace'ы в классах
От: NikeByNike Россия  
Дата: 20.02.12 00:18
Оценка:
Здравствуйте, netch80, Вы писали:

N>Интересно, как можно "вспомнить" то, что никогда не знал? Значительная часть "шарпеев", явистов и т.д. уже никогда не писала под языки, где указатели, ручное распределение памяти и явный вызов free().

Тут вроде речь про С++, а не ущербный С.

T>> А вот когда ц++ садится за чтото посильнее, начинается ОЙ — не хватает знаний по ООП, Дизайну.


N>Или в специфических шарповских фичах вроде делегатов или Linq.

Я в С++ активно использую делегаты.

>А при чём тут дизайн или ООП в общем?

Он думает, что это шарпоспецифичная вещь.
Нужно разобрать угил.
Re[5]: И снова про ц++
От: _d_m_  
Дата: 20.02.12 02:26
Оценка:
Здравствуйте, jyuyjiyuijyu, Вы писали:

J>да что тут спорить это как в спорте и в жизни есть пилоты


Только пилотов единицы, зато много малолетних задротов мнящих себя пилотами и "стритрэйсерами". И в жизни, к сожалению, из-за этих пи...обля..ков страдают другие люди когда случаются ДТП по вине "пилотов".
Да и реальные пилоты порой влетают так, что по кускам их собирают.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.