I have defined some variables using #define preprocessor instruction.
And then later I checked whether I had defined a variable. Sometimes
even though a variable have been defined, #if !defined(var) construct
is returning true. I am using gcc3.0.1 on SunOS8. I would appreciate
if any body can tell me whether this is a bug or I am doing something
wrong.
tia,
Srinivas
20  25358 
srinivas reddy <sr*************@yahoo.com> wrote in message
news:ff**************************@posting.google.c om... I have defined some variables using #define preprocessor instruction.
And then later I checked whether I had defined a variable. Sometimes
even though a variable have been defined, #if !defined(var) construct
is returning true. I am using gcc3.0.1 on SunOS8. I would appreciate
if any body can tell me whether this is a bug or I am doing something
wrong.
I would have said that this surely is a bug, but I wouldn't put anything
past the C++ preprocessor.
Incomprehensibly, #if var1 == var2 simply converts var1 and var2 to "0"
(yes, "0", even though the preprocessor is a _text_ replacer) if it hasn't
come across definitions of them (something like Basic assuming that any
undefined variable it comes across must be an int; and I thought C++ got rid
of implicit this and implicit that because they are thought unsafe). 0 == 0
is true, of course.
I can only assume that those with influence who wish to see the end of the
preprocessor altogether are trying to accelerate its death by ensuring that
it works as badly as possible.
DW
David White wrote:
I can only assume that those with influence who wish to see the end of the
preprocessor altogether are trying to accelerate its death by ensuring that
it works as badly as possible.
Then it must be that the folks who originally came up with the idea of
the preprocessor thirty years ago tried to accelerate its death, because
replacing undefined symbols with 0 in arithmetic expressions has been
the rule since the beginning.
--
Pete Becker
Dinkumware, Ltd. ( http://www.dinkumware.com)
"srinivas reddy" <sr*************@yahoo.com> wrote in message
news:ff**************************@posting.google.c om... I have defined some variables using #define preprocessor instruction.
And then later I checked whether I had defined a variable. Sometimes
even though a variable have been defined, #if !defined(var) construct
is returning true. I am using gcc3.0.1 on SunOS8. I would appreciate
if any body can tell me whether this is a bug or I am doing something
wrong.
tia,
Srinivas
Perhaps you have defined the variable, but not in the compilation unit in
which your #if statement is written? In other words, if you #define the
variable in unit1.h, and make your check in unit2.cpp, then you need to add
#include "unit1.h" in unit2.cpp before checking if the variable exists.
(I usually put my #define's in a precompiled header if they're going to be
widely used in my projects. But that's with CodeWarrior...I don't know how
to use gcc so it may be different.)
Just a thought...
-Howard
David White wrote: srinivas reddy <sr*************@yahoo.com> wrote in message
news:ff**************************@posting.google.c om... I have defined some variables using #define preprocessor instruction.
And then later I checked whether I had defined a variable. Sometimes
even though a variable have been defined, #if !defined(var) construct
is returning true. I am using gcc3.0.1 on SunOS8. I would appreciate
if any body can tell me whether this is a bug or I am doing something
wrong.
I would have said that this surely is a bug, but I wouldn't put
anything past the C++ preprocessor.
Incomprehensibly, #if var1 == var2 simply converts var1 and var2 to
"0" (yes, "0", even though the preprocessor is a _text_ replacer) if
it hasn't come across definitions of them (something like Basic
assuming that any undefined variable it comes across must be an int;
and I thought C++ got rid of implicit this and implicit that because
they are thought unsafe). 0 == 0 is true, of course.
I can only assume that those with influence who wish to see the end
of the preprocessor altogether are trying to accelerate its death by
ensuring that it works as badly as possible.
It isn't the preprocessor that is bad--even the conversion to 0 that you mention
here. It is *misuse* of the preprocessor that is bad. The preprocessor is
actually a critical component of the C and C++ compilation process. It makes it
possible to write code that works on multiple platforms, as well as write code
that works on various current compilers (as opposed to the idealistic perfect
C++ implementation).
Regards,
Paul Mensonides
Pete Becker <pe********@acm.org> wrote in message
news:3F***************@acm.org... David White wrote:
I can only assume that those with influence who wish to see the end of
the preprocessor altogether are trying to accelerate its death by ensuring
that it works as badly as possible.
Then it must be that the folks who originally came up with the idea of
the preprocessor thirty years ago tried to accelerate its death, because
replacing undefined symbols with 0 in arithmetic expressions has been
the rule since the beginning.
I accept that, but why hasn't it been fixed along with everything else?
Implicit int, matching of function argument types, insistence that function
definitions be present, etc. have been some of the many improvements to C++
since C. I don't think anyone disputes that these are all good things. The
more prgrammer errors you can detect at compile time the better. Why leave
something there that's so obviously bad?
DW
David White wrote:
Pete Becker <pe********@acm.org> wrote in message
news:3F***************@acm.org... David White wrote:
I can only assume that those with influence who wish to see the end of the preprocessor altogether are trying to accelerate its death by ensuring that it works as badly as possible.
Then it must be that the folks who originally came up with the idea of
the preprocessor thirty years ago tried to accelerate its death, because
replacing undefined symbols with 0 in arithmetic expressions has been
the rule since the beginning.
I accept that, but why hasn't it been fixed along with everything else?
Because it's not broken.
Implicit int, matching of function argument types, insistence that function
definitions be present, etc. have been some of the many improvements to C++
since C. I don't think anyone disputes that these are all good things. The
more prgrammer errors you can detect at compile time the better. Why leave
something there that's so obviously bad?
The fact that you don't understand it doesn't make it bad.
--
Pete Becker
Dinkumware, Ltd. ( http://www.dinkumware.com)
Pete Becker <pe********@acm.org> wrote in message
news:3F***************@acm.org... David White wrote:
I accept that, but why hasn't it been fixed along with everything else?
Because it's not broken.
Implicit int, matching of function argument types, insistence that
function definitions be present, etc. have been some of the many improvements to
C++ since C. I don't think anyone disputes that these are all good things.
The more prgrammer errors you can detect at compile time the better. Why
leave something there that's so obviously bad?
The fact that you don't understand it doesn't make it bad.
What have I said that indicates that I don't understand it? Did I describe
it wrongly?
I'm interested to know: do you think that assuming that an undefined
preprocessor symbol is "0" is a good thing, or something that wouldn't be
improved by a compiler error saying that the symbol is undefined? If so, why
not extend the principle to assuming that any symbol in a C++ expression is
an 'int'?
myVariable = 7;
// myVariable not defined anywhere: so it must be an 'int'.
Okay?
myVariable = myFunction(3, "abc", 2.65);
// myFunction not defined anywhere: so it must be int myFunction(int, char
*, double);
Okay?
DW
David White wrote:
Pete Becker <pe********@acm.org> wrote in message
news:3F***************@acm.org... David White wrote:
I accept that, but why hasn't it been fixed along with everything else?
Because it's not broken.
Implicit int, matching of function argument types, insistence that function definitions be present, etc. have been some of the many improvements to C++ since C. I don't think anyone disputes that these are all good things. The more prgrammer errors you can detect at compile time the better. Why leave something there that's so obviously bad?
The fact that you don't understand it doesn't make it bad.
What have I said that indicates that I don't understand it? Did I describe
it wrongly?
You said earlier that the preprocessor is "a _text_ replacer."
I'm interested to know: do you think that assuming that an undefined
preprocessor symbol is "0" is a good thing, or something that wouldn't be
improved by a compiler error saying that the symbol is undefined?
No. It would make some things much more verbose, and would only help
beginners.
If so, why
not extend the principle to assuming that any symbol in a C++ expression is
an 'int'?
Non sequitur.
--
Pete Becker
Dinkumware, Ltd. ( http://www.dinkumware.com)
Pete Becker <pe********@acm.org> wrote in message
news:3F***************@acm.org... David White wrote:
What have I said that indicates that I don't understand it? Did I
describe it wrongly?
You said earlier that the preprocessor is "a _text_ replacer."
Yes, and that statement was _clearly_ made in the context of #define and
#if.
#define X Y
Doesn't this replace the symbol 'X' found anywhere in the source code with
the text 'Y'?
Also: "Because they rearrange the program text before the compiler proper
sees it, macros are..." - The C++ Programming Language (3rd ed.), page 160.
Given that macros _do_ replace text, why should an undefined symbol become
'0' rather than ''?
I'm interested to know: do you think that assuming that an undefined
preprocessor symbol is "0" is a good thing, or something that wouldn't
be improved by a compiler error saying that the symbol is undefined?
No. It would make some things much more verbose,
Such as?
And is the increased verbosity worse than no message from the compiler when
a symbol is used without having been defined?
Speaking of verbosity, the way to ensure that preprocessor symbols are not
silently converted to 0 is:
#if !defined(REACTOR_TYPE) || !defined(REACTOR_NEW_MODEL)
#error REACTOR_TYPE or REACTOR_NEW_MODEL not defined
#endif
Apart from the fact that if one remembers to do this then one would have
ensured that the symbols were defined, is it not verbose to place this in
every source file in which these symbols are used?
and would only help
beginners.
I see. So, only beginners would ever forget to ensure that both of these are
#defined somewhere?
#if REACTOR_TYPE == REACTOR_NEW_MODEL If so, why
not extend the principle to assuming that any symbol in a C++ expression
is an 'int'?
Non sequitur.
void f(int reactorType)
{
// No definition of REACTOR_NEW_MODEL given
if(reactorType == REACTOR_NEW_MODEL)
{
// ...
}
}
Why should this be an error, but not the preprocessor version?
DW
"Paul Mensonides" <le******@comcast.net> wrote in message
news:ZoHOa.12065$H17.3639@sccrnsc02... David White wrote: Incomprehensibly, #if var1 == var2 simply converts var1 and var2 to
"0" (yes, "0", even though the preprocessor is a _text_ replacer) if
it hasn't come across definitions of them (something like Basic
assuming that any undefined variable it comes across must be an int;
and I thought C++ got rid of implicit this and implicit that because
they are thought unsafe). 0 == 0 is true, of course.
I can only assume that those with influence who wish to see the end
of the preprocessor altogether are trying to accelerate its death by
ensuring that it works as badly as possible.
It isn't the preprocessor that is bad--even the conversion to 0 that you
mention here.
Well, I think the conversion to 0 _is_ bad. Given that you can use #ifdef or
#if defined() for things such as:
#ifdef _cplusplus
how can the implicit conversion to 0 of an undefined symbol be a good thing?
Why is it better than issuing an error?
It is *misuse* of the preprocessor that is bad. The preprocessor is
actually a critical component of the C and C++ compilation process.
I agree. That's why I'd like it to work _safely_.
It makes it
possible to write code that works on multiple platforms, as well as write
code that works on various current compilers (as opposed to the idealistic
perfect C++ implementation).
Yes, but I want to do it safely. I do not want the outcome of an #if to be
one of these two possibilities:
1. The result of the expression of previously defined symbols.
2. A programmer's mistake in forgetting to include the defined symbols.
This is inherently unsafe. The possibility of no. 2 is the reason that C++
insists on all function definitions being present and that there is a
suitable match for every argument. Does not one other person here think that
this is a problem?
DW
David White wrote:
[...] This is inherently unsafe. The possibility of no. 2 is the reason that C++
insists on all function definitions being present and that there is a
suitable match for every argument. Does not one other person here think that
this is a problem? http://groups.google.com/groups?thre...01%40hsv3.UUCP
(Subject: Using a define that hasn't been #defined)
regards,
alexander.
--
"Status quo, you know, that is Latin for ``the mess we're in.''"
-- Ronald Reagan
"David White" <no@email.provided> wrote in message news:Kb******************@nasal.pacific.net.au...
Doesn't this replace the symbol 'X' found anywhere in the source code with
the text 'Y'?
No, it doesn't. Pete is right, you seem not to understand the preprocessor.
Given that macros _do_ replace text, why should an undefined symbol become
'0' rather than ''?
They do not replace text, they replace tokens.
Ron Natalie wrote: "David White" <no@email.provided> wrote in message
news:Kb******************@nasal.pacific.net.au...
Doesn't this replace the symbol 'X' found anywhere in the source
code with
the text 'Y'?
No, it doesn't. Pete is right, you seem not to understand the
preprocessor.
Given that macros _do_ replace text, why should an undefined symbol
become '0' rather than ''?
They do not replace text, they replace tokens.
Even more specifically, they replace macro invocations:
#define X() Y
X // X
Regards,
Paul Mensonides
David White wrote: It isn't the preprocessor that is bad--even the conversion to 0 that
you mention here.
Well, I think the conversion to 0 _is_ bad. Given that you can use
#ifdef or #if defined() for things such as:
#ifdef _cplusplus
how can the implicit conversion to 0 of an undefined symbol be a good
thing? Why is it better than issuing an error?
Because it is a "reasonable default." Reasonable defaults make code less
verbose. This happens with templates also:
template<class T> void f(int reactorType)
{
// No definition of REACTOR_NEW_MODEL given
if(reactorType == T::REACTOR_NEW_MODEL)
{
// ...
}
}
The compiler will pass this with no problem even though it still parses the
expression, etc.. The reasonable default here is "non-type". The point being
that the language has to deal with unknown names and make assumptions about what
they mean in various places.
That is just the way it is. You know what the behavior is, so writing "safe"
code is up to you to use the language in safe ways. C and C++ certainly don't
protect you from unsafe usage many areas, why should they do that here?
If you changed the behavior to an error, how would you do this in a non-verbose
way:
# if !__cplusplus && __STDC_VERSION__ >= 199901L
You'd have to do something really annoying because you cannot use any
conditional test that uses the name outside the defined operator. You can't
even do this:
#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
...because that constitutes an error under your model if __STDC_VERSION__ is not
defined. You'd have to separate the test for definition from the conditional
expression:
# if !defined __cplusplus && defined __STDC_VERSION__
# if __STDC_VERSION__ >= 199901L
# // 1
# else
# // 2
# endif
# else
# // 2
# endif
....and that is a code doubler for point 2.
If you changed the behavior to expanding to nil instead of 0, you'd have silent
changes in other ways. You'd also end of seeing a lot of "hacks" like this:
# if !(__cplusplus+0) && (__STDC_VERSION__+0) >= 199901L
In order to simulate the common scenario that we already have built into the
preprocessor.
It is *misuse* of the preprocessor that is bad. The preprocessor is
actually a critical component of the C and C++ compilation process.
I agree. That's why I'd like it to work _safely_.
It does work safely if used correctly. I said it before already: The #if and
#elif directives are not designed to implicitly perform the kind of verification
that you want--because that kind of verification (if done by default) is
downright annoying.
Further, the root problem here is 1) forgetting to include a file, or 2) design
error. Assuming that it is just a case of forgetting to include the file that
defines the symbols, there a many ways in which a program can silently change
meaning in C++ by not including a file (e.g. silently choosing different
function overloads or different template specializations).
It makes it
possible to write code that works on multiple platforms, as well as
write code that works on various current compilers (as opposed to
the idealistic perfect C++ implementation).
Yes, but I want to do it safely. I do not want the outcome of an #if
to be one of these two possibilities:
1. The result of the expression of previously defined symbols.
It is totally ill-conceived. You can do what you want reasonably, but you
cannot do what it already does reasonably. You already have the option to do
what you want:
#if defined(REACTOR_TYPE) \
&& defined(REACTOR_NEW_MODEL) \
&& REACTOR_TYPE == REACTOR_NEW_MODEL
You can't go back the other way.
2. A programmer's mistake in forgetting to include the defined
symbols.
This is inherently unsafe.
No it isn't _inherently_ unsafe. It can be unsafe in certain contexts, and you
have to be aware of that when you write code. However, the alternative is much
worse. You can simulate what you want with a small amount of code; you cannot
simulate what it already does with a small amount of code.
The possibility of no. 2 is the reason
that C++ insists on all function definitions being present and that
there is a suitable match for every argument. Does not one other
person here think that this is a problem?
C++ does not insist on all function declarations that you've defined in a group
of files be present at each overload resolution--which can cause silent
differences in overload resolution, etc..
Regards,
Paul Mensonides
Ron Natalie <ro*@sensor.com> wrote in message
news:3f***********************@news.newshosting.co m...
"David White" <no@email.provided> wrote in message
news:Kb******************@nasal.pacific.net.au...
Doesn't this replace the symbol 'X' found anywhere in the source code
with the text 'Y'?
No, it doesn't. Pete is right, you seem not to understand the
preprocessor.
I do. I just didn't use precise enough language in this pedantic place. I am
aware that the 'X' in 'MAX' would not be replaced by 'Y'. Given that macros _do_ replace text, why should an undefined symbol
become '0' rather than ''?
They do not replace text, they replace tokens.
Okay. Why you didn't correct Stroustrup's loose language as well? :)
Getting off the track.
DW
Alexander Terekhov <te******@web.de> wrote in message
news:3F***************@web.de...
David White wrote:
[...] This is inherently unsafe. The possibility of no. 2 is the reason that
C++ insists on all function definitions being present and that there is a
suitable match for every argument. Does not one other person here think
that this is a problem?
http://groups.google.com/groups?thre...01%40hsv3.UUCP
(Subject: Using a define that hasn't been #defined)
Thanks, Alexander. I am not alone after all.
DW
On Thu, 10 Jul 2003 13:35:24 +1000, David White <no@email.provided> wrote: Sam Holden <sh*****@flexal.cs.usyd.edu.au> wrote in message
news:slrnbgpln5.fft.sh*****@flexal.cs.usyd.edu.au. .. On Thu, 10 Jul 2003 12:31:36 +1000,
David White <no@email.provided> wrote: >
Using #if in anything but a header file is madness in my opinion. I
guess using it to give some platform specific optimisation might be OK,
but I'd try and find a way to move the #if itself into a header.
You can't always use C++ itself. How, for example, do you make a declaration
depend on whether you are compiling a NORMAL or LITE version of the
software? Suppose you also have EXTRA_LITE and PREMIUM versions. And suppose
the following constant has a different value for each one:
#if MODEL == EXTRA_LITE
const int NrWheels = 2;
#elif MODEL == LITE
const int NrWheels = 4;
// etcetera
By moving those values into the header file, since they are obviously
in some way dependant on the MODEL and hence having them in one place
rather than scattered throughout many source files is nice (even
if they are in fact only used once - it unifies the location of all
such data).
#define MODEL_NRWHEELS 2
or
#define MODEL_NRWHEELS 4
which get set by the appropriate model specific header.
and then
const int NrWheels = MODEL_NRWHEELS;
Has the disadvantage that when the code is changed, sometimes
the model header files will have to be modified as well. But
has the advantage that when adding another model you will
hopefully just have to add the appropriate header file set
a the appropriate define and all the code now works - as opposed
to finding all those #ifs and adding #elif MODEL == NEW_MODEL.
Of course in practice things never work out and you have
to modify a bit of the code.
But I'd personally be using the C++ type system rather than
#defines to tell things apart. I've been bitten by inconsistant
settings in #defines in different compile runs or files in C
too many times.
--
Sam Holden
David White wrote: It's not going to change. No matter how much you complain about it.
Yes, I realized that very quickly. I can't even get anyone here to
agree that anything needs to be fixed.
It isn't that I don't agree that the kind of danger you refer to doesn't exist.
Instead, its that I don't consider it a big enough problem to prohibit the
utility of the implicit conversion to 0. IMO, the benefits outweigh the costs.
Regards,
Paul Mensonides
"David White" <no@email.provided> wrote in message news:%G*************@nasal.pacific.net.au... Ron Natalie <ro*@sensor.com> wrote in message
I do. I just didn't use precise enough language in this pedantic place. I am
aware that the 'X' in 'MAX' would not be replaced by 'Y'.
There's much more to it than that.
They do not replace text, they replace tokens.
Okay. Why you didn't correct Stroustrup's loose language as well? :)
Because Stroustrup wasn't wrong. You were. The only reference to text
on the page you reference says "the preprocessor rearranges the text ..."
He doesn't say anything specific about macro replacment
Getting off the track.
You're the one driving us there.
"Ron Natalie" <ro*@sensor.com> wrote in message
news:3f***********************@news.newshosting.co m...
"David White" <no@email.provided> wrote in message
news:%G*************@nasal.pacific.net.au... Ron Natalie <ro*@sensor.com> wrote in message
I do. I just didn't use precise enough language in this pedantic place.
I am aware that the 'X' in 'MAX' would not be replaced by 'Y'.
There's much more to it than that.
No kidding? I called the preprocessor a "text" replacer while discussing its
replacement of an undefined symbol with "0" instead of with nothing at all.
This was a correct statement. A token is composed of text. Therefore if you
replace a token you are replacing text. Then I gave an example in which my
language was not precise enough and was corrected. I accepted the correction
to the more precise term 'token' and added an example. And now I get,
completely unnecessarily, but perhaps predictably, "There's much more to it
than that". Really? What a revelation. I've just looked up "The C++
Programming Language", and (my God!), the preprocessor also has #include,
which lets you include a whole other file! And it even has macros with
parameters! And a macro can even use another macro! And there are other
things as well! Getting off the track.
You're the one driving us there.
No, you are, with this ridiculous waste of time.
DW This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Bryan Parkoff |
last post by:
"#define" can only be inside the global scope before main() function.
"#if" can be tested after "#define" is executed. The problem is that
"#define" can't be inside main() function. I do not wish...
|
by: Andreas |
last post by:
Hi!
I'm using an IplImage library from camellia.sourceforge.net, and the
testbench calls a file only containing code like the one below. In
cam_morphomaths_code.c the real computation is made,...
|
by: theotyflos |
last post by:
Hi all,
I have the following:
/*--- SNIP ---*/
typedef struct Argument_s
{
char *address;
int type;
|
by: pozz |
last post by:
Hi all,
I have the below #defines
#define NUMBER1 30
#define NUMBER2 50
#define SUM (NUMBER1+NUMBER2)
#define STRING1 "Byte: \x30"
#define STRING2 "Byte: \x50"...
|
by: BQ |
last post by:
Hello
Is there a way to declare 'FUNCT' via a define so that if its parameter x, a constant, is
greater than 35, it returns 56, if not, 20.
I would like that at compile time, not at run time.
...
|
by: niraj.tiwari |
last post by:
What is meaning of the following define:-
#define x(argl...) x1(##argl)
|
by: David T. Ashley |
last post by:
Where is the best place to define TRUE and FALSE?
Are they in any of the standard include files, ever?
Do any standards apply?
What I've traditionally done is something like:
#ifndef...
|
by: anirbid.banerjee |
last post by:
Hi,
I need to write a macro which would have a lot many conditional
#ifdef ... #endif blocks in it.
#define _xx_macro (x) {
... \
... \ /* some code (); */
#ifdef _SOME_STMT \
... \
... \
|
by: anon.asdf |
last post by:
Hello!
In the following code-snippet, is it possible to initialize each
element of arr, with STRUCT_INIT?
struct mystruct {
int a;
char b;
};
|
by: badc0de |
last post by:
Hello..
a header file of one of my project has macro definitions like this
(for example)
#define PART_A_SORT_1_LABEL_STRING1 100
#define PART_A_SORT_1_LABEL_STRING2 200
#define...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |
