Russian Qt Forum
Март 28, 2024, 21:59 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: 1 ... 3 4 [5] 6   Вниз
  Печать  
Автор Тема: Современные одномерные и двумерные массивы на C++  (Прочитано 46083 раз)
ViTech
Гипер активный житель
*****
Offline Offline

Сообщений: 858



Просмотр профиля
« Ответ #60 : Октябрь 31, 2014, 10:54 »

Всего лишь declspec (вместо attribute) и инициализацию вектора вручную - и все работает.
Как говорится: "мелочь, а приятно" Улыбающийся. Руками данные пушбэкать совсем не интересно, а если загонять данные из статического массива, то смысла в этом векторе совсем уж не остаётся, в рассматриваемом контексте. То хоть были только тормоза, теперь ещё и неудобство инициализации добавилось Улыбающийся.
Записан

Пока сам не сделаешь...
8Observer8
Гость
« Ответ #61 : Октябрь 31, 2014, 11:27 »

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

Надо спорить конструктивно. Если понял, что был не прав лучше обрадоваться, что наконец-то понял. Так и поступаю

C++, с точки зрения разработчика приложений, развивается по такому пути:

1) Писать как можно быстрее. Чем быстрее фирма отдаст проект заказчику (на рынок), тем больше она денег заработает

2) Обезопасить себя. Раньше программисту приходилось писать new и delete, потом придумали идиому RAII, теперь есть std::make_shared и std::make_unique. Теперь можно вообще не писать new и delete и освободить себя и от лишней головной боли, так как оператор delete опасен тем, что:

- можно забыть его написать
- можно написать его два раза
- можно попытаться использовать объект после delete

3) Для стандартных задач применять стандартные решения. Теперь можно комбинировать стандартные алгоритмы, контейнеры, лямбды, функторы, итераторы, регулярные выражения и т.д. решая 99% стандартных задач стандартным образом. Тем самым: уменьшаем время разработки, уменьшаем количество ошибок, программисты лучше понимают друг друга, когда видят перед собой стандартные решения

Нужно идти в ногу со временем

Чем быстрее заказчик получит своё приложение, тем быстрее фирма может перейти к выполнению следующего заказа, тем больше фирма заработает за определённое время (например, за год) Все становятся счастливее и довольнее

По поводу std::vector и статического (динамического) массива - ничего хоть сколько-нибудь убедительного не увидел. Не люблю пустословия. Давайте на конкретных примерах и конкретных задачах

Возьмём какую-нибудь простейшую задачу и на ней потестим. Допустим задача у приложения такая: получить от пользователя размер массива данных, отсортировать массив в обратном направлении, отдать результат (для упрощения - покажем на экран массив до сортировки и массив после сортировки)

Вот как я решил эту задачу с использованием стандартных средств C++11:

Код
C++ (Qt)
#include <iostream>
#include <vector>
#include <ctime>
#include <cstdlib>
#include <algorithm>
#include <iterator>
 
template <typename Type>
std::vector<Type> getArrya( std::size_t n );
 
template <typename Type>
void showArray( const std::vector<Type> &arr );
 
int main()
{
   // Get size
   std::cout << "Enter a size for the array: ";
   size_t n;
   std::cin >> n;
 
   // Get array
   std::vector<int> arr;
   arr = getArrya<int>( n );
 
   // Before
   std::cout << "Before: " << std::endl;
   showArray( arr );
 
   // Sort
   std::sort( arr.begin(), arr.end(), []( int i , int j ) { return i > j; } );
 
   // After
   std::cout << "After: " << std::endl;
   showArray( arr );
   std::cout << std::endl;
 
   return 0;
}
 
template <typename Type>
std::vector<Type> getArrya( std::size_t n )
{
   std::vector<int> arr( n );
   std::srand( std::time( NULL ) );
   std::transform( arr.begin(), arr.end(), arr.begin(),
                   []( Type i ) { return std::rand() % 100; } );
   return arr;
}
 
template <typename Type>
void showArray( const std::vector<Type> &arr )
{
   std::copy( arr.begin(), arr.end(),
              std::ostream_iterator<Type>( std::cout, " " ) );
   std::cout << std::endl;
}
 

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

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

Приведите несколько ситуаций, где возможно только применение статического (динамического) массива и ни в коем случае нельзя применять std::vector

