71 risposte a questa discussione

[Killer application]

Vedo che non sono il solo ad avere una leggera confusione in ambito development

[blindwrite]

La documentazione non esiste.
Il codice e' il documento che dobbiamo produrre, come gli ingegneri civili producono i progetti di un ponte il nostro progetto e' il codice.
Poi sta al compilatore trasformarlo in un eseguibile, come sta ai manovali trasformare il progetto dell'ingegnere in un ponte.
Inutile dire che per questo motivo il codice DEVE essere ben scritto e comprensibilissimo da chiunque, altrimenti e' SHIT.

Maccheccazzo dici ?

*
Come dire progetto una casa, ma non lascio uno straccio di foglio per dire dove passano le condutture e come è fatto l'impianto...

Meglio buttarla giù in caso di riparazioni che cercare dove mettere le mani.

Discorso applicabile per qualunque cosa, ancora più valido se il lavoro finale è qualcosa fatto in gruppo.

[Killer application]

2-1 per la documentazione.

palla al centro

[blindwrite]

2-1 per la documentazione.

palla al centro

Neppure io son un fan della documentazione, ma se fai qualcosa che poi qualcuno deve riprendere (o anche solqmente potrebbe riprendere) è d'obbligo lasciare qualcosa di comprensibile e qualche riga di commento.

Oggi ho passato il pomeriggio a scrivere la doc per un test chip. Già solo lasciare un foglio che dice con quali versioni di software l'ho disegnato è un grande aiuto se fra 2 mesi ci devo rimettere mano.

[trallallero]

?[/url]":1mhwq7q2] 2-1 per la documentazione.

palla al centro :fiore:

Neppure io son un fan della documentazione, ma se fai qualcosa che poi qualcuno deve riprendere (o anche solqmente potrebbe riprendere) è d'obbligo lasciare qualcosa di comprensibile e qualche riga di commento.

Oggi ho passato il pomeriggio a scrivere la doc per un test chip. Già solo lasciare un foglio che dice con quali versioni di software l'ho disegnato è un grande aiuto se fra 2 mesi ci devo rimettere mano.

Appunto, a nessuno piace molto documentare ma se fai un server che è un client per un altro processo in un progetto costituito da una catena client-server su un sistema linux-windows, vorrai lasciare 2 righe che spiegano almeno come viene configurato e fatto partire il tutto ?

Proprio ieri, visto che stiamo creando un nuovo build system, ho dovuto rimettere mani sul mio primo progetto fatto qui. Ho dovuto leggere il README perché non ricordavo niente. Che poi il progetto dipende da altri progetti infatti ho dovuto rileggere anche le varie dipendenze e versioni VCS (bazaar) che per fortuna avevo lasciato scritto, altrimenti sarei stato fottuto.

*
Come dire progetto una casa, ma non lascio uno straccio di foglio per dire dove passano le condutture e come è fatto l'impianto...

Meglio buttarla giù in caso di riparazioni che cercare dove mettere le mani.

Discorso applicabile per qualunque cosa, ancora più valido se il lavoro finale è qualcosa fatto in gruppo.

Probabilmente Tigershark è un muratore

[TigerShark]

?[/url]":2py7qkw8]
La documentazione non esiste.
Il codice e' il documento che dobbiamo produrre, come gli ingegneri civili producono i progetti di un ponte il nostro progetto e' il codice.
Poi sta al compilatore trasformarlo in un eseguibile, come sta ai manovali trasformare il progetto dell'ingegnere in un ponte.
Inutile dire che per questo motivo il codice DEVE essere ben scritto e comprensibilissimo da chiunque, altrimenti e' SHIT.

Ok da parte tua c'è un Agile Fan. Che il mio prof di Project Management dice essere "una moda passata che non troverete mai in ambito aziendale"

Ci capisco piu un cazzo

