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

А>Ну это ты загнул.

Ну не знаю, может и ошибся...

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

Vi2>Дело, наверное, не в том, сколько лет. Всё-таки есть разница между годами использования предмета, допустим, С/С++, человеком с опытом программирования и без оного.

Мне тоже не совсем понятно как считаются года.
Например первый раз я на C программировал(не тривиальную
и в добавок коммерческую программу) в 11 классе(95 год)
Но записывать себе 7 лет экспы я как-то стесняюсь,
т.к. одно дело когда ты пишешь и думаешь о C++
минимум 50 часов в неделю, а другое когда 20 часов
в месяц.

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

В принципе наверное правы люди на Source Forge которые
оценивают skill-ы по такой шкале

None
Want to learn
Competent
Wizard
Wrote a book
Wrote it

Разница более очевидна чем между 6 и 12 месяцами exp.
Сразу становится все понятно

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

Vi2>>Дело, наверное, не в том, сколько лет. Всё-таки есть разница между годами использования предмета, допустим, С/С++, человеком с опытом программирования и без оного.

A>Мне тоже не совсем понятно как считаются года.

Года считают очень просто. Например, размещает человек своё резюме на Монстре, допустим 10 лет назад он писал на C три года, затем пересел на C++, 5 лет назад начал писать на VC++, год назад на С#. Итого:

C    - 3
C++  - 7
VC++ - 5
C#   - 1

Сумарный опыт C/C++ — 10 лет. На монстре это всё записывается в одну строчку и получаем:

C/C++/VC++/C# - 10

Поисковик тамошний легко выдаёт человека с опытом C# — 10 лет И таких хитростей народ придумывает море, только бы резюме было выше в топе.

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

IT>Поисковик тамошний легко выдаёт человека с опытом C# — 10 лет И таких хитростей народ придумывает море, только бы резюме было выше в топе.

Т.е. я тебя похоже даже не обманул
когда себе 8 лет экспы в C/C++ написал

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

A>Выводы о unix ориентированности ты сделал не правильно.
A>Т.е. ты не проверил как раз unix и Delphi/BCB но посчитал что я unix-оид (возможно уровень подготовки просто не состыковался с твоим представлением 'дельфака позорного')

Ых. Жалко, промазал.

A>По поводу общего, то да видимо уровень определить задавая вопросы все-таки можно. Но на проядок больше можно о человеке узнать просто спросив его что он делал раньше и попросив описать свои проекты. Там будет сразу понятно что и где ты пользовал. Если у тебя написано Java — 1 год, а на вопрос где ты его использовал ты говоришь "самоподготовка", то все сразу становится понятно

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

A>P.S. Спасибо было интересно и поучительно.

Мне тоже. Спасибо и тебе. Только вот переводы строк твои я устал удалять

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

IT>Мне тоже. Спасибо и тебе. Только вот переводы строк твои я устал удалять

А зачем их удалять? Они мешаются чем-то? С ними вроде как даже лучше.

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

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

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

A>>>Assembler — хорошо — 2.5 года опыта в Reverse Engeneering(хобби, эпизодически)

IT>>Имеется 300k дезассемблированной кода. По каким отличительным признакам можно определить на каком языке высокого уровня написана программа.

A>Несколько прямых признаков(метка компилятора, сигнатуры библиотек)
A>И много косвенных(конвенция вызовов(хорошо видно кто сохраняет регистры и чистит стек), формат строк(asciiz или pascal) )

Можно добавить?
Часть информации неплохо видно в .exe'шнике невооруженным глазом. При просмотре в томже фар-манагере.

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

IT>>>Имеется 300k дезассемблированной кода. По каким отличительным признакам можно определить на каком языке высокого уровня написана программа.

G>Можно добавить?
G>Часть информации неплохо видно в .exe'шнике невооруженным глазом. При просмотре в томже фар-манагере.

Видишь здесь по условию код уже дизассемблированный

Здравствуйте Иван Цыгулёв, Вы писали:

ИЦ>Здравствуйте IT, Вы писали:

IT>>Здравствуйте Иван Цыгулёв, Вы писали:

ИЦ>>>Привет злобный HR Ткачёв

IT>>Здравствуйте, Ваня. Скажи спасибо, что я просто не знал о чём тебя в своё время спрашивать

ИЦ>Ага, сам не знал
ИЦ>Да и главное тогда было чтобы человек хороший был

ИЦ>>>вот тебе подсказка

ИЦ>>>Внимание вопрос!
ИЦ>>>Чем человек занимался 2 года с Visual C++?

IT>>Ты подожди, мы до всего дойдём. И про ATL с COM'ом ещё поспрашаем. Вообще, опыт с наименьшим количесвом лет всегда вызывает подозрение.

ИЦ>Да не про минимальный опыт разговор, а о том что можно делать без ATL и MFC 2 года с Visual C++ ?

А на них свет клином сошелся ?
Можно писать :
— парсеры
— semantic checker/name resolution
— import/export из/в другие языки
— кодогенераторы
— оптимищаторы генеренного кода
— библиотеки для кодогенераторов
— etc.
(вышеперечисленное не обязательно относится к разработке компиляторов,
он встречается во многих других областях, например в CASE системах для Real-Time систем. См фирмы I-Logix, Telelogic)

