Сообщение Re[9]: Школа С++ от UNIGINE от 07.03.2017 19:21
Изменено 07.03.2017 20:42 AlexGin
Re[9]: Школа С++ от UNIGINE
Здравствуйте, alex_public, Вы писали:
_>А какая вообще связь между размером проекта и появлением в нём не кроссплатформенных кусков?
Обычно, чем больше объём кода, тем больше вероятности того, что потребуется что-то специфическое.
Кроме того, если предполагается MSVC проект (под целевую Windows), очень велика вероятность применения ActiveX (COM) etc.
_>Последнее обычно появляется исключительно вследствие необходимости использования функций ОС, для которых нет удобных кроссплатформенных библиотек-обёрток. В этом случае или пишется своя вариация под каждую платформу (если у нас в ТЗ заявлена поддержка многих платформ) или же вот появляется такой некроссплатформенный кусок. Но с размером проекта это никак не связано, а является исключительно следствием потребности в специфическом функционале.
В ТЗ не заявлено ничего по данному поводу
По-умолчанию подразумевается Windows, затраты на разработку под Linux — НЕ смогут окупиться
_>Что такое "адаптация gcc <-> MSVC"? Или вы пишете не под стандарт языка, а под конкретный компилятор? )
OK!
Вот мне нужно отобразить древовидную таблицу (иерархический грид):

Я применяю вот это (ComponentOne VsFlexGrid8):
http://helpcentral.componentone.com/nethelp/vsflexgrid8/componentonevsflexgridpro8.html
Вопрос — неужели ради строгого следования стандарту C++ (что конечному пользователю вообще-то фиолетово), мне следует отказаться от этого?
_>Если так, то это не верный подход. Ориентироваться следует исключительно на стандарт языка.
Когда у Вас, уважаемый alex_public, появится Заказчик, Вы будете ориентироваться исключительно на его требования.
_>P.S. И да, MSVC сейчас явно не является лучшим выбором. Ни по поддержке стандарта, ни по быстродействию получаемого.
А что же тогда, по-вашему, является лучшим выбором?
По объективным оценкам...
_>А какая вообще связь между размером проекта и появлением в нём не кроссплатформенных кусков?
Обычно, чем больше объём кода, тем больше вероятности того, что потребуется что-то специфическое.
Кроме того, если предполагается MSVC проект (под целевую Windows), очень велика вероятность применения ActiveX (COM) etc.
_>Последнее обычно появляется исключительно вследствие необходимости использования функций ОС, для которых нет удобных кроссплатформенных библиотек-обёрток. В этом случае или пишется своя вариация под каждую платформу (если у нас в ТЗ заявлена поддержка многих платформ) или же вот появляется такой некроссплатформенный кусок. Но с размером проекта это никак не связано, а является исключительно следствием потребности в специфическом функционале.
В ТЗ не заявлено ничего по данному поводу
По-умолчанию подразумевается Windows, затраты на разработку под Linux — НЕ смогут окупиться
_>Что такое "адаптация gcc <-> MSVC"? Или вы пишете не под стандарт языка, а под конкретный компилятор? )
OK!
Вот мне нужно отобразить древовидную таблицу (иерархический грид):

Я применяю вот это (ComponentOne VsFlexGrid8):
http://helpcentral.componentone.com/nethelp/vsflexgrid8/componentonevsflexgridpro8.html
Вопрос — неужели ради строгого следования стандарту C++ (что конечному пользователю вообще-то фиолетово), мне следует отказаться от этого?
_>Если так, то это не верный подход. Ориентироваться следует исключительно на стандарт языка.
Когда у Вас, уважаемый alex_public, появится Заказчик, Вы будете ориентироваться исключительно на его требования.
_>P.S. И да, MSVC сейчас явно не является лучшим выбором. Ни по поддержке стандарта, ни по быстродействию получаемого.
А что же тогда, по-вашему, является лучшим выбором?
По объективным оценкам...
Re[9]: Школа С++ от UNIGINE
Здравствуйте, alex_public, Вы писали:
_>А какая вообще связь между размером проекта и появлением в нём не кроссплатформенных кусков?
Обычно, чем больше объём , тем больше вероятности того, что потребуется что-то специфическое.
Кроме того, если предполагается MSVC проект (под целевую Windows), очень велика вероятность применения ActiveX (COM) etc.
_>Последнее обычно появляется исключительно вследствие необходимости использования функций ОС, для которых нет удобных кроссплатформенных библиотек-обёрток. В этом случае или пишется своя вариация под каждую платформу (если у нас в ТЗ заявлена поддержка многих платформ) или же вот появляется такой некроссплатформенный кусок. Но с размером проекта это никак не связано, а является исключительно следствием потребности в специфическом функционале.
В ТЗ не заявлено ничего по данному поводу
По-умолчанию подразумевается Windows, затраты на разработку под Linux — НЕ смогут окупиться
_>Что такое "адаптация gcc <-> MSVC"? Или вы пишете не под стандарт языка, а под конкретный компилятор? )
OK!
Вот мне нужно отобразить древовидную таблицу (иерархический грид):