Ovvio.
La cosa sorprendente e che in italia ci ha messo DIECI anni ad arrivare questo concetto. :fiore:
Qui era il 2001 quando si muovevano i primi passi nell'agile programming, e io personalmente ho iniziato con fek nel 2005 col progetto diamonds.
In italia le novita' dell'informatica SE VA BENE ci mettono 10 anni ad arrivare.
Ascolta il tuo prof che parla di agile che mi sembra l'unico tra tutti ad essere un minimo aggiornato, gli altri sono solo vecchi bacucchi che pensano ancora che un progetto informatico sia del tutto simile ad un progetto di ingegneria civile, cosa assolutamente e TOTALMENTE falsa.
I requisiti di costruzione di un ponte sono fissati e ben definiti all'inizio.
Quando inizierai a lavorare ti accorgerai di quanto siano fissi e, mentre mia madre succhia cazzi, inamovibili i requisiti informatici. :fiore:

[TigerShark]

?[/url]":24pd79sw]

My ambition :fiore:

Diventare mister no-life è la tua ambition ?

No women, no beers, no hobbies... no life :fiore:

La documentazione non esiste.
Il codice e' il documento che dobbiamo produrre, come gli ingegneri civili producono i progetti di un ponte il nostro progetto e' il codice.
Poi sta al compilatore trasformarlo in un eseguibile, come sta ai manovali trasformare il progetto dell'ingegnere in un ponte.
Inutile dire che per questo motivo il codice DEVE essere ben scritto e comprensibilissimo da chiunque, altrimenti e' SHIT.

Maccheccazzo dici ?

Deduco che anche in germania l'agile programming non e' poi cosi' ben diffuso.
Ma cazzo, e' nato in america intorno al 2001 e qui e' sbarcato dopo 6 mesi piu' o meno.
Possibile che ancora ci siano realta' informatiche che non utilizzano metodologie agile per programmare?
epic terzo mondo.
Grazie a dio sono finito qui, un altro anno di quella merda di sviluppo con metodologie tradizionali mi avrebbe ucciso.

[TigerShark]

?[/url]":3gdpv0e1]



Maccheccazzo dici ?

*
Come dire progetto una casa, ma non lascio uno straccio di foglio per dire dove passano le condutture e come è fatto l'impianto...

Meglio buttarla giù in caso di riparazioni che cercare dove mettere le mani.

Discorso applicabile per qualunque cosa, ancora più valido se il lavoro finale è qualcosa fatto in gruppo.

Capito un cazzo, come al solito. :fiore:
La documentazione e' nel codice e, soprattutto, nei TEST.
Basta leggere i test per capire ESATTAMENTE come funziona il tutto.
E un test fatto bene esprime il concetto INFINITAMENTE meglio di una cagata di documento che va aggiornato GIORNO PER GIORNO al cambiare dei requisiti e dell'implementazione.
Aggiornare sia il codice che il documento e' uno spreco di tempo abissale.
Cmq vedo che l'italia non e' la sola ad essere nel terzo mondo informatico cazzo. :fiore:

[TigerShark]

?[/url]":1r8eskr4] 2-1 per la documentazione.

palla al centro :fiore:

Neppure io son un fan della documentazione, ma se fai qualcosa che poi qualcuno deve riprendere (o anche solqmente potrebbe riprendere) è d'obbligo lasciare qualcosa di comprensibile e qualche riga di commento.

Oggi ho passato il pomeriggio a scrivere la doc per un test chip. Già solo lasciare un foglio che dice con quali versioni di software l'ho disegnato è un grande aiuto se fra 2 mesi ci devo rimettere mano.

I commenti nel codice, a meno di casi particolari, sono un indice che il codice e' scritto male.
Se il codice ha bisogno di un commento allora significa che non e' chiaro e puo' essere scritto in maniera piu' chiara.
Il codice ideale viene letto come un documento in inglese senza alcuna difficolta'.
Fek ai tempi faceva leggere il suo codice alla sua ragazza che capiva di informatica quanto un tostapane capisce di meccanica quantistica.
Se lei non riusciva a capire cosa faceva il suo codice assolutamente privo di commenti allora buttava giu' tutto e lo riscriveva.
Ma immagino che voi non abbiate mai visto del codice scritto bene se arrivate a dire che la documentazione e' addirittura INDISPENSABILE.