Я уверен, что в 99% случаев можно обойтись в своих приложениях std::vector (ну или другим контейнером). А использовать статические (динамические) массивы только в самых крайних случаях. Я бы хотел, чтобы каждый перечислил все известные ему случаи. Буду очень рад! Спасибо!
« Последнее редактирование: Октябрь 31, 2014, 11:42 от 8Observer8 » Записан
ViTech
Гипер активный житель
*****
Offline Offline

Сообщений: 858



Просмотр профиля
« Ответ #62 : Октябрь 31, 2014, 12:03 »

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

По поводу std::vector и статического (динамического) массива - ничего хоть сколько-нибудь убедительного не увидел. Не люблю пустословия. Давайте на конкретных примерах и конкретных задачах.

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

Приведите несколько ситуаций, где возможно только применение статического (динамического) массива и ни в коем случае нельзя применять std::vector
В теме есть конкретный пример, где не стоит применять вектор. Разжевали, в рот положили, ещё и тестовый файл для сравнения скоростных характеристик выложили.
Записан

Пока сам не сделаешь...
vulko
Гость
« Ответ #63 : Октябрь 31, 2014, 12:05 »

Автор вообще неадекватен...
Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #64 : Октябрь 31, 2014, 13:25 »

По поводу std::vector и статического (динамического) массива - ничего хоть сколько-нибудь убедительного не увидел.
Я уже дважды привел пример где бездумное использование вектора неудачно. Привожу в 3-й раз.
Код
C++ (Qt)
   std::vector< std::vector<int> > arr( 5 );
 
Кстати "отсталый" программист на С никогда бы не написал такого говнокода. Хотя возможно он и не слыхал ни о каком векторе  Улыбающийся

Вы неоднократно употребляете термины "статический/динамический" массив. Возможно Вы имели ввиду объявление массива и массив выделяемый в куче с помощью new/malloc. Но это не соответствует терминам языка где static означает область видимости, а "динамический массив" просто отсутствует.

..потом придумали идиому RAII, теперь есть std::make_shared и std::make_unique.
Улыбающийся Не надо парИть так высоко. Разберитесь (по-настоящему, глубоко) почему Ваш 2-мерный массив очень плох, толку будет больше.
Записан
alex312
Хакер
*****
Offline Offline

Сообщений: 606



Просмотр профиля
« Ответ #65 : Октябрь 31, 2014, 13:52 »

Не надо парИть так высоко. Разберитесь (по-настоящему, глубоко) почему Ваш 2-мерный массив очень плох, толку будет больше.
Не надо умничать. Обьясните "на пальцах" почему его двумерный массив плох и говнокод. Мне совсем не очевидно.
Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #66 : Ноябрь 01, 2014, 08:49 »

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

- можно ли опираться на адрес элемента или придется хранить его индекс (больше забот)?
- чем грозит вставка/удаление?

В случае 2-мерного массива это прекрасно решается (в отличие от 1-мерного). И в Qt есть хорошее готовое решение. Поэтому странно что для Вас это неочевидно.
Записан
_Bers
Бывалый
*****
Offline Offline

Сообщений: 486


Просмотр профиля
« Ответ #67 : Ноябрь 01, 2014, 19:07 »

1. Стандартные средства являются кросс-платформенными, и не являются компиляторо-зависимыми.

2. Что касается межпроцессового взаимодействия: существует ограничение на использование rtti.
Поскольку, оно является unspecified behavior.

3. Не нужно путать "компиляторо-зависимость" и "зависимость от платформы".

Примером зависимости от платформы может служить, например "порядок следования байтов".
https://ru.wikipedia.org/wiki/%CF%EE%F0%FF%E4%EE%EA_%E1%E0%E9%F2%EE%E2

Очевидно, что одного лишь этого нюанса достаточно, что бы создать прецедент бинарной несовместимости.
« Последнее редактирование: Ноябрь 01, 2014, 19:18 от _Bers » Записан
vulko
Гость
« Ответ #68 : Ноябрь 02, 2014, 23:09 »

1. Стандартные средства являются кросс-платформенными, и не являются компиляторо-зависимыми.

2. Что касается межпроцессового взаимодействия: существует ограничение на использование rtti.
Поскольку, оно является unspecified behavior.

3. Не нужно путать "компиляторо-зависимость" и "зависимость от платформы".

