++равствуйте, CreatorCray, Вы писали:

I>>Не валяй дурака, нужен ли эти рефакторинги для с++ или нет, не зависят от того, умеет ли это решарпер и любому, знакомому с логикой это понятно.
CC>Зависят.

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

CC>На что тебе был приведён тул — ассист.

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

CC>Ты начал ныть что мол, он слишком мало умеет.

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

CC>На что тебе было сказано что для рефакторинга в С++ он умеет достаточно.

Был даден список рефакторингов, ты так и не ответил на вопрос, почему эти рефакторинги нахрен не нужны в с++

Ты так и не не отвтил на этот вопрос, а начал валять дурака

>хочу услышать внятный ответ
Только после того, как ответишь что из этого умеет решарпер:

— ответа, заметь, не было

I>>в готовом виде он конечно все это он не умеет
CC>Тогда какое отношение эта книга имеет к разговору о тулах для рефакторинга?

чуть ниже было пояснение или для тебя абзац текта слишком сложно осилить ?

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

Еще раз — почему рефакторинги, приведеные в книге, не нужны в С++ ?

В чем особенность этого С++, что в нём не надо упрощать логику ? Что за мега-методики ?

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

I>>Соответсвенно, хочу услышать внятный вопрос — нужны ли рефакторинги _тобою_ перечисленные в С++.
CC>Это не мною перечисленные. Это "рфакторинги, перечисленые в книге в главах 6-9" из твоего поста.

Еще раз — почему рефакторинги, приведеные в книге, не нужны в С++ ?

I>>Т.е. да или нет, без виляний в твоем духе.
CC>Прекращай нести чушь.

Еще раз — почему рефакторинги, приведеные в книге, не нужны в С++ ?

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

допустим, если взять вместо С++ Эйфель, то худо-бедно можно cогласиться, что Эйфель вынуждает соблюдать принцип замещения Лисков.

Какие средсва в языке С++, что отменяют необходимость инструмента для воплощения этого и других принципов ?

P.S. слушай, тебе AV не помогает постить ? А то ощущение у вас одна и та же болезнь. Ты хоть пересядь куда.

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

S>Да я бы не стал никогда писать на чистом си или сипипи. Если мне не надо конструктора в объекте я объявлю струтуру, нужен конструктор объявлю класс. Нет смысла все функции прятать в методы. Нет смысла обявлять все переменные в начале блока, как в си, а есть смысл объявлять по мере необходимости. В общем чистота программы в плане написания на си или на сипипи ненужна.
компилятор или coding guidelines вполне может иметь своё мнение по этому вопросу. позови посмотреть когда будешь доказывать им свою точку зрения.

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


S>Нет смысла обявлять все переменные в начале блока, как в си, а есть смысл объявлять по мере необходимости.

Ты точно ничего не путаешь? Кто сказал, что в си нужно объявлять переменные только в начале блока?

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

I>>>Не валяй дурака, нужен ли эти рефакторинги для с++ или нет, не зависят от того, умеет ли это решарпер и любому, знакомому с логикой это понятно.
CC>>Зависят.
I>Перечитай выделеное чуть выше. Не понял идею, каким образом необходимость конкретного рефакторинга для С++ зависит от решарпера ? Начни так "в нативном с++ рефакторинг ... не нужен, потому что решарпер в .Net ..."
Не дури голову. Прочитай ветку с начала обсуждения ассиста как средства рефакторинга для С++.

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

I>- ответа, заметь, не было
Твоего в общем то тоже. Или ответом было "ничего не умеет"?

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

I>Еще раз — почему рефакторинги, приведеные в книге, не нужны в С++ ?
Так. Ясно. Чукча у нас даже не читатель.
Пруфлинк на мои слова где я утверждаю что "рефакторинги, приведеные в книге, не нужны в С++".
Озаботься напоминанием себе о чём все таки идёт речь в этой ветке.

I>>>Соответсвенно, хочу услышать внятный вопрос — нужны ли рефакторинги _тобою_ перечисленные в С++.
CC>>Это не мною перечисленные. Это "рфакторинги, перечисленые в книге в главах 6-9" из твоего поста.
I>Еще раз — почему рефакторинги, приведеные в книге, не нужны в С++ ?
А с чего ты взял вдруг что они не нужны? Я ничего подобного не утверждал.
Не нужно свои фантазии приписывать другим.
Или это такой новый метод троллинга?

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

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

В С# и Java кроме классов ничего долгое время и не было

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

I>>Перечитай выделеное чуть выше. Не понял идею, каким образом необходимость конкретного рефакторинга для С++ зависит от решарпера ? Начни так "в нативном с++ рефакторинг ... не нужен, потому что решарпер в .Net ..."
CC>Не дури голову. Прочитай ветку с начала обсуждения ассиста как средства рефакторинга для С++.

I>Не валяй дурака, нужен ли эти рефакторинги для с++ или нет, не зависят от того, умеет ли это решарпер и любому, знакомому с логикой это понятно.
Зависят.

Твоей ответ чисто в КУ