[TigerShark]

?[/url]":8rqcpi32]
Neppure io son un fan della documentazione, ma se fai qualcosa che poi qualcuno deve riprendere (o anche solqmente potrebbe riprendere) è d'obbligo lasciare qualcosa di comprensibile e qualche riga di commento.

Oggi ho passato il pomeriggio a scrivere la doc per un test chip. Già solo lasciare un foglio che dice con quali versioni di software l'ho disegnato è un grande aiuto se fra 2 mesi ci devo rimettere mano.

Appunto, a nessuno piace molto documentare ma se fai un server che è un client per un altro processo in un progetto costituito da una catena client-server su un sistema linux-windows, vorrai lasciare 2 righe che spiegano almeno come viene configurato e fatto partire il tutto ?

Proprio ieri, visto che stiamo creando un nuovo build system, ho dovuto rimettere mani sul mio primo progetto fatto qui. Ho dovuto leggere il README perché non ricordavo niente. Che poi il progetto dipende da altri progetti infatti ho dovuto rileggere anche le varie dipendenze e versioni VCS (bazaar) che per fortuna avevo lasciato scritto, altrimenti sarei stato fottuto.

*
Come dire progetto una casa, ma non lascio uno straccio di foglio per dire dove passano le condutture e come è fatto l'impianto...

Meglio buttarla giù in caso di riparazioni che cercare dove mettere le mani.

Discorso applicabile per qualunque cosa, ancora più valido se il lavoro finale è qualcosa fatto in gruppo.

Probabilmente Tigershark è un muratore :fiore:

Quelle due righe non si chiamano documentazione.
E quelle due righe sono perfettamente legit in quanto spiegano solo ad alto livello cosa dovrebbe fare il sistema e sono necessarie per interfacciarsi con altri sistemi.
La documentazione del codice spiega IN DETTAGLIO cosa fa il proprio sistema, come javaDoc.
Se non si sta scrivendo una libreria che dovra' essere utilizzata da tutti allora perdere tempo a documentare tutto il codice con javadoc et similia e' solo uno spreco di tempo dato che ci sara' un costo anche per mantenere la documentazione.
E a me finora non e' mai capitato di lavorare su qualcosa di simile.
Quanto ai commenti, che secondo me sono la cosa che piu' si avvicina al concetto di "documentazione", vale assolutamente quanto ho gia' detto sopra.

[trallallero]

?[/url]":22vlivz4]
Diventare mister no-life è la tua ambition ? :fiore:

No women, no beers, no hobbies... no life :fiore:



Maccheccazzo dici ?

Deduco che anche in germania l'agile programming non e' poi cosi' ben diffuso.
Ma cazzo, e' nato in america intorno al 2001 e qui e' sbarcato dopo 6 mesi piu' o meno.
Possibile che ancora ci siano realta' informatiche che non utilizzano metodologie agile per programmare?
epic terzo mondo.
Grazie a dio sono finito qui, un altro anno di quella merda di sviluppo con metodologie tradizionali mi avrebbe ucciso.

L'agile programming andrà bene da voi che fate programmi per fare soldi dai soldi (aka aria fritta).
Qui facciamo software che gestisce hardware costruito da noi (armi, caschi con radio e visori, intere torri di controllo per simulazioni militari, carri armati con proiettori che mostrano la simulazione a 360°)... agile programming

[TigerShark]

?[/url]":tltv969q]
Deduco che anche in germania l'agile programming non e' poi cosi' ben diffuso.
Ma cazzo, e' nato in america intorno al 2001 e qui e' sbarcato dopo 6 mesi piu' o meno.
Possibile che ancora ci siano realta' informatiche che non utilizzano metodologie agile per programmare?
epic terzo mondo. :fiore:
Grazie a dio sono finito qui, un altro anno di quella merda di sviluppo con metodologie tradizionali mi avrebbe ucciso. :fiore:

L'agile programming andrà bene da voi che fate programmi per fare soldi dai soldi (aka aria fritta).
Qui facciamo software che gestisce hardware costruito da noi (armi, caschi con radio e visori, intere torri di controllo per simulazioni militari, carri armati con proiettori che mostrano la simulazione a 360°)... agile programming

L'agile programming va bene per tutto.
Scrivere dei test che certifichino il corretto funzionamento del sistema e documentino molto meglio di n-mila documenti cosa fa il codice e' essenziale per scrivere un buon codice flessibile e manutenibile.
Se io, appena entrato nel team, vado a mettere mani sul codice e faccio qualche cazzata ci sono fior di test che saltano e me ne accorgo SUBITO, appena committo il codice e la build machine fa partire i test.
E questo senza dover leggere una sola riga di documentazione.

[trallallero]

?[/url]":36gumnrz]
L'agile programming andrà bene da voi che fate programmi per fare soldi dai soldi (aka aria fritta).
Qui facciamo software che gestisce hardware costruito da noi (armi, caschi con radio e visori, intere torri di controllo per simulazioni militari, carri armati con proiettori che mostrano la simulazione a 360°)... agile programming

L'agile programming va bene per tutto.
Scrivere dei test che certifichino il corretto funzionamento del sistema e documentino molto meglio di n-mila documenti cosa fa il codice e' essenziale er scrivere un buon codice flessibile e manutenibile.
Se io, appena entrato nel team, vado a mettere mani sul codice e faccio qualche cazzata ci sono fior di test che saltano e me ne accorgo SUBITO, appena committo il codice e la build machine fa partire i test.
E questo senza dover leggere una sola riga di documentazione.

L'agile programming va bene quando ti ritrovi il progetto bello che definito, disegnato da qualcuno sopra di te che lo dirige. Quando invece il progetto lo crei tu e il tuo team da zero e lo dirigi tu e il tuo team, non c'è agilecoso che tenga. Se devi andare nel carro armato e misurare col tester gli ampere della radio per poter sapere come fare la funzione che modifica il volume (scrivo a caso ma son cose che succedono quando hai a che fare con hardware complesso), scriverai 2 righe nella funzione per la prossima volta che dovrai modificarla ?

E comunque sei passato da "no documentation at all" a "no documentation in the code" (o almeno questo è quello che sembrava al tuo primo post).

[TigerShark]

?[/url]":2eupdevn]
L'agile programming va bene per tutto.
Scrivere dei test che certifichino il corretto funzionamento del sistema e documentino molto meglio di n-mila documenti cosa fa il codice e' essenziale er scrivere un buon codice flessibile e manutenibile.
Se io, appena entrato nel team, vado a mettere mani sul codice e faccio qualche cazzata ci sono fior di test che saltano e me ne accorgo SUBITO, appena committo il codice e la build machine fa partire i test.
E questo senza dover leggere una sola riga di documentazione.

L'agile programming va bene quando ti ritrovi il progetto bello che definito, disegnato da qualcuno sopra di te che lo dirige. Quando invece il progetto lo crei tu e il tuo team da zero e lo dirigi tu e il tuo team, non c'è agilecoso che tenga. Se devi andare nel carro armato e misurare col tester gli ampere della radio per poter sapere come fare la funzione che modifica il volume (scrivo a caso ma son cose che succedono quando hai a che fare con hardware complesso), scriverai 2 righe nella funzione per la prossima volta che dovrai modificarla ?

E comunque sei passato da "no documentation at all" a "no documentation in the code" (o almeno questo è quello che sembrava al tuo primo post).

Per me documentazione e' quello che ho spiegato prima.
Quanto all'esempio del carroarmato scrivero' un test che certifichi i valori che il mio metodo dovra' tirare fuori.
E se qualcuno in futuro scrivera' qualche cazzata e in qualche modo i valori che escono da questo metodo saranno diversi da quanto aspettato allora il test fallira' e tutti potranno rendersi conto subito dell'errore e porvi rimedio, vedendo l'esatto punto del codice in cui il bug e' stato introdotto.
E tutto questo senza magari aspettare che il carroarmato salti in aria per un bug.

