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

В запрос передавать

(1) Это как например?

(0) Ну и не используй, если тебе не надо.
В 7-ке массивы - несколько кастрированные, и использовать их можно разве что в узкоспециальных целях.

Использовать в условии? Это будет быстрее, чем


Пример запроса:

тз = СоздатьОбъект("ТаблицаЗначений");
тз.НоваяКолонка("Материал");
тз.НоваяКолонка("Количество");


ТекстЗапроса = "
| Материал = Справочник.Материалы;

.....
|Условие (тз.НайтиЗначение(1, 0, Материал) = 1);

";


?

(3) Так вот и интересно понять в каких))) До сих пор видел массив только в типовой зарплате, и тогда не стал рыться, зачем именно использовали массив, а не тз))) А сейчас 8 гоняю, как-раз про коллекции значений начал проходить, там массивы, я и подумал - зачем они вообще существуют в платформе)

(4)

быстрее, чем что ?

(5) В 8-ке, в отличие от 7-ки - полноценные динамические массивы. Их в большинстве случаев использовать гораздо удобнее, чем списки значений (если речь не идёт об общении с пользователем).

в 7-ке есть еще список значений, делать как в (4) это прикол такой?

(8) Зачем делать проще, если можно через ж? :-)

(6) Я попытался понять (1), он имеет в виду что массивы в условии запроса быстрее чем тз?
(7) Но в 8 ведь тоже есть тз?
Вызов тз как диалога, это плюс к тз, и тогда еще непонятней, зачем разрабы в 7 делали массивы...
(8) Это не прикол, если много значений в фильтре, и запрос большой - работает с тз быстрее, чем со списком.
(9) Не ожидал от вас)

(10) насчет быстрее списка значений как можно объяснить, в чем причина?

(11) неэффективный штатный поиск при больших размерах списка

(10) Да. В 8-ке есть таблицы значений, есть списки значений, есть массивы, есть структуры, есть соответствия... Много чего есть. У каждой структуры данных - своё назначение.
В 7-ке массивы делали, видимо, в спешке, "заимствуя" из других языков программирования. Поэтому результат получился весьма неудачным. Есть примеры, когда использование массивов необходимо (в частности, в запросах - на форуме это обсуждалось). Но таких примеров - весьма и весьма немного.
Сомнение в коде из (4) - вполне оправдано (в том примере кода, который приведен, IMHO, без дополнительных пояснений не видно причин использовать именно таблицу значений).

(11) вероятно тз быстрее обрабатывается в запросе хз почему ("спасибо кэп)", я знаю). Просто был случай - вот здесь ((12) - вы советовали, я помню) )Запрос и список, я тогда мучился со списком, надо было отфильтровать данные и отобразить в диалоге на форме, лепил консольку для пользователя. С тз в запросе обновление было практически незаметно, а вот со списком притупливало.
Но вообще, если бы кто обьяснил про массивы...
(13) ну так на то и пример...

(13) насчёт тормозов конструкции в запросе " в СЗ" - это, как бы, баян

(14) В 7-ке? Да просто не используй массивы, пока не припрёт. Неудачно они в 7-ке реализованы.

(10)
для скл версии  передача списка значнний ,для условия отбора,как массив   - быстрее.
Это связано с тем, что 1с77 для каждлго элемента создает хранимую процедуру исполняет её и затем удаляет.
но есть ограничение на колво элементов проверки условия (точнее на размер текста запроса ), тк передача происходит тупо составление  текста запроса вида УСЛОВИЕ( поле = Массив[i] ИЛИ поле = Массив[i+1]+ ... .



Ваш пример - с точки зрения быстродействия - ужасен, тк для реализации подобного условия 1с77
сначала скачает выборку на клиент, а затем применит к ней условие

(17) для скл - возможно, не тестировал. способ был протестирован на файловой версии в терминальнике, ускорение по сравнению с СЗ - в разы

СЗ - для интерактивной работы, а не в запрос его пихать :)

(17) База была как раз SQL. И причем на клиенте было подключение ЛОКАЛЬНОЕ т.е. даже не через терминалы. Я знал, что тормоза будут в любом случае, но тогда тз в запросе меня выручила, я уж не знаю что внутри платформы происходит, когда идет выборка, но тогда тз реально была быстрее чем список.

(18) SQL и файлы - две больших разницы, в том числе и по быстродействию.
(15), (18) И ещё один момент. Если список значений - _большой_, то во многих случаях имеет смысл призадуматься: а что в нём лежит.

(21) 2. глянь в штатную обормотку формирования прайса в ТиС 7.7, и поймешь :)

(19) видимо, разработчикам типовых об этом сказать забыли

я массивы однажды использовал, когда какой-то хитрый отчёт писал в ПУБе. Больше ни разу.

(23) тогда проблем не было с СЗ.

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

(0) Массивы в 7-ке сделали - чтобы были. А в реальности их использование очень сильно от программистской школы зависит, как то видел зарплату написанную явно бывшими паскальщиками - в коде одни массивы, причем названия у них такие уютные :-) А, АА, Б, АБ и т.д. Пока разбирал код - чуть не повесился :-)
К тому же я, например, за десять лет в семерке ни разу меток не использовал, но не берусь утверждать, что они не нужны :-) , хотя есть здесь и такие граждане

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

(28) Теоретически - потому, что при использовании меток и переходов становится сложным сформулировать (и тем более понять) логику кода, что затрудняет написание и отладку программы (подробнее см. Э.Дейкстра, "Дисциплина программирования")
Метки в 1Сике нужны лишь постольку, поскольку нет выходов из глубоко вложенных структур.

+(29) (Но если хочешь поговорить о метках - лучше создай отдельную тему. Удобнее по техническим причинам).

(30) думаю, нет смысла - уже всё сто раз перетёрто
Теорема Бома — Якопини реалистична? или снова про goto

(31) Отдельную тему - закрыть проще, без ущерба для прочего :-)

(31) обьемно, спасибо, почитаю)

(33) Недостаток преобразования по Бома-Якопини - необходимо бывает введение дополнительных переменных.
Кроме того, есть continuations - по сути те же goto, но математически корректные. Но в 1Сик их не втащишь... :-(

(28) меток надо избегать любым способом чтобы не быть обвиненным в быдлокодерстве)))
причина в анекдоте про обезьян "здесь так принято"

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

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

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

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

(37) Насчёт "переходы вместо рекурсии" - тут поподробнее, пожалуйста. Хвостовая рекурсия ведь эквивалентна циклу.

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

(39) Ну, 1Совский компилятор не сильно утруждает себя оптимизациями... :-)
Насчёт выходов из вложенных циклов - согласен.

(36) без динамики разве не теряется универсальность ?

(41) все зависит от конкретного случая: к примеру если я точно буду знать размер массива в конечном итоге, то я могу использовать его без потери универсальности
далее, я могу задать предположительный размер массива, и при необходимости динамически увеличивать его размер, опять же универсальность на месте

конечно если нужна сортировка значений и тп, то предпочтительнее использовать таблицу

(41) Нет. Динамика сохраняется. Вопрос - в контроле, я бы даже сказал, в "вычислимости".

(39) если надо выходить из вложенного цикла сразу на нулевой уровень, достаточно оформить этот код в отдельную процедуру, тогда выход через "возврат"

(44) В общем случае - не всё так просто.

(44) выход может быть не на нулевой уровень
плюс мы теряем локальные переменные

массивы и ТЗ - отстой в вчерашний день!
деревья списков значений - вот настоящее!

(0) в 7.7 массив -- тз с одной строкой )

(48) с чего бы это?

(47) шутка?

(47) правильные программисты сохраняют коллекции в текстовые файлы и читают их из файлов при необходимости

+(51) это между прочим экономи оперативную память

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

(51)
в 7.7 нет коллекций ;)

а обращения к диску происходят медленнее чем к ОЗУ

(53) сз