I>>Был даден список рефакторингов, ты так и не ответил на вопрос, почему эти рефакторинги нахрен не нужны в с++
CC>Потому что вопрос тролльский и к теме отношения не имеет.

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

I>Нужны высокоуровневые средтва, рефакторинг тот же.
Зачем?
Объясни?
Какие средства надо? Что у тя входит в рефакторинг?
Ты не меряй то, что надо для шарпа на плюсы.

Это не троллинг — это принуждение к ответу.

Или вот

I>хочу услышать внятный ответ
Только после того, как ответишь что из этого умеет решарпер:

И снова ответа нет

I>>- ответа, заметь, не было
CC>Твоего в общем то тоже. Или ответом было "ничего не умеет"?

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

и вот эти рефакторинги решарпер уже умеет, а ассист — нет.

выделеное и три строчки понятны или нет ?

Стало быть вопрос — нужны ли рефакторинги из книги при разработке на С++ или нет.

В который раз задаю вопрос !

I>>Еще раз — почему рефакторинги, приведеные в книге, не нужны в С++ ?
CC>Так. Ясно. Чукча у нас даже не читатель.
CC>Пруфлинк на мои слова где я утверждаю что "рефакторинги, приведеные в книге, не нужны в С++".

I>Нужны высокоуровневые средтва, рефакторинг тот же.
Зачем?
Объясни?
Какие средства надо? Что у тя входит в рефакторинг?
Ты не меряй то, что надо для шарпа на плюсы.

как трактовать твой недо-ответ я и не знаю.

I>>Еще раз — почему рефакторинги, приведеные в книге, не нужны в С++ ?
CC>А с чего ты взял вдруг что они не нужны? Я ничего подобного не утверждал.

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

Нужны или не нужны рефакторинги из книги ты не сказал.

Вот что было

I>Нужны высокоуровневые средтва, рефакторинг тот же.
Зачем?
Объясни?
Какие средства надо? Что у тя входит в рефакторинг?
Ты не меряй то, что надо для шарпа на плюсы.

Хочу услышать ответ примерно такой по форме:

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

или

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

Здравствуйте, dr.Chaos, Вы писали:

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

DC>В С# и Java кроме классов ничего долгое время и не было

Это значит, что для них и инструментов надо меньше. Например для С# и Джавы не нужны инструменты рефакторинга множественного наследования или рефакторнга макросов.

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

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

I>Это значит, что для них и инструментов надо меньше. Например для С# и Джавы не нужны инструменты рефакторинга множественного наследования или рефакторнга макросов.

I>А получается наоборот — классы есть и в С++ а инструмента для их рефакторинга нет, даже самого простого.

В lisp-е тоже есть классы, а средств для рефакторинга нету . Просто вселенский заговор какой-то.

Здравствуйте, dr.Chaos, Вы писали:

I>>Это значит, что для них и инструментов надо меньше. Например для С# и Джавы не нужны инструменты рефакторинга множественного наследования или рефакторнга макросов.

I>>А получается наоборот — классы есть и в С++ а инструмента для их рефакторинга нет, даже самого простого.

DC>В lisp-е тоже есть классы, а средств для рефакторинга нету . Просто вселенский заговор какой-то.

И насколько сильно Лисп распространен ? Вышел уже за пределы стат погрешности или 50 лет надо ждать ?

Ты в курсе, что сделали в Яхе, когда оттуда ушел Грехем со своей бандой лисперов ?

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

I>И насколько сильно Лисп распространен ? Вышел уже за пределы стат погрешности или 50 лет надо ждать ?

I>Ты в курсе, что сделали в Яхе, когда оттуда ушел Грехем со своей бандой лисперов ?

А какое это имеет отношение к рефакторингам Кириевски? Кириевски написал — все должны делать. ёпт!

Вот и выросло поколение...

Здравствуйте, dr.Chaos, Вы писали:

I>>И насколько сильно Лисп распространен ? Вышел уже за пределы стат погрешности или 50 лет надо ждать ?

I>>Ты в курсе, что сделали в Яхе, когда оттуда ушел Грехем со своей бандой лисперов ?

DC>А какое это имеет отношение к рефакторингам Кириевски? Кириевски написал — все должны делать. ёпт!

На вопросы для начала ответь.

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

нет никаких рефакторингов Кериевски, в его книги приведены самые общие рефакторинги, которые нужны везде где есть классы например.

В лиспе тоже есть классы, представь себе.

Здравствуйте, Ikemefula, Вы писали:
I>И насколько сильно Лисп распространен ? Вышел уже за пределы стат погрешности или 50 лет надо ждать ?
Лисп прекрасно живет и развивается в своем комьюнити. И будет так же жить и развиваться в ближайшие 50 лет. А вот судьба нынешнего мейнстрима предрешена: c#,java ждет судьба кобола, питон — в самом лучшем случае судьба tcl.

I>Ты в курсе, что сделали в Яхе, когда оттуда ушел Грехем со своей бандой лисперов ?
Набрали команду инди-кодеров, продолбали все полиме^W акции и превратились в моральных пигмеев?