[trallallero]

?[/url]":15t55r01]
L'agile programming va bene quando ti ritrovi il progetto bello che definito, disegnato da qualcuno sopra di te che lo dirige. Quando invece il progetto lo crei tu e il tuo team da zero e lo dirigi tu e il tuo team, non c'è agilecoso che tenga. Se devi andare nel carro armato e misurare col tester gli ampere della radio per poter sapere come fare la funzione che modifica il volume (scrivo a caso ma son cose che succedono quando hai a che fare con hardware complesso), scriverai 2 righe nella funzione per la prossima volta che dovrai modificarla ?

E comunque sei passato da "no documentation at all" a "no documentation in the code" (o almeno questo è quello che sembrava al tuo primo post).

Per me documentazione e' quello che ho spiegato prima.
Quanto all'esempio del carroarmato scrivero' un test che certifichi i valori che il mio metodo dovra' tirare fuori.
E se qualcuno in futuro scrivera' qualche cazzata e in qualche modo i valori che escono da questo metodo saranno diversi da quanto aspettato allora il test fallira' e tutti potranno rendersi conto subito dell'errore e porvi rimedio, vedendo l'esatto punto del codice in cui il bug e' stato introdotto.
E tutto questo senza magari aspettare che il carroarmato salti in aria per un bug. :fiore:

Quindi qualcosa oltre al codice lo devi scrivere.

Comunque, a proposito di "no documentation in the code", vorrei sapere che faccia fai quando dopo, diciamo un anno, ma un mese sarebbe sufficiente, rimetti mano ad un tuo algoritmo che gestisce una list of maps of pairs of lists.
Poi se l'algoritmo non è tuo non serve che me lo spieghi, la faccia è senza dubbio questa " "

[TigerShark]

?[/url]":1l4fi33m]
Per me documentazione e' quello che ho spiegato prima.
Quanto all'esempio del carroarmato scrivero' un test che certifichi i valori che il mio metodo dovra' tirare fuori.
E se qualcuno in futuro scrivera' qualche cazzata e in qualche modo i valori che escono da questo metodo saranno diversi da quanto aspettato allora il test fallira' e tutti potranno rendersi conto subito dell'errore e porvi rimedio, vedendo l'esatto punto del codice in cui il bug e' stato introdotto.
E tutto questo senza magari aspettare che il carroarmato salti in aria per un bug. :fiore:

Quindi qualcosa oltre al codice lo devi scrivere.

Comunque, a proposito di "no documentation in the code", vorrei sapere che faccia fai quando dopo, diciamo un anno, ma un mese sarebbe sufficiente, rimetti mano ad un tuo algoritmo che gestisce una list of maps of pairs of lists.
Poi se l'algoritmo non è tuo non serve che me lo spieghi, la faccia è senza dubbio questa " "

No, i test sono parte del codice.
Anzi, lavorando in TDD, PRIMA si scrivono i test e solo DOPO si scrive il codice che li fa passare.
Il codice che io scrivo e' chiarissimo anche prendendolo dopo un anno dato che cerco di esplicitare chiaramente cosa fa il mio codice nel codice stesso.
tanto per fare un esempio:

int count = 0;

for (int i = 0; i < document.length; i++)

{

    if (document[i] == "a") 

        count++; 

}

Console.WriteLine(count);

Console.WriteLine(document.Count(ch => ch == "a"));

Entrambi gli snippet di codice fanno esattamente la stessa cosa.
Solo che per capire cosa fa il primo ci metti MOLTO piu' tempo rispetto a capire cosa fa il secondo.
Io ovviamente utilizzo sempre la seconda versione.
E con codice decisamente piu' complesso vado avanti col continuous design e faccio sempre refactoring, soprattutto estraendo classi e metodi in modo da migliorare il codice.
Se tutti i programmatori seguissero la massima di Baden Powell: "Lasciate il mondo un po' migliore di come l'avete trovato", dove il mondo del programmatore e' ovviamente il codice su cui mette le mani, molte cose migliorerebbero.
Alla fine, come diceva il grande Martin Fowler, "Any fool can write code that a computer can understand. Good programmers write code that humans can understand."