Примером зависимости от платформы может служить, например "порядок следования байтов".
https://ru.wikipedia.org/wiki/%CF%EE%F0%FF%E4%EE%EA_%E1%E0%E9%F2%EE%E2

Очевидно, что одного лишь этого нюанса достаточно, что бы создать прецедент бинарной несовместимости.


1. Стандартные средства являются кросс-платформенными, и не являются компиляторо-зависимыми.

то что описано в с++11 можно отнести к стандартным средствам?
Записан
_Bers
Бывалый
*****
Offline Offline

Сообщений: 486


Просмотр профиля
« Ответ #69 : Ноябрь 02, 2014, 23:46 »

то что описано в с++11 можно отнести к стандартным средствам?

Вы хотите знать, является ли стандартным то, что описано в стандарте?


Записан
vulko
Гость
« Ответ #70 : Ноябрь 03, 2014, 00:16 »

то что описано в с++11 можно отнести к стандартным средствам?

Вы хотите знать, является ли стандартным то, что описано в стандарте?

Хорошо, давай так. Есть msvs compiler, им никто не пользуется и он никому не нужен?
Записан
_Bers
Бывалый
*****
Offline Offline

Сообщений: 486


Просмотр профиля
« Ответ #71 : Ноябрь 03, 2014, 14:23 »

Хорошо, давай так. Есть msvs compiler, им никто не пользуется и он никому не нужен?

Им пользуются. А значит - он нужен.

Однако, я не вижу связи между вашим первым и вторым вопросом.
Записан
vulko
Гость
« Ответ #72 : Ноябрь 05, 2014, 09:06 »

Хорошо, давай так. Есть msvs compiler, им никто не пользуется и он никому не нужен?

Им пользуются. А значит - он нужен.

Однако, я не вижу связи между вашим первым и вторым вопросом.

с++11 поддерживается только gcc.
тем не менее под виндой можно например запустить cygwin с gcc. а вот под линуксом врядли получится запустить msvs...

т.е. есть зависимость не только от платформы, но и от компилятора.
Записан
kambala
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 4724



Просмотр профиля WWW
« Ответ #73 : Ноябрь 05, 2014, 14:02 »

с++11 поддерживается только gcc.
где ты это услышал? мс компилятор тоже поддерживает (возможно не полностью), как и клэнг.
Записан

Изучением C++ вымощена дорога в Qt.

UTF-8 has been around since 1993 and Unicode 2.0 since 1996; if you have created any 8-bit character content since 1996 in anything other than UTF-8, then I hate you. © Matt Gallagher
_Bers
Бывалый
*****
Offline Offline

Сообщений: 486


Просмотр профиля
« Ответ #74 : Ноябрь 05, 2014, 20:17 »

с++11 поддерживается только gcc.
тем не менее под виндой можно например запустить cygwin с gcc. а вот под линуксом врядли получится запустить msvs...
т.е. есть зависимость не только от платформы, но и от компилятора.

Вы немножко ошибаетесь: помимо gcc в мейнстрим есть ещё такие топовые компиляторы, как:

Clang c++
http://clang.llvm.org/cxx_status.html

Visual C++ Compiler November 2013 CTP
http://www.microsoft.com/en-us/download/details.aspx?id=41151

Нельзя обойти вниманием порт gcc под виндовс в составе wingw.

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

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

Так например,
Visual C++ Compiler November 2013 CTP - бесплатен и ставиться отдельно с офф. сайта.
Он расширяет возможности базового компилятора CL, предоставляя улучшенную поддержку с++1y.

Но вы правы насчет зависимости от компиляторов: далеко не все они поддерживают стандарт языка на должном уровне.
Так например, базовая сборка CL для 2012 студии не умеет variardic template.

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

Однако, если вернуться к нашим баранам: одно дело отсутствие поддержки некоторых частей стандарта.
И другое дело - поведение не по стандарту.

Даже если взять компилятор вижал студии CL  - он до сих пор не соответствует стандарту на все 100%.
Но даже на нем, код написанный согласно букве стандарта взлетает без проблем.

Все реализованное в стандартной библиотеке на 100% соответствует букве стандарта.
Записан
Страниц: 1 ... 3 4 [5] 6   Вверх
  Печать  
 
Перейти в:  


Страница сгенерирована за 0.121 секунд. Запросов: 23.