for(indx = 1; test; indx++)
{
instructions;
}
result = indx - 1;
Ca ne marche pas avec Xcode. Lorsque le test est faux, la variable indx
est quand-même incrémentée ce qui est contraire à tous les standards.
for(indx = 1; test; indx++)
{
instructions;
}
result = indx - 1;
Ca ne marche pas avec Xcode. Lorsque le test est faux, la variable indx
est quand-même incrémentée ce qui est contraire à tous les standards.
for(indx = 1; test; indx++)
{
instructions;
}
result = indx - 1;
Ca ne marche pas avec Xcode. Lorsque le test est faux, la variable indx
est quand-même incrémentée ce qui est contraire à tous les standards.
Lionel Mychkine wrote:
> for(indx = 1; test; indx++)
Je suppose que c'est du C [...]
et que tu parls du compilateur...
La valeur de indx est incrémenté à chque fois que test est vrai.
Par exemple, en C avec :
int i;
for (i=0;i<;i++)
{
...
}
println(i);
Affichera bien "11" ce qui est normal, puisque quand i, le test étant
vrai, i++ est executé (donc i passe à 11).
La boule suivante étant fausse, i reste bien à 11 en sortie et pas à 12.
Lionel Mychkine <mychkine@nowhere.invalid> wrote:
> for(indx = 1; test; indx++)
Je suppose que c'est du C [...]
et que tu parls du compilateur...
La valeur de indx est incrémenté à chque fois que test est vrai.
Par exemple, en C avec :
int i;
for (i=0;i<;i++)
{
...
}
println(i);
Affichera bien "11" ce qui est normal, puisque quand i, le test étant
vrai, i++ est executé (donc i passe à 11).
La boule suivante étant fausse, i reste bien à 11 en sortie et pas à 12.
Lionel Mychkine wrote:
> for(indx = 1; test; indx++)
Je suppose que c'est du C [...]
et que tu parls du compilateur...
La valeur de indx est incrémenté à chque fois que test est vrai.
Par exemple, en C avec :
int i;
for (i=0;i<;i++)
{
...
}
println(i);
Affichera bien "11" ce qui est normal, puisque quand i, le test étant
vrai, i++ est executé (donc i passe à 11).
La boule suivante étant fausse, i reste bien à 11 en sortie et pas à 12.
C'est exactement ce que ne fait pas Xcode. Ou plutôt le compilateur
C/C++ dans un environnement Cocoa de Xcode pour parler comme tu
comprends.
C'est exactement ce que ne fait pas Xcode. Ou plutôt le compilateur
C/C++ dans un environnement Cocoa de Xcode pour parler comme tu
comprends.
C'est exactement ce que ne fait pas Xcode. Ou plutôt le compilateur
C/C++ dans un environnement Cocoa de Xcode pour parler comme tu
comprends.
> Lionel Mychkine wrote:
>
> > for(indx = 1; test; indx++)
>
> Je suppose que c'est du C [...]
Il suffit pour s'en convaincre de lire les instructions. Ça aurait pu
être du C++ mais cela ne change rien sur le fond. Dans la vraie vie,
c'est du Cocoa.
> et que tu parls du compilateur...
Tu charries ou tu fais l'imbécile ?
> La valeur de indx est incrémenté à chque fois que test est vrai.
>
> Par exemple, en C avec :
> int i;
> for (i=0;i<;i++)
> {
> ...
> }
> println(i);
>
> Affichera bien "11" ce qui est normal, puisque quand i, le test étant
> vrai, i++ est executé (donc i passe à 11).
> La boule suivante étant fausse, i reste bien à 11 en sortie et pas à 12.
C'est exactement ce que ne fait pas Xcode.
Ou plutôt le compilateur
C/C++ dans un environnement Cocoa de Xcode pour parler comme tu
comprends.
> Lionel Mychkine <mychkine@nowhere.invalid> wrote:
>
> > for(indx = 1; test; indx++)
>
> Je suppose que c'est du C [...]
Il suffit pour s'en convaincre de lire les instructions. Ça aurait pu
être du C++ mais cela ne change rien sur le fond. Dans la vraie vie,
c'est du Cocoa.
> et que tu parls du compilateur...
Tu charries ou tu fais l'imbécile ?
> La valeur de indx est incrémenté à chque fois que test est vrai.
>
> Par exemple, en C avec :
> int i;
> for (i=0;i<;i++)
> {
> ...
> }
> println(i);
>
> Affichera bien "11" ce qui est normal, puisque quand i, le test étant
> vrai, i++ est executé (donc i passe à 11).
> La boule suivante étant fausse, i reste bien à 11 en sortie et pas à 12.
C'est exactement ce que ne fait pas Xcode.
Ou plutôt le compilateur
C/C++ dans un environnement Cocoa de Xcode pour parler comme tu
comprends.
> Lionel Mychkine wrote:
>
> > for(indx = 1; test; indx++)
>
> Je suppose que c'est du C [...]
Il suffit pour s'en convaincre de lire les instructions. Ça aurait pu
être du C++ mais cela ne change rien sur le fond. Dans la vraie vie,
c'est du Cocoa.
> et que tu parls du compilateur...
Tu charries ou tu fais l'imbécile ?
> La valeur de indx est incrémenté à chque fois que test est vrai.
>
> Par exemple, en C avec :
> int i;
> for (i=0;i<;i++)
> {
> ...
> }
> println(i);
>
> Affichera bien "11" ce qui est normal, puisque quand i, le test étant
> vrai, i++ est executé (donc i passe à 11).
> La boule suivante étant fausse, i reste bien à 11 en sortie et pas à 12.
C'est exactement ce que ne fait pas Xcode.
Ou plutôt le compilateur
C/C++ dans un environnement Cocoa de Xcode pour parler comme tu
comprends.
In article ,
Lionel Mychkine wrote:
> C'est exactement ce que ne fait pas Xcode. Ou plutôt le compilateur
> C/C++ dans un environnement Cocoa de Xcode pour parler comme tu
> comprends.
Donne un vrai programme qu'on peux compiler ainsi que le résultat si tu
veux qu'on considère cette possibilité...
In article <OKSdnUdblo4i_B7PnZ2dnUVZ7q-dnZ2d@giganews.com>,
Lionel Mychkine <mychkine@nowhere.invalid> wrote:
> C'est exactement ce que ne fait pas Xcode. Ou plutôt le compilateur
> C/C++ dans un environnement Cocoa de Xcode pour parler comme tu
> comprends.
Donne un vrai programme qu'on peux compiler ainsi que le résultat si tu
veux qu'on considère cette possibilité...
In article ,
Lionel Mychkine wrote:
> C'est exactement ce que ne fait pas Xcode. Ou plutôt le compilateur
> C/C++ dans un environnement Cocoa de Xcode pour parler comme tu
> comprends.
Donne un vrai programme qu'on peux compiler ainsi que le résultat si tu
veux qu'on considère cette possibilité...
In article
,
Patrick Stadelmann wrote:
> In article ,
> Lionel Mychkine wrote:
>
> > C'est exactement ce que ne fait pas Xcode. Ou plutôt le compilateur
> > C/C++ dans un environnement Cocoa de Xcode pour parler comme tu
> > comprends.
>
> Donne un vrai programme qu'on peux compiler ainsi que le résultat si tu
> veux qu'on considère cette possibilité...
#import <Cocoa/Cocoa.h>
#import <CoreAudio/AudioHardware.h>
// la librairie CoreAudio.framework doit se trouver dans le projet
// il faut renseigner outputDeviceID mais en principe, 40 convient
@interface AppDelegate : NSObject <NSApplicationDelegate>
@end
@implementation AppDelegate
- (void) applicationDidFinishLaunching:(NSNotification *) aNotification
{
Float32 volume;
UInt32 channel;
UInt32 propertyDataSize;
AudioObjectPropertyAddress audioPropertyAddress;
UInt32 numberOfChannels;
AudioObjectID outputDeviceID = 40;
OSStatus err = noErr;
audioPropertyAddress.mSelector = kAudioDevicePropertyVolumeScalar;
audioPropertyAddress.mScope = kAudioObjectPropertyScopeOutput;
// ###### CHANNEL EST INCREMENTE MEME SI ERR <> NOERR ######
for(channel = 1; err == noErr; channel++)
{
propertyDataSize = sizeof volume;
audioPropertyAddress.mElement = channel;
err = AudioObjectGetPropertyData(outputDeviceID,
&audioPropertyAddress, 0, NULL,
&propertyDataSize, &volume);
}
numberOfChannels = channel - 1; // ###### ERREUR ########
}
@end
In article
<Patrick.Stadelmann-798ECC.14064013112013@news.individual.net>,
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
> In article <OKSdnUdblo4i_B7PnZ2dnUVZ7q-dnZ2d@giganews.com>,
> Lionel Mychkine <mychkine@nowhere.invalid> wrote:
>
> > C'est exactement ce que ne fait pas Xcode. Ou plutôt le compilateur
> > C/C++ dans un environnement Cocoa de Xcode pour parler comme tu
> > comprends.
>
> Donne un vrai programme qu'on peux compiler ainsi que le résultat si tu
> veux qu'on considère cette possibilité...
#import <Cocoa/Cocoa.h>
#import <CoreAudio/AudioHardware.h>
// la librairie CoreAudio.framework doit se trouver dans le projet
// il faut renseigner outputDeviceID mais en principe, 40 convient
@interface AppDelegate : NSObject <NSApplicationDelegate>
@end
@implementation AppDelegate
- (void) applicationDidFinishLaunching:(NSNotification *) aNotification
{
Float32 volume;
UInt32 channel;
UInt32 propertyDataSize;
AudioObjectPropertyAddress audioPropertyAddress;
UInt32 numberOfChannels;
AudioObjectID outputDeviceID = 40;
OSStatus err = noErr;
audioPropertyAddress.mSelector = kAudioDevicePropertyVolumeScalar;
audioPropertyAddress.mScope = kAudioObjectPropertyScopeOutput;
// ###### CHANNEL EST INCREMENTE MEME SI ERR <> NOERR ######
for(channel = 1; err == noErr; channel++)
{
propertyDataSize = sizeof volume;
audioPropertyAddress.mElement = channel;
err = AudioObjectGetPropertyData(outputDeviceID,
&audioPropertyAddress, 0, NULL,
&propertyDataSize, &volume);
}
numberOfChannels = channel - 1; // ###### ERREUR ########
}
@end
In article
,
Patrick Stadelmann wrote:
> In article ,
> Lionel Mychkine wrote:
>
> > C'est exactement ce que ne fait pas Xcode. Ou plutôt le compilateur
> > C/C++ dans un environnement Cocoa de Xcode pour parler comme tu
> > comprends.
>
> Donne un vrai programme qu'on peux compiler ainsi que le résultat si tu
> veux qu'on considère cette possibilité...
#import <Cocoa/Cocoa.h>
#import <CoreAudio/AudioHardware.h>
// la librairie CoreAudio.framework doit se trouver dans le projet
// il faut renseigner outputDeviceID mais en principe, 40 convient
@interface AppDelegate : NSObject <NSApplicationDelegate>
@end
@implementation AppDelegate
- (void) applicationDidFinishLaunching:(NSNotification *) aNotification
{
Float32 volume;
UInt32 channel;
UInt32 propertyDataSize;
AudioObjectPropertyAddress audioPropertyAddress;
UInt32 numberOfChannels;
AudioObjectID outputDeviceID = 40;
OSStatus err = noErr;
audioPropertyAddress.mSelector = kAudioDevicePropertyVolumeScalar;
audioPropertyAddress.mScope = kAudioObjectPropertyScopeOutput;
// ###### CHANNEL EST INCREMENTE MEME SI ERR <> NOERR ######
for(channel = 1; err == noErr; channel++)
{
propertyDataSize = sizeof volume;
audioPropertyAddress.mElement = channel;
err = AudioObjectGetPropertyData(outputDeviceID,
&audioPropertyAddress, 0, NULL,
&propertyDataSize, &volume);
}
numberOfChannels = channel - 1; // ###### ERREUR ########
}
@end
In article
,
Patrick Stadelmann wrote:
> In article ,
> Lionel Mychkine wrote:
>
> > C'est exactement ce que ne fait pas Xcode. Ou plutôt le compilateur
> > C/C++ dans un environnement Cocoa de Xcode pour parler comme tu
> > comprends.
>
> Donne un vrai programme qu'on peux compiler ainsi que le résultat si tu
> veux qu'on considère cette possibilité...
#import <Cocoa/Cocoa.h>
#import <CoreAudio/AudioHardware.h>
// la librairie CoreAudio.framework doit se trouver dans le projet
// il faut renseigner outputDeviceID mais en principe, 40 convient
@interface AppDelegate : NSObject <NSApplicationDelegate>
@end
@implementation AppDelegate
- (void) applicationDidFinishLaunching:(NSNotification *) aNotification
{
Float32 volume;
UInt32 channel;
UInt32 propertyDataSize;
AudioObjectPropertyAddress audioPropertyAddress;
UInt32 numberOfChannels;
AudioObjectID outputDeviceID = 40;
OSStatus err = noErr;
audioPropertyAddress.mSelector = kAudioDevicePropertyVolumeScalar;
audioPropertyAddress.mScope = kAudioObjectPropertyScopeOutput;
// ###### CHANNEL EST INCREMENTE MEME SI ERR <> NOERR ######
for(channel = 1; err == noErr; channel++)
{
propertyDataSize = sizeof volume;
audioPropertyAddress.mElement = channel;
err = AudioObjectGetPropertyData(outputDeviceID,
&audioPropertyAddress, 0, NULL,
&propertyDataSize, &volume);
}
numberOfChannels = channel - 1; // ###### ERREUR ########
}
@end
In article
<Patrick.Stadelmann-798ECC.14064013112013@news.individual.net>,
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
> In article <OKSdnUdblo4i_B7PnZ2dnUVZ7q-dnZ2d@giganews.com>,
> Lionel Mychkine <mychkine@nowhere.invalid> wrote:
>
> > C'est exactement ce que ne fait pas Xcode. Ou plutôt le compilateur
> > C/C++ dans un environnement Cocoa de Xcode pour parler comme tu
> > comprends.
>
> Donne un vrai programme qu'on peux compiler ainsi que le résultat si tu
> veux qu'on considère cette possibilité...
#import <Cocoa/Cocoa.h>
#import <CoreAudio/AudioHardware.h>
// la librairie CoreAudio.framework doit se trouver dans le projet
// il faut renseigner outputDeviceID mais en principe, 40 convient
@interface AppDelegate : NSObject <NSApplicationDelegate>
@end
@implementation AppDelegate
- (void) applicationDidFinishLaunching:(NSNotification *) aNotification
{
Float32 volume;
UInt32 channel;
UInt32 propertyDataSize;
AudioObjectPropertyAddress audioPropertyAddress;
UInt32 numberOfChannels;
AudioObjectID outputDeviceID = 40;
OSStatus err = noErr;
audioPropertyAddress.mSelector = kAudioDevicePropertyVolumeScalar;
audioPropertyAddress.mScope = kAudioObjectPropertyScopeOutput;
// ###### CHANNEL EST INCREMENTE MEME SI ERR <> NOERR ######
for(channel = 1; err == noErr; channel++)
{
propertyDataSize = sizeof volume;
audioPropertyAddress.mElement = channel;
err = AudioObjectGetPropertyData(outputDeviceID,
&audioPropertyAddress, 0, NULL,
&propertyDataSize, &volume);
}
numberOfChannels = channel - 1; // ###### ERREUR ########
}
@end
In article
,
Patrick Stadelmann wrote:
> In article ,
> Lionel Mychkine wrote:
>
> > C'est exactement ce que ne fait pas Xcode. Ou plutôt le compilateur
> > C/C++ dans un environnement Cocoa de Xcode pour parler comme tu
> > comprends.
>
> Donne un vrai programme qu'on peux compiler ainsi que le résultat si tu
> veux qu'on considère cette possibilité...
#import <Cocoa/Cocoa.h>
#import <CoreAudio/AudioHardware.h>
// la librairie CoreAudio.framework doit se trouver dans le projet
// il faut renseigner outputDeviceID mais en principe, 40 convient
@interface AppDelegate : NSObject <NSApplicationDelegate>
@end
@implementation AppDelegate
- (void) applicationDidFinishLaunching:(NSNotification *) aNotification
{
Float32 volume;
UInt32 channel;
UInt32 propertyDataSize;
AudioObjectPropertyAddress audioPropertyAddress;
UInt32 numberOfChannels;
AudioObjectID outputDeviceID = 40;
OSStatus err = noErr;
audioPropertyAddress.mSelector = kAudioDevicePropertyVolumeScalar;
audioPropertyAddress.mScope = kAudioObjectPropertyScopeOutput;
// ###### CHANNEL EST INCREMENTE MEME SI ERR <> NOERR ######
for(channel = 1; err == noErr; channel++)
{
propertyDataSize = sizeof volume;
audioPropertyAddress.mElement = channel;
err = AudioObjectGetPropertyData(outputDeviceID,
&audioPropertyAddress, 0, NULL,
&propertyDataSize, &volume);
}
numberOfChannels = channel - 1; // ###### ERREUR ########
}
@end
Dans ton cas, la boucle est au moins exécutée une fois puisque le
premier test est vrai, donc channel vaut au minimum 2 en sortie. Il faut
donc soustraire 2 pour obtenir le nombre d'appel à AudioObjectGet... qui
n'a pas généré d'erreur.
Dans ton cas, la boucle est au moins exécutée une fois puisque le
premier test est vrai, donc channel vaut au minimum 2 en sortie. Il faut
donc soustraire 2 pour obtenir le nombre d'appel à AudioObjectGet... qui
n'a pas généré d'erreur.
Dans ton cas, la boucle est au moins exécutée une fois puisque le
premier test est vrai, donc channel vaut au minimum 2 en sortie. Il faut
donc soustraire 2 pour obtenir le nombre d'appel à AudioObjectGet... qui
n'a pas généré d'erreur.
In article
,
Patrick Stadelmann wrote:
> Dans ton cas, la boucle est au moins exécutée une fois puisque le
> premier test est vrai, donc channel vaut au minimum 2 en sortie. Il faut
> donc soustraire 2 pour obtenir le nombre d'appel à AudioObjectGet... qui
> n'a pas généré d'erreur.
A un moment, et c'est le but recherché, la fonction
AudioObjectGetPropertyData va renvoyer une erreur. La variable channel a
une certaine valeur à ce moment là, valeur dont il ne faut pas tenir
compte puisqu'elle est à l'origine de l'erreur. Et puisque le test
err == noErr sera faux, channel n'a aucune raison d'être incrémenté. En
sortie de for on considère que le nombre de canaux est égal à
channel - 1.
Je maintiens que la gestion du for() sous Xcode 5 ne respecte pas les
standards du C et du C++.
In article
<Patrick.Stadelmann-E85C08.16132713112013@news.individual.net>,
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
> Dans ton cas, la boucle est au moins exécutée une fois puisque le
> premier test est vrai, donc channel vaut au minimum 2 en sortie. Il faut
> donc soustraire 2 pour obtenir le nombre d'appel à AudioObjectGet... qui
> n'a pas généré d'erreur.
A un moment, et c'est le but recherché, la fonction
AudioObjectGetPropertyData va renvoyer une erreur. La variable channel a
une certaine valeur à ce moment là, valeur dont il ne faut pas tenir
compte puisqu'elle est à l'origine de l'erreur. Et puisque le test
err == noErr sera faux, channel n'a aucune raison d'être incrémenté. En
sortie de for on considère que le nombre de canaux est égal à
channel - 1.
Je maintiens que la gestion du for() sous Xcode 5 ne respecte pas les
standards du C et du C++.
In article
,
Patrick Stadelmann wrote:
> Dans ton cas, la boucle est au moins exécutée une fois puisque le
> premier test est vrai, donc channel vaut au minimum 2 en sortie. Il faut
> donc soustraire 2 pour obtenir le nombre d'appel à AudioObjectGet... qui
> n'a pas généré d'erreur.
A un moment, et c'est le but recherché, la fonction
AudioObjectGetPropertyData va renvoyer une erreur. La variable channel a
une certaine valeur à ce moment là, valeur dont il ne faut pas tenir
compte puisqu'elle est à l'origine de l'erreur. Et puisque le test
err == noErr sera faux, channel n'a aucune raison d'être incrémenté. En
sortie de for on considère que le nombre de canaux est égal à
channel - 1.
Je maintiens que la gestion du for() sous Xcode 5 ne respecte pas les
standards du C et du C++.
A un moment, et c'est le but recherché, la fonction
AudioObjectGetPropertyData va renvoyer une erreur. La variable channel a
une certaine valeur à ce moment là, valeur dont il ne faut pas tenir
compte puisqu'elle est à l'origine de l'erreur. Et puisque le test
err == noErr sera faux, channel n'a aucune raison d'être incrémenté. En
sortie de for on considère que le nombre de canaux est égal à
channel - 1.
Par exemple, sur un système monophonique l'erreur sera déclenchée sur
channel = 2 et il faut donc soustraire 1 parce que si, comme toi, on
soustrait 2, on obtiendra un nombre de canaux égal à zéro ce qui est
tout simplement faux.
Le problème est que lorsque la variable err est renseignée et donc <>
noErr, channel est quand-même incrémenté et c'est bien ça qui n'est pas
normal.
A un moment, et c'est le but recherché, la fonction
AudioObjectGetPropertyData va renvoyer une erreur. La variable channel a
une certaine valeur à ce moment là, valeur dont il ne faut pas tenir
compte puisqu'elle est à l'origine de l'erreur. Et puisque le test
err == noErr sera faux, channel n'a aucune raison d'être incrémenté. En
sortie de for on considère que le nombre de canaux est égal à
channel - 1.
Par exemple, sur un système monophonique l'erreur sera déclenchée sur
channel = 2 et il faut donc soustraire 1 parce que si, comme toi, on
soustrait 2, on obtiendra un nombre de canaux égal à zéro ce qui est
tout simplement faux.
Le problème est que lorsque la variable err est renseignée et donc <>
noErr, channel est quand-même incrémenté et c'est bien ça qui n'est pas
normal.
A un moment, et c'est le but recherché, la fonction
AudioObjectGetPropertyData va renvoyer une erreur. La variable channel a
une certaine valeur à ce moment là, valeur dont il ne faut pas tenir
compte puisqu'elle est à l'origine de l'erreur. Et puisque le test
err == noErr sera faux, channel n'a aucune raison d'être incrémenté. En
sortie de for on considère que le nombre de canaux est égal à
channel - 1.
Par exemple, sur un système monophonique l'erreur sera déclenchée sur
channel = 2 et il faut donc soustraire 1 parce que si, comme toi, on
soustrait 2, on obtiendra un nombre de canaux égal à zéro ce qui est
tout simplement faux.
Le problème est que lorsque la variable err est renseignée et donc <>
noErr, channel est quand-même incrémenté et c'est bien ça qui n'est pas
normal.