[Sgobbone]

Due anni che non vedevo un ciclo for. :fiore: :fiore:

estoteparatifag here.

[trallallero]

Si certo, belle parole che vanno bene per il cicletto da 0 a n.

Se devi gestire i disturbi di n frequenze di n radio di n soldati in n carro armati in una zona con n jamming areas, un cicletto++ non ti basta.

Per capire cosa ho fatto in sto ciclo, se non l'avessi commentato, dopo un anno ci metterei ore (ho tolto i commenti per lasciare la sensazione di buio ).

for ( list::const_iterator itFreq = m_FreqsToBeDisturbedList.begin(); itFreq != m_FreqsToBeDisturbedList.end(); ++itFreq )

	{

		LL_ID id;

		LLMatrixUser::IsFreqTalking( *itFreq, &id );



		if (id > 0)

		{

			LogL.Write(LogLib::LOGLIB_WARNING_MSG, LOGLIB_FIX_ARGS, 0, "Freq talking: ", *itFreq);



			LLPanel* pPan = LLPanelHandler::GetEntity(id);



			if (pPan)

			{

				unsigned int MatId = LLMatrixClientHandler::GetClientId(pPan->GetName());



				if (MatId)

				{

					vector EnabledColumns;

					LLMatrixClientHandler::GetListeners( EnabledColumns, MatId );



					for ( vector::iterator x = EnabledColumns.begin(); x != EnabledColumns.end(); ++x )

						LogL.Write(LogLib::LOGLIB_WARNING_MSG, LOGLIB_FIX_ARGS, 0, "Listner id: ", *x);





					if (EnabledColumns.size() > 0)

					{

						m_Freq_TalkId_DisturbedIdsMap[(*itFreq)].insert(make_pair(MatId, EnabledColumns));



						for (  mapFreq_TalkId_DisturbedIds::iterator x = m_Freq_TalkId_DisturbedIdsMap.begin();

						       x != m_Freq_TalkId_DisturbedIdsMap.end();

						       ++x )

						{

							for ( map<unsigned int, vector >::iterator y = x->second.begin(); y != x->second.end(); ++y )

							{

								for ( vector::iterator o = y->second.begin(); o != y->second.end(); ++o )

								{

									QMap qmFadeMap;



									if (pPan->panelType() == PT_Laks)

									{

										LogL.Write(LogLib::LOGLIB_WARNING_MSG, LOGLIB_FIX_ARGS, 0, "DISTURB - talker PT_Laks");



										qmFadeMap[y->first]        = 0;

										qmFadeMap[m_NoiseClientId] = 100;

									}

									else

									{

										LLMatrixClient* c = LLMatrixClientHandler::GetClient((*o));

										if (c)

										{

											LogL.Write(LogLib::LOGLIB_WARNING_MSG, LOGLIB_FIX_ARGS, 0, "DISTURB - listener: ", c->GetName_c_str());



											LLPanel* p = LLPanelHandler::GetEntity(c->GetName());

											if (p && p->panelType() == PT_Laks)

											{

												LogL.Write(LogLib::LOGLIB_WARNING_MSG, LOGLIB_FIX_ARGS, 0, "DISTURB - listener PT_Laks");



												qmFadeMap[y->first]        = 0;

												qmFadeMap[m_NoiseClientId] = 100;

											}

											else

											{

												LogL.Write(LogLib::LOGLIB_WARNING_MSG, LOGLIB_FIX_ARGS, 0, "DISTURB - listener NO PT_Laks");



												qmFadeMap[y->first]        = 50;

												qmFadeMap[m_NoiseClientId] = 10;

											}

										}

									}

									GetClientInterface()->fadingAudioStream( (*o), qmFadeMap );

								}

							}

						}

					}

				}

			}

		}

	}

[Killer application]

Si certo, belle parole che vanno bene per il cicletto da 0 a n.