Интересная у вас дискуссия... )

IT>А как быть, если нужно рекурсивное использование классов, определённых в разных модулях? Т.е., например, в методе M1() класса A нужно работать с классамом B. А в классе B, в методе M2() нужно работать с классом A.

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

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

JD>Интересная у вас дискуссия... )

IT>>А как быть, если нужно рекурсивное использование классов, определённых в разных модулях? Т.е., например, в методе M1() класса A нужно работать с классамом B. А в классе B, в методе M2() нужно работать с классом A.

JD>А это кстати можно сделать — вернее можно обойти это ограничение:
JD>напиши еще пару классов — baseA и baseB — соответственно базовые для A и для B и вынеси туда все нужные тебе функции, сделай их виртуальными и переопредели а потомках..
JD>т.е. надо просто не использовать методы других классов, а использовать виртуальные методы абстрактных базовых классов — тогда проблемы цикличесикх ссылок будет разрешена. да и вообще это более качественный и правильный подход к программированию.

Нет не качественный. Плодить сущности это не есть хорошо. То что ты привел я знаю, и это просто хак. Не стоит делать вид что так и надо.

Просто подумай что эти функции должны возвращать эти самые классы классы, притом не какой-то предок, а сам класс. В таком случае виртуальность тебя не спасет. Например подумай как реализовать ListView/ListViewItem если они были бы в разных модулях.

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

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

JD>>Интересная у вас дискуссия... )

IT>>>А как быть, если нужно рекурсивное использование классов, определённых в разных модулях? Т.е., например, в методе M1() класса A нужно работать с классамом B. А в классе B, в методе M2() нужно работать с классом A.

JD>>А это кстати можно сделать — вернее можно обойти это ограничение:
JD>>напиши еще пару классов — baseA и baseB — соответственно базовые для A и для B и вынеси туда все нужные тебе функции, сделай их виртуальными и переопредели а потомках..
JD>>т.е. надо просто не использовать методы других классов, а использовать виртуальные методы абстрактных базовых классов — тогда проблемы цикличесикх ссылок будет разрешена. да и вообще это более качественный и правильный подход к программированию.

A>Нет не качественный. Плодить сущности это не есть хорошо. То что ты привел я знаю, и это просто хак. Не стоит делать вид что так и надо.

Я все-таки считаю что это хорошо! Очень часто в "умных" книжках слышал советы о том что реализация (код) должна быть только в конечных классах иерархии наслеования. Т.е. наследуйся конечно сколько тебе угодно и от кого угодно, НО вот новые интерфейсные методы (т.е. методы которые кто-то будет дергать снаружи) добавлять нельзя — добвлять им можно только в базовом абстрактном классе.
Я конечно не говорю что надо всегда так делать, но я считаю что это хороший тон программирования хотя и трудозатратный...
Посмотри на COM — там все построено на этом — есть чисто виртуальные классы (интерфейсы) и все дергают только за них — что тут плохого???

A>Просто подумай что эти функции должны возвращать эти самые классы классы, притом не какой-то предок, а сам класс. В таком случае виртуальность тебя не спасет. Например подумай как реализовать ListView/ListViewItem если они были бы в разных модулях.

Если ты хочешь именно ListViewItem и на базовый абстрактный класс не согласен(хоят и не понятно почему) то все равно очень просто:

1.pas:
class IListView

2.pas
uses 1.pas;
uses 3.pas;
class ListView : IListView
содержит методы и проперти возвращающие ListViewItem

3.pas
uses 1.pas
class ListViewItem
// при необходимости дергает все что ему нужно через IListView

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

JD>Я все-таки считаю что это хорошо! Очень часто в "умных" книжках слышал советы о том что реализация (код) должна быть только в конечных классах иерархии наслеования. Т.е. наследуйся конечно сколько тебе угодно и от кого угодно, НО вот новые интерфейсные методы (т.е. методы которые кто-то будет дергать снаружи) добавлять нельзя — добвлять им можно только в базовом абстрактном классе.

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

Вообщем здесь надо руководствоваться так называемым KISS principle (KISS = Keep It Simple, Stupid )

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

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

JD>>Я все-таки считаю что это хорошо! Очень часто в "умных" книжках слышал советы о том что реализация (код) должна быть только в конечных классах иерархии наслеования. Т.е. наследуйся конечно сколько тебе угодно и от кого угодно, НО вот новые интерфейсные методы (т.е. методы которые кто-то будет дергать снаружи) добавлять нельзя — добвлять им можно только в базовом абстрактном классе.

A>Ни в одной правильной книжке так не написано.
"Наиболее эффективное использование C++" by Скотт Майерс стр. 266
там как раз есть тема "Делайте нетерминальные классы абстрактными" — это то про что я и говорил.

A>Видимо у тебя недостает опыта, слегка, в проектировании систем если ты так считаешь(без обид).
Оk. Без обид. Возможно, что у тебя опыта больше...