Я применяю вот это (ComponentOne VsFlexGrid8):
http://helpcentral.componentone.com/nethelp/vsflexgrid8/componentonevsflexgridpro8.html
Вопрос — неужели ради строгого следования стандарту C++ (что конечному пользователю вообще-то фиолетово), мне следует отказаться от этого?
Теперь насчет именно адаптации по gcc: прежде всего, меня раздражает, что в нём, при ошибке компиляции выдается скупой и зачастую малоинформативный короткий текст. Найти истинную причину (дажеднём с огнёмпри помощи гугла) очень трудно 
На MSVC выдаётся код ошибки, (например C2259) и далее в MSDN — полное и точное описание всех возможных причин данной ситуаций, а также и рекомендации насчёт того, как её пофиксить.
_>Если так, то это не верный подход. Ориентироваться следует исключительно на стандарт языка.
Когда у Вас, уважаемый alex_public, появится Заказчик, Вы будете ориентироваться исключительно на его требования.
_>P.S. И да, MSVC сейчас явно не является лучшим выбором. Ни по поддержке стандарта, ни по быстродействию получаемого.
А что же тогда, по-вашему, является лучшим выбором?
По объективным оценкам...
_>А какая вообще связь между размером проекта и появлением в нём не кроссплатформенных кусков?
Обычно, чем больше объём , тем больше вероятности того, что потребуется что-то специфическое.
Кроме того, если предполагается MSVC проект (под целевую Windows), очень велика вероятность применения ActiveX (COM) etc.
_>Последнее обычно появляется исключительно вследствие необходимости использования функций ОС, для которых нет удобных кроссплатформенных библиотек-обёрток. В этом случае или пишется своя вариация под каждую платформу (если у нас в ТЗ заявлена поддержка многих платформ) или же вот появляется такой некроссплатформенный кусок. Но с размером проекта это никак не связано, а является исключительно следствием потребности в специфическом функционале.
В ТЗ не заявлено ничего по данному поводу
По-умолчанию подразумевается Windows, затраты на разработку под Linux — НЕ смогут окупиться
_>Что такое "адаптация gcc <-> MSVC"? Или вы пишете не под стандарт языка, а под конкретный компилятор? )
OK!
Вот мне нужно отобразить древовидную таблицу (иерархический грид):

Я применяю вот это (ComponentOne VsFlexGrid8):
http://helpcentral.componentone.com/nethelp/vsflexgrid8/componentonevsflexgridpro8.html
Вопрос — неужели ради строгого следования стандарту C++ (что конечному пользователю вообще-то фиолетово), мне следует отказаться от этого?
Теперь насчет именно адаптации по gcc: прежде всего, меня раздражает, что в нём, при ошибке компиляции выдается скупой и зачастую малоинформативный короткий текст. Найти истинную причину (даже
На MSVC выдаётся код ошибки, (например C2259) и далее в MSDN — полное и точное описание всех возможных причин данной ситуаций, а также и рекомендации насчёт того, как её пофиксить.
_>Если так, то это не верный подход. Ориентироваться следует исключительно на стандарт языка.
Когда у Вас, уважаемый alex_public, появится Заказчик, Вы будете ориентироваться исключительно на его требования.
_>P.S. И да, MSVC сейчас явно не является лучшим выбором. Ни по поддержке стандарта, ни по быстродействию получаемого.
А что же тогда, по-вашему, является лучшим выбором?
По объективным оценкам...