I've heard that some compilers reserve the '_' starting a symbol for system
variables/symbols. I can not find this documented anywhere (so far). I've
used an '_' at the end of member variables (ie. Uint16 bar_; ) to
distinquish private fields, but this does not stand out as much as if the
'_' were at the begginning of the name as in the following class
declaration.
class Foo {
private:
Uint16 _baz;
Uint32 _bar;
public:
....
};
22  2211 
BRIAN VICKERY wrote: I've heard that some compilers reserve the '_' starting a symbol for
system variables/symbols.
The C++ language reserves some of them, like e.g. those that begin with
an underscore followed by an uppercase letter and those that contain
two consecutive underscores.
I can not find this documented anywhere (so far).
I've used an '_' at the end of member variables (ie. Uint16 bar_; )
to distinquish private fields,
That's quite common practise.
but this does not stand out as much as if the '_' were at the
begginning of the name as in the following class
declaration.
class Foo {
private:
Uint16 _baz;
Uint32 _bar;
public:
....
};
I think those shold be fine.
"BRIAN VICKERY" <is*********@verizon.net> wrote in message
news:LK**************@nwrddc02.gnilink.net... I've heard that some compilers reserve the '_' starting a symbol for
system variables/symbols. I can not find this documented anywhere (so far).
I've used an '_' at the end of member variables (ie. Uint16 bar_; ) to
distinquish private fields, but this does not stand out as much as if the
'_' were at the begginning of the name as in the following class
declaration.
class Foo {
private:
Uint16 _baz;
Uint32 _bar;
public:
....
};
From 17.4.3.1.2 of the Standard:
Certain sets of names and function signatures are always reserved to the
implementation:
- Each name that contains a double underscore (_ _) or begins with an
underscore followed by an uppercase letter (2.11) is reserved to the
implementation for any use.
- Each name that begins with an underscore is reserved to the implementation
for use as a name in the global namespace.
BRIAN VICKERY wrote in news:LK**************@nwrddc02.gnilink.net: I've heard that some compilers reserve the '_' starting a symbol for
system variables/symbols. I can not find this documented anywhere (so
far). I've used an '_' at the end of member variables (ie. Uint16
bar_; ) to distinquish private fields, but this does not stand out as
much as if the '_' were at the begginning of the name as in the
following class declaration.
class Foo {
private:
Uint16 _baz;
Uint32 _bar;
public:
....
};
Am identifier with single leading undersore is reserved for the
implementation if:
Its followed by an uppercase letter (anywhere).
Its followed by another underscore (anywhere), in fact *all* identifiers
that *contain* 2 or more *consecutive* underscores are reserved.
Its declared at global namespace scope, i.e its a macro or it
*isn't* declared within an namespace, class, struct or union or it
*isn't* a paramiter name or a local variable name.
Also IIUC it shouldn't be a declared extern "C".
So you usage for member identifiers is Ok.
Nobody really likes it though and most people can't be bothered to
remember all the rules, so they will probably complain that your using a
reserved identifier anyway, so I'd suggest m_baz or some such thing.
Rob.
-- http://www.victim-prime.dsl.pipex.com/
"Rob Williscroft" <rt*@freenet.REMOVE.co.uk> wrote in message:
Am identifier with single leading undersore is reserved for the
implementation if:
Its followed by an uppercase letter (anywhere).
Its followed by another underscore (anywhere), in fact *all*
identifiers that *contain* 2 or more *consecutive* underscores are reserved.
Its declared at global namespace scope, i.e its a macro or it
*isn't* declared within an namespace, class, struct or union or it
*isn't* a paramiter name or a local variable name.
Also IIUC it shouldn't be a declared extern "C".
So you usage for member identifiers is Ok.
Nobody really likes it though and most people can't be bothered to
remember all the rules, so they will probably complain that your
using a reserved identifier anyway, so I'd suggest m_baz or some such thing.
I'm familiar with the language from the standard, but it sounds a bit
ambiguous:
"reserved to the implementation for use as a name in the global
namespace"
could mean:
(i) reserved to the implementation; also, must be global,
or
(ii) reserved to the implementation if used in the global namespace
Why do you prefer (i)? Is this known to be the correct interpretation?
Jonathan
"Jonathan Turkanis" <te******@kangaroologic.com> wrote in message
news:bv************@ID-216073.news.uni-berlin.de...
Why do you prefer (i)? Is this known to be the correct
interpretation?
I meant (ii) here.
Jonathan
On Fri, 30 Jan 2004 16:29:49 +0100, Rolf Magnus <ra******@t-online.de>
wrote: BRIAN VICKERY wrote:
I've heard that some compilers reserve the '_' starting a symbol for
system variables/symbols.
Check 17.4.3.1.2 of the C++ standard first.
Stroustrup says "never" ... (see p. 81 of the 3rd edition, "The C++
Programming Language).
--
Bob Hairgrove No**********@Home.com
Jonathan Turkanis wrote in news:bv************@ID-216073.news.uni-
berlin.de: So you usage for member identifiers is Ok.
Nobody really likes it though and most people can't be bothered to
remember all the rules, so they will probably complain that your using a reserved identifier anyway, so I'd suggest m_baz or some such thing.
I'm familiar with the language from the standard, but it sounds a bit
ambiguous:
"reserved to the implementation for use as a name in the global
namespace"
could mean:
(i) reserved to the implementation; also, must be global,
This would be the same as reserved ... everywhere. The "must be global"
would be unnessasery additional info'.
or
(ii) reserved to the implementation if used in the global namespace
[from elswhere]
I meant (ii) here.
Why do you prefer (i)? Is this known to be the correct interpretation?
Sorry but (i) doesn't make any sense to me.
_lowecase identifiers are used to support the C standard library and
meny C++ implementation's just use the C library as-is, and most
allow you to link with C code that will link in the C library.
C++ needs another set of identifiers _Uppercase so it doesn't stomp
on the _lowecase ones and also the double underscore rule for name
mangaling. This allows a C++ compiler to compile via a C compiler
as meny still do.
Rob.
-- http://www.victim-prime.dsl.pipex.com/
Rob Williscroft <rt*@freenet.REMOVE.co.uk> wrote in message news:<Xn*********************************@195.129. 110.201>... BRIAN VICKERY wrote in news:LK**************@nwrddc02.gnilink.net:
I've heard that some compilers reserve the '_' starting a symbol for
system variables/symbols. I can not find this documented anywhere (so
far). I've used an '_' at the end of member variables (ie. Uint16
bar_; ) to distinquish private fields, but this does not stand out as
much as if the '_' were at the begginning of the name as in the
following class declaration.
class Foo {
private:
Uint16 _baz;
Uint32 _bar;
public:
....
};
Am identifier with single leading undersore is reserved for the
implementation if:
Its followed by an uppercase letter (anywhere).
From memory, Microsoft C++ used to (not sure now), define a special
keyword called "_except". If you tried to use that name, even as a
member variable of a class, the compiler would spit the dummy.
Thus, regardless of what the standard for C++ says, don't necessarily
expect Microsoft to adhere to it. :-)
Graham Dumpleton wrote in news:dc6f5c99.0401301624.544b4b2
@posting.google.com:
From memory, Microsoft C++ used to (not sure now), define a special
keyword called "_except". If you tried to use that name, even as a
member variable of a class, the compiler would spit the dummy.
yes also things like _far, _near, _try all of which are extemsion
keywords
Thus, regardless of what the standard for C++ says, don't necessarily
expect Microsoft to adhere to it. :-)
Well did MS introduce the keyword before or after the standard
came out (1998). Certainly I've noticed that all of the extension
keywords I've come accross reciently have had 2 leading underscores
__declspec.
Rob.
-- http://www.victim-prime.dsl.pipex.com/
"Rob Williscroft" <rt*@freenet.REMOVE.co.uk> wrote in message:
"reserved to the implementation for use as a name in the
global namespace"
could mean:
(i) reserved to the implementation; also, must be global,
This would be the same as reserved ... everywhere. The "must be
global" would be unnessasery additional info'.
Unnecessary info for users, maybe, but not for implementers.
Maybe you mean it would be an 'unneccessary additional restriction'?
Are you sure that C++ doesn't have any of these? ;-)
Jonathan
Jonathan Turkanis wrote in news:bv************@ID-216073.news.uni-
berlin.de:
"Rob Williscroft" <rt*@freenet.REMOVE.co.uk> wrote in message:
>
> "reserved to the implementation for use as a name in the global > namespace"
>
> could mean:
>
> (i) reserved to the implementation; also, must be global,
>
This would be the same as reserved ... everywhere. The "must be
global" would be unnessasery additional info'.
Unnecessary info for users, maybe, but not for implementers.
How would it help an implementer, the standard tells implementors
what they have to implement not *how*, "must be global" could
only be related to how.
Maybe you mean it would be an 'unneccessary additional restriction'?
It isn't a restriction, its saying that _lowercase *must* be a global
namespace identifier, i.e. its telling an implementor some details
about *how* to implement.
[snip]
Rob.
-- http://www.victim-prime.dsl.pipex.com/
"Rob Williscroft" <rt*@freenet.REMOVE.co.uk> wrote in message: This would be the same as reserved ... everywhere. The "must be global" would be unnessasery additional info'.
Unnecessary info for users, maybe, but not for implementers.
How would it help an implementer, the standard tells implementors
what they have to implement not *how*, "must be global" could
only be related to how.
Did I say 'helpful'? I said 'necessary': if (i) is correct, then it
constitutes necessary information for implementers.
Maybe you mean it would be an 'unneccessary additional
restriction'?
It isn't a restriction, its saying that _lowercase *must* be a
global namespace identifier, i.e. its telling an implementor some details
about *how* to implement.
What distinction are you trying to make? I don't see how a requirement
that such identifiers -- if used by an implementation -- must be
global, isn't a restriction. True, the standard tries to give
implementers broad discretion, yet it also puts quite a few
constraints on implementations.
Maybe you should try to find some evidence in favor of your
interpretation. I never said it was wrong, by the way. I just asked
you to support it.
Jonathan
Jonathan Turkanis wrote in news:bv************@ID-216073.news.uni-
berlin.de:
"Rob Williscroft" <rt*@freenet.REMOVE.co.uk> wrote in message:
>> This would be the same as reserved ... everywhere. The "must be
> global"
>> would be unnessasery additional info'.
>>
>
> Unnecessary info for users, maybe, but not for implementers.
How would it help an implementer, the standard tells implementors
what they have to implement not *how*, "must be global" could
only be related to how.
Did I say 'helpful'? I said 'necessary': if (i) is correct, then it
constitutes necessary information for implementers.
My apologees, I should have consulted the standard when you first said:
I'm familiar with the language from the standard, but it sounds a bit
ambiguous:
"reserved to the implementation for use as a name in the global
namespace"
could mean:
(i) reserved to the implementation; also, must be global,
This section (17.4.3) is describing constraints on programmes.
However your rewording with hindsight appears to be as if your reading
the section as constraining implementation's.
>
> Maybe you mean it would be an 'unneccessary additional restriction'?
It isn't a restriction, its saying that _lowercase *must* be a
global namespace identifier, i.e. its telling an implementor some details
about *how* to implement.
What distinction are you trying to make? I don't see how a requirement
that such identifiers -- if used by an implementation -- must be
global, isn't a restriction.
Indeed, implementors arn't allowed to use _lowercase identifiers
other than in the global namespace (or in std).
I interpreted you originaly as suggesting *nobody* could use such
identifiers other than in the global namespace and only
implementors can use them there.
True, the standard tries to give
implementers broad discretion, yet it also puts quite a few
constraints on implementations.
Maybe you should try to find some evidence in favor of your
interpretation. I never said it was wrong, by the way. I just asked
you to support it.
There is only one peice evidence available, I presume since you
quoted from it, that you've read it. It helps if you read the all
of "17.4.3 Constraints on programs", here's the relevent quote:
17.4.3.1.2 Global names
1 Certain sets of names and function signatures are always reserved to
the implementation:
— Each name that contains a double underscore (_ _) or begins with
an underscore followed by an uppercase letter (2.11) is reserved
to the implementation for any use.
— Each name that begins with an underscore is reserved to the
implementation for use as a name in the global namespace.165)
165) Such names are also reserved in namespace ::std (17.4.3.1).
The second bullet is clearly saying that implementation's can use
identifiers such as _lowercase at in the global namespace so
a conforming programme may not.
The note 165) tells us we can't put such identifiers in namespace std
but we can't do that anyway.
Rob.
-- http://www.victim-prime.dsl.pipex.com/
On Fri, 30 Jan 2004 13:10:19 -0700, "Jonathan Turkanis"
<te******@kangaroologic.com> wrote in comp.lang.c++:
"Rob Williscroft" <rt*@freenet.REMOVE.co.uk> wrote in message:
Am identifier with single leading undersore is reserved for the
implementation if:
Its followed by an uppercase letter (anywhere).
Its followed by another underscore (anywhere), in fact *all*
identifiers that *contain* 2 or more *consecutive* underscores are reserved.
Its declared at global namespace scope, i.e its a macro or it
*isn't* declared within an namespace, class, struct or union or it
*isn't* a paramiter name or a local variable name.
Also IIUC it shouldn't be a declared extern "C".
So you usage for member identifiers is Ok.
Nobody really likes it though and most people can't be bothered to
remember all the rules, so they will probably complain that your
using a reserved identifier anyway, so I'd suggest m_baz or some such thing.
I'm familiar with the language from the standard, but it sounds a bit
ambiguous:
"reserved to the implementation for use as a name in the global
namespace"
could mean:
(i) reserved to the implementation; also, must be global,
or
(ii) reserved to the implementation if used in the global namespace
Why do you prefer (i)? Is this known to be the correct interpretation?
Jonathan
Your confusion, and this wording, is caused by C++ adopting a C
restriction but applying new terminology.
C reserves the leading underscore+upper case, and leading double
underscore (but not embedded double underscore, that's a C++ addition)
in all contexts.
Then it reserves leading underscore+lower case at file scope. The
problem with C++ duplicating this restriction is... there is NO SUCH
THING as "file scope" in the standard C++. The phrase literally does
not exist in the standard.
What is file scope in C has been expanded into the concept of
namespace scope in C++. Things that are defined or declared outside
of a function in C++ are either inside a (named or anonymous)
namespace, concepts that do not exist in C, or they are at the top
level, what C calls "file scope" and C++ calls the global namespace.
Note that it makes no difference whether the "file scope"/"global
namespace" identifiers have external linkage or not, even with
internal linkage they can conflict with things the compiler defines in
its header files, or even pre-defined helper functions that it calls
directly.
Don't confuse the global namespace in C++ with the concept of global
variables. It really means pretty much exactly the same thing as file
scope in C.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
"Jack Klein" <ja*******@spamcop.net> wrote in message
news:lh********************************@4ax.com... On Fri, 30 Jan 2004 13:10:19 -0700, "Jonathan Turkanis"
<te******@kangaroologic.com> wrote in comp.lang.c++:
"Rob Williscroft" <rt*@freenet.REMOVE.co.uk> wrote in message:
Am identifier with single leading undersore is reserved for the
implementation if:
Its followed by an uppercase letter (anywhere).
Its followed by another underscore (anywhere), in fact *all* identifiers that *contain* 2 or more *consecutive* underscores are reserved.
Its declared at global namespace scope, i.e its a macro or it
*isn't* declared within an namespace, class, struct or union or
it *isn't* a paramiter name or a local variable name.
Also IIUC it shouldn't be a declared extern "C".
So you usage for member identifiers is Ok.
Nobody really likes it though and most people can't be bothered
to remember all the rules, so they will probably complain that your
using a reserved identifier anyway, so I'd suggest m_baz or some such
thing.
I'm familiar with the language from the standard, but it sounds a
bit ambiguous:
"reserved to the implementation for use as a name in the
global namespace"
could mean:
(i) reserved to the implementation; also, must be global,
or
(ii) reserved to the implementation if used in the global
namespace
Why do you prefer (i)? Is this known to be the correct
interpretation?
Jonathan
Your confusion, and this wording, is caused by C++ adopting a C
restriction but applying new terminology.
C reserves the leading underscore+upper case, and leading double
underscore (but not embedded double underscore, that's a C++
addition) in all contexts.
Then it reserves leading underscore+lower case at file scope. The
problem with C++ duplicating this restriction is... there is NO SUCH
THING as "file scope" in the standard C++. The phrase literally
does not exist in the standard.
What is file scope in C has been expanded into the concept of
namespace scope in C++. Things that are defined or declared outside
of a function in C++ are either inside a (named or anonymous)
namespace, concepts that do not exist in C, or they are at the top
level, what C calls "file scope" and C++ calls the global namespace.
Note that it makes no difference whether the "file scope"/"global
namespace" identifiers have external linkage or not, even with
internal linkage they can conflict with things the compiler defines
in its header files, or even pre-defined helper functions that it calls
directly.
Don't confuse the global namespace in C++ with the concept of global
variables. It really means pretty much exactly the same thing as
file scope in C.
Thank you for your historical perspective. I don't believe I was
confusing global variables with the global namespace. I was using
'global' as shorthand for 'in the global namespace' because we were
focusing on a different issue. The question was whether member
variable names with single leading underscores not followed by an
uppercase letter are legal in user code.
Looking at the second item of 17.4.3.1.2/1,
Each name that begins with an underscore is reserved to the
implementation for use as a name in the global namespace,
I noted that there was a plausible reading according to which such a
use would be prohibited. Namely, it could be held to say that such
names are reserved for use by the implementation -- so that they
cannot be used at all in user code -- and *additionally* the
implementation must use such names, if it choses to use them at all,
in the global namespace.
Jonathan
> Certain sets of names and function signatures are always reserved to the implementation:
- Each name that contains a double underscore (_ _) or begins with an
underscore followed by an uppercase letter (2.11) is reserved to the
implementation for any use.
- Each name that begins with an underscore is reserved to the implementation
for use as a name in the global namespace.
Can someone explain to me *what* or *who* is or qualifies as an
implementation? For example, SGI's STL library contains _Uppercase and
__doubleunder names. Why does the SGI company or programmer in SGI
have the right to be an *implementation* but I do not? Why are not my
libraries just as *implementation* worthy as any other programmer.
Also, can someone explain to me by what mechanisms (besides a macro)
the use of these underscores names within a class or namespace I
create can conflict with a C++ implementation.
Keith H Duggar wrote: Can someone explain to me *what* or *who* is or qualifies as an
implementation? For example, SGI's STL library contains _Uppercase and
__doubleunder names. Why does the SGI company or programmer in SGI
have the right to be an *implementation* but I do not? Why are not my
libraries just as *implementation* worthy as any other programmer.
What does the S in STL stand for?
Also, can someone explain to me by what mechanisms (besides a macro)
the use of these underscores names within a class or namespace I
create can conflict with a C++ implementation.
typedef int __doubleunder;
std::vector<int> yo;
Pretend that std::vector depended on a variable called __doubleunder, but
your typedef made its usage look like a type.
(I'm stuck on this one too - just don't do it!)
--
Phlip http://www.xpsd.org/cgi-bin/wiki?Tes...UserInterfaces
Keith H Duggar wrote: Certain sets of names and function signatures are always reserved to
the implementation:
- Each name that contains a double underscore (_ _) or begins with an
underscore followed by an uppercase letter (2.11) is reserved to the
implementation for any use.
- Each name that begins with an underscore is reserved to the
implementation for use as a name in the global namespace.
Can someone explain to me *what* or *who* is or qualifies as an
implementation?
Anything that implements the (or part of the) C++ standard.
For example, SGI's STL library contains _Uppercase and
__doubleunder names. Why does the SGI company or programmer in SGI
have the right to be an *implementation* but I do not?
Probably because they are implementing the standard library (which is
part of C++ and thus part of an implementation of it) and you don't.
Why are not my libraries just as *implementation* worthy as any other
programmer.
They are not implementations of the standard.
Also, can someone explain to me by what mechanisms (besides a macro)
the use of these underscores names within a class or namespace I
create can conflict with a C++ implementation.
One example is the name mangling. In C++, several functions with the
same name can exist in different namespaces or as members of different
classes or just as overloads with different number and types of
arguments. So there is typically a scheme that translates those
function names to internal names that contain all that information so
the linker can find the functions. Those internal names are often such
reserved names, so if you use those, they can conflict with other code.
Rolf Magnus wrote: Also, can someone explain to me by what mechanisms (besides a macro)
the use of these underscores names within a class or namespace I
create can conflict with a C++ implementation.
One example is the name mangling. In C++, several functions with the
same name can exist in different namespaces or as members of different
classes or just as overloads with different number and types of
arguments. So there is typically a scheme that translates those
function names to internal names that contain all that information so
the linker can find the functions. Those internal names are often such
reserved names, so if you use those, they can conflict with other
code.
Just for a practical example of this. You can't produce an executable
from the following code with e.g. g++ 3.3.2:
int _Z4testv;
void test() {};
int main()
{
test();
}
The reason is that the internal mangled name for the function test is
_Z4testv, so there is a naming conflict with the global variable. The
error message looks like this:
/tmp/cckaLQYy.s: Assembler messages:
/tmp/cckaLQYy.s:13: Error: symbol `_Z4testv' is already defined
Thanks for the example Rolf. int _Z4testv;
void test() {};
int main()
{
test();
}
The reason is that the internal mangled name for the function test is
_Z4testv, so there is a naming conflict with the global variable. The
error message looks like this:
/tmp/cckaLQYy.s: Assembler messages:
/tmp/cckaLQYy.s:13: Error: symbol `_Z4testv' is already defined
Personally, I never pollute the global namespace with underscore
names. I was mainly thinking of continuing to use __xyz to indicate
member variables. I tried using m_xyz for a while but the code didn't
look nearly as nice as with __xyz. Also, I tried using xyz_ as many
suggest but again __xyz was much easier on my eyes and I take it that
xyz__ would also be reserved (double underscore) is that correct?
However, your example seems to indicate that I could run into name
mangling problems even within a class namespace.
Thank you again, I will have to look into this more.
PS. What convention to you use for member variable names?
On 31 Jan 2004 18:31:56 -0800, du****@mit.edu (Keith H Duggar) wrote: Personally, I never pollute the global namespace with underscore
names. I was mainly thinking of continuing to use __xyz to indicate
member variables. I tried using m_xyz for a while but the code didn't
look nearly as nice as with __xyz. Also, I tried using xyz_ as many
suggest but again __xyz was much easier on my eyes and I take it that
xyz__ would also be reserved (double underscore) is that correct?
However, your example seems to indicate that I could run into name
mangling problems even within a class namespace.
Don't forget that although your member names are within a namespace,
the ones we have been talking about often are not, so there is still
plenty of opportunity for clashes.
--
Bob Hairgrove No**********@Home.com
Keith H Duggar wrote: Thanks for the example Rolf.
int _Z4testv;
void test() {};
int main()
{
test();
}
The reason is that the internal mangled name for the function test is
_Z4testv, so there is a naming conflict with the global variable. The
error message looks like this:
/tmp/cckaLQYy.s: Assembler messages:
/tmp/cckaLQYy.s:13: Error: symbol `_Z4testv' is already defined
Personally, I never pollute the global namespace with underscore
names. I was mainly thinking of continuing to use __xyz to indicate
member variables. I tried using m_xyz for a while but the code didn't
look nearly as nice as with __xyz. Also, I tried using xyz_ as many
suggest but again __xyz was much easier on my eyes and I take it that
xyz__ would also be reserved (double underscore) is that correct?
Yes. Everything that contains two consecutive underscores, so both __xyz
and xyz__ are reserved.
However, your example seems to indicate that I could run into name
mangling problems even within a class namespace.
I'm not sure how likely it is that you can get into problems with your
above naming scheme, but my example at least shows that there might be
things you haven't been considering. I don't know of other internal
uses of reserved identifiers than standard library macros and name
mangling, but that doesn't mean there are none, and it also will depend
on the compiler. The simplest way to be sure still is by just not using
reserved identifiers.
Thank you again, I will have to look into this more.
PS. What convention to you use for member variable names?
xyz_ This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Chris S. |
last post by:
Is there a purpose for using trailing and leading double underscores for
built-in method names? My impression was that underscores are supposed
to imply some sort of pseudo-privatization, but would...
|
by: Andy Glew |
last post by:
I am in search of any rigourous,
scientific, academic or industrial studies
comparing naming conventions in
C++ or similar languages such as
Ada:
Specifically, are names formed with...
|
by: Kari Laitinen |
last post by:
During the past 15 years I have been writing computer
programs with so-called natural names, which means
that the names (identifiers, symbols) in progarms
are constructed of several natural words....
|
by: Ares Lagae |
last post by:
When adopting the coding style of the standard C++ library, you often run
into naming problems because class names are lower case, and member
functions do not have get/set prefixes.
For example:...
|
by: meyousikmann |
last post by:
Given these two (incomplete but representative) classes in two seperate
header files:
Class1.h
class Class1
{
public:
Class(const char CharValue, const int IntValue1, const int IntValue2);...
| | |
by: James Harris |
last post by:
Before I embark on a new long-term project I'd appreciate your advice on how to split up
long names. I would like to keep the standards for command names the same as that for
variable names....
|
by: Peter Kirk |
last post by:
Hi
I am looking at some C# code, and can see in some of the classes there are
instance variables whose names start with an underscore, for example:
private string _projectId;
Is there a...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
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: 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: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
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...
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
|
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence...
| |