A>На самом деле класс предок от которого наследуется только один класс это баг в дизайне, его нужно исправлять. Посмотри как написаны все нормальные библиотеки(та же VCL) и увидишь что там каждое наследование что-то в класс добавляет.
В этом (насчет бага в дизайне) я с тобой не согласен. Я считаю что могу писать так как захочу (а обычно я хочу так как мне кажется правильней). Однако, лишний уровень абстракции обычно только упрощает (в плане удобства пользования, красоты дизайна и т.п.) дальнейшую разработку... хотя и тормозит ее (в плане временных и умственных трудозатрат).

A>Вообщем здесь надо руководствоваться так называемым KISS principle (KISS = Keep It Simple, Stupid )
Я же не спорю с kiss. Просто иногда когда проект растет возникают сложности...
Но как у тебя у самого сказано в подписи:
"Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев"

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

A>>Ни в одной правильной книжке так не написано.
JD>"Наиболее эффективное использование C++" by Скотт Майерс стр. 266
JD>там как раз есть тема "Делайте нетерминальные классы абстрактными" — это то про что я и говорил.

Это как раз не про это. Там говорится что надо делать абстрактными классы которые не имеют собственного смысла для того чтобы кто-нибудь не мог их создать. Притом обрати внимание что сказано "делайте существующие классы абстрактными". И там ничего что для каждого класса надо делать абстрактную пару.

A>>На самом деле класс предок от которого наследуется только один класс это баг в дизайне, его нужно исправлять. Посмотри как написаны все нормальные библиотеки(та же VCL) и увидишь что там каждое наследование что-то в класс добавляет.
JD>В этом (насчет бага в дизайне) я с тобой не согласен. Я считаю что могу писать так как захочу (а обычно я хочу так как мне кажется правильней). Однако, лишний уровень абстракции обычно только упрощает (в плане удобства пользования, красоты дизайна и т.п.) дальнейшую разработку... хотя и тормозит ее (в плане временных и умственных трудозатрат).

Дизайн считается хорошим когда другие люди его понимают и принимают.

JD>"Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев"

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

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

A>>>Ни в одной правильной книжке так не написано.
JD>>"Наиболее эффективное использование C++" by Скотт Майерс стр. 266
JD>>там как раз есть тема "Делайте нетерминальные классы абстрактными" — это то про что я и говорил.

A>Это как раз не про это. Там говорится что надо делать абстрактными классы которые не имеют собственного смысла для того чтобы кто-нибудь не мог их создать. Притом обрати внимание что сказано "делайте существующие классы абстрактными". И там ничего что для каждого класса надо делать абстрактную пару.

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





JD>>"Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев"

A>

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

JD>Ладно, я согласен, что, конечно же, не надо делать для каждого класса его абстрактную пару — обычно это просто ни к чему (особенно если от этого класса никто не будет наследоваться).
JD>Но иногда это надо (например в приведенном тобой примере из Дельфы) и, когда это надо, это не есть плохо!
JD>Ты же к примеру не ругаешься, что тебе надо описывать интерфейс в IDL'ке, а потом реализовывать его в производном классе — это нормально — это технология такая. ну и тут это тоже технология — технология программирования в дельфи.

А я и не ругаюсь. Я абсолютно спокойно отношусь. У дельфи есть ограничение, ну и ладно.

IT>>

IT>>static CCriticalSection g_cs;

IT>>void MyCollection::AddItem(void *ptr)
IT>>{
IT>>    g_cs.Lock();
IT>>    AddInternal(ptr);
IT>>    g_cs.Unlock();
IT>>}
IT>>

A>Здесь не стоит выносить critical section за класс,
A>т.к. получается, что если я заблокировал один экземпляров,
A>то все остальные в этот момент стоят курят, хотя могли
A>бы работать. Надо сделать CriticalSection одной из
A>переменных класса(не статистической)

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

PS: извините, что вмешался.

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

LD>Хотя я бы внес все-таки внес эту переменную в класс как статическую. (это правильно с
LD>точки зрения архитектуры.)

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

LD>PS: извините, что вмешался.

Да ничего основная дискусия уже давно закончилась, сейчас только обсуждение идет.

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

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

A>>Pascal

A>>type MyClass=class;
A>>(это в Object Pascal от Delphi, в классическом используется ключевое слово object а не class)

IT>А как быть, если нужно рекурсивное использование классов, определённых в разных модулях? Т.е., например, в методе M1() класса A нужно работать с классамом B. А в классе B, в методе M2() нужно работать с классом A.

На самом деле все это можно реализовать

unit u1;
interface
type
  A = class
  public
    procedure M1(AObject:TObject); // ничего не зная о u2 
//  можем передавать его объекты через "универсальный" класс
  end;
implementation

uses u2; // мы можем использовать этот юнит только в 
// разделе реализации
procedure A.M1;
begin
  if AObject is B then
  //  что-то делаем
end;

unit u2;
interface

uses u1; // в разделе интерфейса можно использовать только один из двух

type
  B = class
  public
    procedure M2(AObject:A); // зная о u1 можем передавать экземпляры нужного класса
  end;
implementation
procedure B.M2;
begin
  // что-то делаем
end;

странно, что никто не заступился..