Se devi gestire i disturbi di n frequenze di n radio di n soldati in n carro armati in una zona con n jamming areas, un cicletto++ non ti basta.

Per capire cosa ho fatto in sto ciclo, se non l'avessi commentato, dopo un anno ci metterei ore (ho tolto i commenti per lasciare la sensazione di buio ).

void 

Se_devi_gestire_i_disturbi_di_n_frequenze_di_n_radio_di_n_soldati_in_n_carro_armati_in_una_zona_con_n_jamming_areas(int n, int n, int n){



for ( list::const_iterator itFreq = m_FreqsToBeDisturbedList.begin(); itFreq != m_FreqsToBeDisturbedList.end(); ++itFreq )

	{

		LL_ID id;

		LLMatrixUser::IsFreqTalking( *itFreq, &id );



		if (id > 0)

		{

			LogL.Write(LogLib::LOGLIB_WARNING_MSG, LOGLIB_FIX_ARGS, 0, "Freq talking: ", *itFreq);



			LLPanel* pPan = LLPanelHandler::GetEntity(id);



			if (pPan)

			{

				unsigned int MatId = LLMatrixClientHandler::GetClientId(pPan->GetName());



				if (MatId)

				{

					vector EnabledColumns;

					LLMatrixClientHandler::GetListeners( EnabledColumns, MatId );



					for ( vector::iterator x = EnabledColumns.begin(); x != EnabledColumns.end(); ++x )

						LogL.Write(LogLib::LOGLIB_WARNING_MSG, LOGLIB_FIX_ARGS, 0, "Listner id: ", *x);





					if (EnabledColumns.size() > 0)

					{

						m_Freq_TalkId_DisturbedIdsMap[(*itFreq)].insert(make_pair(MatId, EnabledColumns));



						for (  mapFreq_TalkId_DisturbedIds::iterator x = m_Freq_TalkId_DisturbedIdsMap.begin();

						       x != m_Freq_TalkId_DisturbedIdsMap.end();

						       ++x )

						{

							for ( map<unsigned int, vector >::iterator y = x->second.begin(); y != x->second.end(); ++y )

							{

								for ( vector::iterator o = y->second.begin(); o != y->second.end(); ++o )

								{

									QMap qmFadeMap;



									if (pPan->panelType() == PT_Laks)

									{

										LogL.Write(LogLib::LOGLIB_WARNING_MSG, LOGLIB_FIX_ARGS, 0, "DISTURB - talker PT_Laks");



										qmFadeMap[y->first]        = 0;

										qmFadeMap[m_NoiseClientId] = 100;

									}

									else

									{

										LLMatrixClient* c = LLMatrixClientHandler::GetClient((*o));

										if (c)

										{

											LogL.Write(LogLib::LOGLIB_WARNING_MSG, LOGLIB_FIX_ARGS, 0, "DISTURB - listener: ", c->GetName_c_str());



											LLPanel* p = LLPanelHandler::GetEntity(c->GetName());

											if (p && p->panelType() == PT_Laks)

											{

												LogL.Write(LogLib::LOGLIB_WARNING_MSG, LOGLIB_FIX_ARGS, 0, "DISTURB - listener PT_Laks");



												qmFadeMap[y->first]        = 0;

												qmFadeMap[m_NoiseClientId] = 100;

											}

											else

											{

												LogL.Write(LogLib::LOGLIB_WARNING_MSG, LOGLIB_FIX_ARGS, 0, "DISTURB - listener NO PT_Laks");



												qmFadeMap[y->first]        = 50;

												qmFadeMap[m_NoiseClientId] = 10;

											}

										}

									}

									GetClientInterface()->fadingAudioStream( (*o), qmFadeMap );

								}

							}

						}

					}

				}

			}

		}

	}

Ho capito come usare il tuo codice senza commenti.

Se_devi_gestire_i_disturbi_di_n_frequenze_di_n_radio_di_n_soldati_in_n_carro_armati_in_una_zona_con_n_jamming_areas(n,n,n)

[trallallero]