Здравствуйте, Mr.Cat, Вы писали:

I>>И насколько сильно Лисп распространен ? Вышел уже за пределы стат погрешности или 50 лет надо ждать ?
MC>Лисп прекрасно живет и развивается в своем комьюнити. И будет так же жить и развиваться в ближайшие 50 лет. А вот судьба нынешнего мейнстрима предрешена: c#,java ждет судьба кобола, питон — в самом лучшем случае судьба tcl.

Пусть развивается. Он за пределами стат-погршности, всего то.

Нужен интрумент для решения текущих задач бизнеса, а Лисп — нет, не нужен.

I>>Ты в курсе, что сделали в Яхе, когда оттуда ушел Грехем со своей бандой лисперов ?
MC>Набрали команду инди-кодеров, продолбали все полиме^W акции и превратились в моральных пигмеев?

Нет, они нашли инструмент, который решил их задачи.

V>>Вызов по COM — это реальный вызов метода, in-proc или out-proc. В результате имеет счетчик ссылок и прочее.
C>А каким образом происходит вызов out-of-proc методов?
C>Hint: там ещё посылается оконное сообщение.

Вызов out-proc это вызов RPC. C 96-го года (Windows NT), в качестве транспорта, оконные сообщения не используются. В Windows 2k, XP и 2k3 передача основной массы данных осуществляется взаимодействием через LPC-порты. К сожалению, они синхронные, поэтому, что бы поддержать общий интерфейс асинхронных вызовов используются отсылка сообщений. Т.е. сообщения используются в качестве уведомлений.

Теперь посмотрим на Windows Vista и старше. Тут дела еще лучше — ALPC порты. В нашем контексте их основное новшество — возможность привязки IOCP (I/O Completion Ports), полностью асинхронный интерфейс и передача контекстов, в рамках одного transceiv'а. Это позволило полностью отказаться от оконных сообщений (я их там не видел, поправьте, если кто-то раскопал).

Здравствуйте, dr.Chaos, Вы писали:

DC>Здравствуйте, Aleх, Вы писали:

A>>Например преобразование типа строки с буфером 20 символов к строке с буфером 50 символов.
A>>Естественно данный подход не будет давать оптимальных оптимизаций, но всё же это лучше чем вообще ничего. К тому же С++ не дает ничего лучше.
A>>>>Тогда причем здесь это, я же описал совершенно другой случай.
DC>Ничем он особо не лучше: от параметров шаблонов пухнет страшно код, да и засунуть 2 такие строки в один массив целая проблема. Т.е. Здесть возможно даже аллокатор стоит делать не параметром шаблона, а параметром конструктора.
Можно и так, только если без параметра шаблона, в теории будет медленнее.

A>>>>>>Во вторых, контейнер map тоже должен быть настраиваемым. Например, в качестве дополнительного параметра шаблона должно быть возможно выбирать способ внутреннего представления отображения (double_hashing, chain_hashing, red_black_tree, avl_tree, ordered_vector), которое никак не влияет на интерфейс map.

A>>Ну и что здесь плохого? Александреску, например, пропагандирует такой подход.

DC>Скажем по другому: чем это лучше 5ти классов map, map_double_hashing и т.д. с одним интерфейсом? Допустим параметразовать можно было бы хеш функцией, но все эти 5 реализаций карты очень различаются и найти что-то общее в рамках одной реализации тут ИМХО будет сложнее, да и смысл?
Различаться будут только реализацией. Ну а смысл в том, чтобы сократить объем кода библиотеки: предполагается, что эти же внутренние представления можно задействовать для других контейнеров — например, set.

Здравствуйте, Eugeny__, Вы писали:
E__>Ты точно ничего не путаешь? Кто сказал, что в си нужно объявлять переменные только в начале блока?
Эээ... как бы да, если быть точнее после того как хотя бы одна переменная была использована, объявлять переменные нельзя (это касается Си).

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

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

S>>Да я бы не стал никогда писать на чистом си ...
A>компилятор или coding guidelines вполне может иметь своё мнение по этому вопросу. позови посмотреть когда будешь доказывать им свою точку зрения.

Компилятор со мной уже согласен, coding guidelines — это не ко мне

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

S>>>Да я бы не стал никогда писать на чистом си ...
A>>компилятор или coding guidelines вполне может иметь своё мнение по этому вопросу. позови посмотреть когда будешь доказывать им свою точку зрения.
S>Компилятор со мной уже согласен,
компилятор С++. компилятор С не согласится с, хотя бы, class. По крайней мере, я таких не знаю (#define class struct не считается). то есть пишешь ты на С++, и упоминать С всуе совсем незачем было. просто бы сказал, что в споре C vs С++ ты за C++.

S>coding guidelines — это не ко мне
вот и индусы так говорят, и, что хуже, делают

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

S>Нет смысла обявлять все переменные в начале блока, как в си, а есть смысл объявлять по мере необходимости.

#pragma flame on
переменные вообще не нужны