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

Оказывается эта цифра равна 27!
Или я ошибаюсь? при количестве неявных параметров большем 27, происходит ошибка:
Цитата:


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


Тест прилагается.
Тестировалось на 1С++ 2.0.3.1, а также 2.0.3.0

привлеку к себе внимание до срока:
1) может кто-нибудь использует активно неявные параметры и поделится впечатлениями? Может я что-то делаю не так?
2) смотрел ли кто-нибудь мой тест, проявляется ли ошибка в нем?

PS Добавил еще один тест для вызова "по простому" - т.е. тупо описанные в модуле функции с разным количеством параметров

спасибо за внимание! 

т.е. не то, чтобы я очень боялся остаться без него, но все таки кое-что уже прояснилось - не только у меня "что-то с глазами"...

ну чтож пока поищу другие пути-дорожки...

Цитата:

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

2) хочется иметь метод, с помощью которого за один вызов можно передать Идентификатор значения и Неопределенное количество параметров парами(ИдПараметра,Значение), где-то так:

	СтрЗапроса = Запрос.ВставитьПеременнуюЗапроса(
				"ДатаКонца" //---Переменная
				,"УсловиеВыполнитьДействие","УстановитьТекстовыйПараметр"
				,"УсловиеПараметр1","ДатаКонца"
				);
 

другой вызов:

	СтрЗапроса = Запрос.ВставитьПеременнуюЗапроса(
				"Фирма" //---Переменная
				,"ПеременнаяSQL","$РегОстатки.Фирма"
				,"ТекстSELECT","$РегОстатки.Фирма AS Firma"
				,"ТекстJOIN",""
				,"ТекстWHERE","($РегОстатки.Фирма IN (SELECT val FROM #ВыбРазделитель1<@>))"
				,"ТекстWHERE_ВсеКроме","($РегОстатки.Фирма NOT IN (SELECT val FROM #ВыбРазделитель1<@>))"
				,"ТекстGROUPBY","$РегОстатки.Фирма"
				,"ТекстORDERBY",""
				,"УсловиеВыполнитьДействие","УложитьСписокОбъектов"
				,"УсловиеПараметр1","ВыбРазделитель1"
				,"УсловиеПараметр2","#ВыбРазделитель1<@>"
				,"УсловиеПараметр3","Фирмы"
				);
 

почему именно метод? потому что в противном случае (если пользоваться таблице значений или структурой), то придется делать что-то такое:

ТЗ.НоваяСтрока()
ТЗ.Переменная = "Фирма";
ТЗ.ПеременнаяSQL = "$РегОстатки.Фирма";
ТЗ.ТекстSELECT = "$РегОстатки.Фирма AS Firma" 

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

ТЗ.ЗаписатьСтроку() 

или передавать уже готовую структуру в качестве параметра...

всяко можно, но наглядность уменьшается (для меня  )

Цитата:

видимо так и придется поступить

Ну нет... Структура - это структура. А параметры - это параметры.

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

[quote author=DrACe link=1170137838/0#0 date=1170137838]Оказывается эта цифра равна [highlight]27[/highlight]!
[/quote]
Больше не равна :)
[url]http://www.1cpp.ru/forum/YaBB.pl?num=1158076903/60#60[/url]

х.з. это к Deb'у вопрос.

Ну ни просто так же он это ограничение поставил. Видать так надо было. А вдруг какая-нить хрень непонятная начнется...

Кстати, вот и Deb.
Дмитрий, напомни плз историю, в чем был смысл такого ограничения?

А вот теперь сабж вызывает интерес:

DrACe писал(а) 30. Января 2007 :: 07:13:

Еще момент, если количество больше 30, то использовался старый механизм получения количества параметров, путем парсинга текущей исполняемой строки, у которого было несколько существенных недостатков. Вообще-то думаю, что за это время, которое прошло, можно убрать это ограничение и этот код - парсинга, т.к. время показало, что в принципе "быстрый-хакерский" метод работает довольно стабильно... Хотя кто знает, что будет на следующих релизах от 1С...

Deb писал(а) 30. Января 2007 :: 15:49:

Ну, чтобы народ успокоить:
1. Оставлен один метод определения через IsOleContext() /EBX для любых количеств
2. Протестировано для количества параметров 1000 - проблем нет
3. Старый алгоритм выведен из обращения.

Думаю, будет нормально.

kms писал(а) 30. Января 2007 :: 15:57:

Михаил, проверял ли ты, работает ли этот метод при вызове через Шаблон?
Как поведет он себя в случае
вм.GetMethOfContext(объект)?
Как он отработает при:

CBLContext* pCont = CBLContext::CreateInstance(strNameInstance);
int nFunc = pCont->FindMethod("УказанныйМетод");
if(nFunc>=0)
{
     BOOL bIsFinc = pCont->HasRetVal(nFunc);
     int nParams = pCont->GetNParams(nFunc);
     // И так далее
}

orefkov писал(а) 31. Января 2007 :: 07:11:

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

Цитата:

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

Твой вопрос закономерен. Но у меня нет полной картины вот в чем:
1. Что должен возвращать GetMethOfContext() и GetNParams() в случае применения к методу с неявным числом параметров, в ситуациях, когда истинное число параметров определить невозможно?
2. На данный момент это где-то документировано или есть какая-то публичная договоренность?

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

artbear писал(а) 01. Февраля 2007 :: 07:54:

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

Тем более, если ты не в теме.

P.S.
Ребятки, это ненормально, когда на десятисекундное решение проблемы я теперь должен потратить 2 часа на обсуждение этой темы с каждым, кто считает своим долгом принять в ней участие.

Именно поэтому я не занимаюсь развитием ООП в 1С++ и в планах этого нет и в данном формате никогда не будет.

+1
Пусть принимает их в СЗ что-ли...

1. Нужна обратная совместимость.
2. Я за СЗ. Так как это сделано в ВМ.

mash писал(а) 24. Марта 2007 :: 12:38:

Для страховки... 

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

Может быть, номер метода стоит определять при добавлении обработчика, а проверку параметров откладывать на потом?