В 8-ке в параметр сеанса можно передать массив, причем только фиксированный. А параметры сеанса нужны для работы RLS.

(53) ну то что было до коллекций.. всякие там массивы, списки, таблицы и тд и тп..

(57) жесть, а что такое коллекции?

А массив и ТЗ не одинаково хранятся ?

(27) Массивы в семерке в несколько раз быстрее ТЗ.

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

(61) в 1С это сплошь и рядом. тоже не нравится. но по опыту если блоки с кучей вложенных циклов объединить в процедуру, будет только удобнее

(60) А как ты к версии в (48) отнесешься?
Мне это старший товарищ сказал в бородатом 2006-ом, когда я еще на преддипломной практике был. У товарища было тиражное решение, успешно продававшееся. Думаю, он вряд ли мне нагло врал )

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

(60) да я не против массивов, сам при переходе с дельфей на 1с тяжко привыкал к тз, просто привык давать внятные, не требующие комментариев наименования переменным, а названия типа А, Б и т.д убивало понимание, да и массивы там использовались некорректно - в зависимости от номера элемента в массиве была разная обработка :-( этих элементов

(63) Такой вариант по быстродействию я не сравнивал, но присвоение в ТЗ в любом случае дольше чем в массив, даже на одной ячейке. Так что это не совсем так.

(66) а кстати, не в курсе почему в семерке была очень существенная разница в быстродействии, если искать значение в списке значений, и просто проверять принадлежность списку? Принадлежит() тормозит просто жутко

(67) Нет, не в курсе.

(67) Не берусь утверждать, но можнт это связано с тем, что принадлежит() ищет с учетом иерархии.

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

(69)+ Тогда каждый элемент списка, как минимум, надо проверять на тип значения и потом еще и на группа, не группа. Это если проверяется элемент справочника на принадлежит.

(69) в десятку

(0) Ненужны массивы?? Мне как-то для реализации универсальных вертикальных группировок не хватило наличия двухмерных массивов.

примерно вот такой код пришлось городить...




Перем ВертикальнаяГруппировка1[1000];
Перем ВертикальнаяГруппировка2[1000];
Перем ВертикальнаяГруппировка3[1000];
Перем ВертикальнаяГруппировка4[1000];
Перем ВертикальнаяГруппировка5[1000];
Перем ВертикальнаяГруппировка6[1000];
Перем ВертикальнаяГруппировка7[1000];
Перем ВертикальнаяГруппировка8[1000];
Перем ВертикальнаяГруппировка9[1000];
                                                                     
Перем КоличествоВертикальныхЭлементов;


Процедура УстановитьФункцииЗапросаПоЗначениямСтолбцов(ТекстЗапроса)  
                       
   Перем ТекстУсловия[9];
   
   Для К=1 По КоличествоВертикальныхЭлементов Цикл
                             
       Для Усл = 1 По 5 Цикл
           Если Усл = 1 Тогда
               ЗначениеКолонки = ВертикальнаяГруппировка1[К];
           ИначеЕсли Усл = 2 Тогда
               ЗначениеКолонки = ВертикальнаяГруппировка2[К];
           ИначеЕсли Усл = 3 Тогда
               ЗначениеКолонки = ВертикальнаяГруппировка3[К];
           ИначеЕсли Усл = 4 Тогда
               ЗначениеКолонки = ВертикальнаяГруппировка4[К];
           ИначеЕсли Усл = 5 Тогда
               ЗначениеКолонки = ВертикальнаяГруппировка5[К];
           ИначеЕсли Усл = 6 Тогда
               ЗначениеКолонки = ВертикальнаяГруппировка6[К];
           ИначеЕсли Усл = 7 Тогда
               ЗначениеКолонки = ВертикальнаяГруппировка7[К];
           ИначеЕсли Усл = 8 Тогда
               ЗначениеКолонки = ВертикальнаяГруппировка8[К];
           ИначеЕсли Усл = 9 Тогда
               ЗначениеКолонки = ВертикальнаяГруппировка9[К];            
           КонецЕсли;                                        
       
           
           Если ЗначениеКолонки="" Тогда
               ТекстУсловия[Усл] ="";
           Иначе  
               НазваниеГруппировки = СписокГруппировокСтолбцы.ПолучитьЗначение(усл);
               Если ТипЗначенияСтр(ЗначениеКолонки)="Справочник" Тогда
               
                   Если ЗначениеКолонки.ЭтоГруппа()=1 Тогда
                       ТекстУсловия[Усл] = "("+НазваниеГруппировки+"  в ВертикальнаяГруппировка"+усл+"["+к+"])";
                   Иначе
                           ТекстУсловия[Усл] = "("+НазваниеГруппировки+"= ВертикальнаяГруппировка"+усл+"["+к+"])";
                   КонецЕсли;
               Иначе
                   ТекстУсловия[Усл] = "("+НазваниеГруппировки+"= ВертикальнаяГруппировка"+усл+"["+к+"])";
               КонецЕсли;                
           КонецЕсли;
       КонецЦикла;
       
       ТекстЗапроса = ТекстЗапроса+"
       |Функция Функ"+к+" = Сумма(Приход-Расход) Когда ("+ТекстУсловия[1]+"
       
       Для Усл=2 По 9 Цикл
           Если ПустоеЗначение(ТекстУсловия[Усл])=0 Тогда                              
               ТекстЗапроса = ТекстЗапроса +"
               |И "+ТекстУсловия[Усл];            
           КонецЕсли;
       КонецЦикла;
       
       ТекстЗапроса = ТекстЗапроса+"
       |);";            
               
   КонецЦикла;
КонецПроцедуры

(72) Какбы двухмерный массив от одномерного ничем не отличается.

В твоем случае, вместо индексации [в,г]
Просто пишешь [в*1000+г], и массив объявляешь на 10000.

(0) ты ещё про СЗ спроси

(0) имхо, тяжкое наследие 7.0, в которой не было тз.

(76)тогда уж 7.5:-)

Последняя версия без тз. Может и была в природе 7.6, но я ее не видел

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

(78)>>когда какой использовать хез

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

К обилию просто привыкнуть нужно, ничего особо страшного. Это еще спасибо скажи, что свои классы писать нельзя.  А то бы ты в чужой конфе вообще утонул,если бы каждый писатель к существующим еще и свои типы ваял:-)

(0)В 7.7 это просто баловство :)

(72)А не проще было бы через ТЗ все организовать?

(81) Для реализации многомерных структур данных в семерке самое то использовать индексированную таблицу из 1с++. Стандартная таблица значений тормозная и неудобная в плане фильтрации

(79) Зато в семерке как раз можно создавать классы :)

(83) Через 1с++? :-)

(0) без массива не слепить условие в тексте оле-запроса.

+85 по вхождению в список значений, например

(10) > зачем разрабы в 7 делали массивы...
Когда "разрабы делали 7", то ТЗ там не было (в 7.5 например), а появились они только в 7.7. И что, по-твоему, "разрабы" должны были при добавлении ТЗ в язык, УБРАТЬ массивы? Зачем? :)

(73)(74) Для этого нужно иметь некоторое понимание, "что ж такое массив", и умение думать.

(0) Для специализированных задач.

Как верно заметил NS скорости работы в 1С 7.7 с массивами и ТЗ (или ИТЗ из 1С++) несравнимые. Очень хорошо я это ощутил, когда писал для PlanetWars::1C

Вот отличный пример, где можно использовать массив: http://www.kansoftware.ru/?tid=4273

(88) не соглашусь. Для того, чтобы использовать одномерный массив как двумерный, понимать что такое массив совсем не обязательно :)

(0)  ТЗ появились по моему с 7.7
Массивы были сразу начиная с 7.0

(0) зачем семерка, если есть восьмерка?

(78) пример?

(94) зачем 1С если есть ВС

Зачем компьютер, если есть наркотики?

(97) тонко подмечено)