|
That's a PRETTY good point. But at least you agree with me to set the define for each .cpp file and not all of them in one header file. One modification and BAM, at least 15 minutes to compile for one little change!
|
|
|
|
|
The converse point is also true. A typo in one place can lead to almost unfindable bugs.
Cheers,
Peter
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
I would go the second way, mostly for not polluting the global namespace. Also you should set the types to static const float, assuming they are not supposed to change during runtime. I like to name constants in all upper case, but that's just a personal preferrence.
The good thing about pessimism is, that you are always either right or pleasently surprised.
|
|
|
|
|
Message Closed
modified 17-Feb-15 4:55am.
|
|
|
|
|
Message Closed
modified 17-Feb-15 5:04am.
|
|
|
|
|
Don't use #define for constants. If you want to keep things tidy, use a dedicated namespace, and a separate definition.
namespace constants
{
extern const float pi;
}
#include "constants.h"
namespace constants
{
const float pi = 3.141593;
}
...
int i = 5;
float angle = constants::pi * i;
int* pi = &i;
...
This also demonstrates why using #defines will break your code
|
|
|
|
|
When using namespaces (in Visual Studio) you get the added benefit of IntelliSense helping you out.
I personally think it is overkill to put the definition in a cpp file as long as we are talking about simple constants.
Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
SoMad wrote: I personally think it is overkill to put the definition in a cpp file as long as we are talking about simple constants.
I'd second that... plus if someone is tracking a value of a constant, it's getting hidden away a bit (unnecessarily) by putting it in a source file.
|
|
|
|
|
The benefit of having the definition in a cpp file is more apparent when the constant isn't a universal physical/mathematical one, but one that could conceivably change during development. Should this happen, there's no need to recompile all files that refer to it, which would be required if the definition is in the header file.
|
|
|
|
|
Although using the statics is a way to keep your namespace cleaner, the macros are used A LOT... and they allow your code to be compiled as C OR C++. If you use class/namespace enclosed statics you're pretty much C++ compliant only.
|
|
|
|
|
In my experience, very few projects have a requirement that they be compilable as both C and C++. Many libraries must be accessible from both C and C++, but a well-designed C-style interface will take care of that.
For example, instead of:
#define MAX_SIZE 42
write a function,
int GetMaxSize()
which returns the value of the constant from your library.
This has the further advantage of decoupling the library from the constant - any changes to MAX_SIZE won't require the client's code to be recompiled (possibly relinked, if we are talking about a static library).
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
Well in my experience, there's A LOT of code that exists from the C days, so you still see macros a lot. And yes, most people use C style interfaces for libraries.
Important to note that the original question specified C AND C++. I was simply pointing out that namespace/class enclosed statics aren't C compliant.
Quote: I was wondering what is the best way to set constanta in C/C++
|
|
|
|
|
Perhaps I expressed myself poorly.
I was referring to the case where the library is written in C / C++ / <whatever>, but must be callable from a C-style interface (e.g. the MS-Windows SDK). I believe that it is poor practice to expose #defined constants in the library's header file, because it introduces tight coupling between the caller and the library - any change in the constant requires recompiling the client.
Having said that, I recognize that standard C practice is to define such constants, so that code such as below may be written:
header.h:
#define MAX_SIZE 42
...
code.c:
#include "header.h"
void foo(void)
{
int array[MAX_SIZE];
...
}
C99 and later support variable-length arrays. As developers transition to compilers supporting this feature, I suspect that the need for such constants may decrease.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
You still can use the const keyword. In case of constants being used for array bounds, you could instead declare an enum (since const ints in C cannot be used for array bounds, unfortunately):
enum {
MAX_SIZE = 42
};
const struct {
double pi;
int size;
} constants = { 3.14, 42 };
double arr1[MAX_SIZE]; double arr2[constants.size];
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
1. Your solution, while removing the problems with #define, still has the problem of tight coupling of the caller's code with the library.
2. In C99 or later, variable-length arrays are perfectly legal, but IIRC - not as static variables.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
1. you are free to move the initialization of the struct elsewhere within your library code. I just did it like this to have a compact example. (and I didn't want to bother finding out how and where to place qualifiers)
2. True, but that didn't help in the example code I gave. The compiler still issued an error (VS 2010, compiled "as C"). The reason I pointed out the alternative (defining an enum) is that sometimes you do want a symbol to be recognized and treated as constant (e. g. to prevent typos such as if (MAX_SIZE=10)), but at the same time you want to use these same constants in situations that specifically require constants, such as in array definitions. C unfortunately doesn't allow you to use a const int as array bounds, in spite of VLAs! But it does let you use enum values.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
You still could use a const struct in ANSI C like this:
const extern struct {
double pi;
int answer;
} constants = { 3.14, 42 };
const is part of ANSI C, as are struct initializer lists. So no need to resort to #defines and cluttering the global namespace. Of course, you could also just define each individual constant as const, or you could skip the const and the initialization if you prefer initializing the values in a .c file.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
I usually use consts or better still enums.
The main problem I came to find with defines is namespace pollution - in many places you'd have constants named MAX_FILENAME_LENGHT and it is possible, depending on the use you make of this constant, that they differ. Using a define you'd probably end up with a redefine or nasty bug somewhere, using constants and enums you can keep them enclosed in a class, which is often what is needed.
Enums are still better as they build another inner namespace, further reducing namespace pollution. For the same reason I often enclose the data members that makes sense only when taken together into inner structs inside the definition of the classes, this way you have an easy way to pass an entire block of information between functions and can reuse common names (as Length used with different meanings in different places, avoiding C-like horrors like DataPadLenght, DataPayloadLenght, DataReservedAllocationLength, FileNameLenght...).
Geek code v 3.12
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- r++>+++ y+++*
Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Hello there. I am trying to insert record in mysql database using c++ ("sakila.actor"). Problem is, if I hardcode my table name (using double quotes) then it works fine, otherwise it gives runtime exception. Here is the code
void MyAppDlg::InsertRecord(CString sHostWithPort, CString sUser, CString sPassword, CString sTableName, int nActorId, CString sFirstName, CString sLastName, CString sLastUpdate)
{
sql::Driver *driver;
sql::Connection *con;
sql::PreparedStatement *pstmt;
driver = get_driver_instance();
con = driver->connect(sHostWithPort.GetString(), sUser.GetString(), sPassword.GetString());
con->setSchema(sTableName.GetBuffer());
}
Two questions:
1- driver->connect(...); function is compiling with no problem but why con->setSchema(....); is producing exception.
2- How do I get all database names and table names using prepared statements.
Thanks for any pointer.
|
|
|
|
|
OK, but you haven't said what the error is.
Try:
con->setSchema(sTableName);
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
|
Hi,
The Documentation for RegisterClass, or RegisterClassEX, states that the Name of the class to be registered must be a name previously registered with either of these API Calls. (by way of Atom, or Text String).
https://msdn.microsoft.com/en-us/library/windows/desktop/ms633577(v=vs.85).aspx[^]
I Understood always that Window Class Names should be Unique, and, that to register a Window Class by a Previously registered name, would (or should) constitute an Error. I am not sure whether Windowclass Registration is per process or System Wide. I Suspect the former, but, the Documentation does not say.
Do I totally misunderstand the system, or, is the MS Documentation Wrong on this point.
Bram van Kampen
|
|
|
|
|
The page that you link to is the page for the WNDCLASSEX structure, not the RegisterClass or RegisterClassEx function.
Therefore when it refers to a class name that has been previously registered, it does so only to describe what the structure should contain.
It's not telling you to register a class name more than once.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
No, the Link is Correct. The offending piece of Text is in the explanation about "lpszClassName" in the WNDCLASS(EX) structure. A Good bit down the File!
Regards,
Bram van Kampen
|
|
|
|
|
lpszClassName
Type: LPCTSTR
A pointer to a null-terminated string or is an atom. If this parameter is an atom, it must be a class atom created by a previous call to the RegisterClass or RegisterClassEx function. The atom must be in the low-order word of lpszClassName; the high-order word must be zero.
If lpszClassName is a string, it specifies the window class name. The class name can be any name registered with RegisterClass or RegisterClassEx, or any of the predefined control-class names.
The maximum length for lpszClassName is 256. If lpszClassName is greater than the maximum length, the RegisterClassEx function will fail.
As I read this, the lpszClassName member must be either an atom or a string. Only if it is an atom must the atom be one created by a previous call to the RegisterClass() or RegisterClassEx() APIs.
In my experience, most programmers use a string for this member.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
