You could probably use a macro.
#include <stdio.h>
#include <stdlib.h>
#define CARDINAL(array) \
(((void*)array != (void*)&array) ? 0 : sizeof(array) / sizeof(array[0]))
Type: Posts; User: Sir Galahad
You could probably use a macro.
#include <stdio.h>
#include <stdlib.h>
#define CARDINAL(array) \
(((void*)array != (void*)&array) ? 0 : sizeof(array) / sizeof(array[0]))
It is the Norse language from whence these words arise (as do the vast number of words used everyday in English). In that context to be aligned with the "godspirit" in one's actions was the whole...
Side note: the two words actually come from the same root. To be a "good man" for example used to mean a "godly man". Of course the meanings have obviously diverged quite a bit over the millennia....
Implicit conversions from char to int are just part of the language. C++ inherited that from C where functions such as getchar() return an int (not a char). As such the best thing to do is avoid...
Yes, of course, that is in fact the preferable way to go. Much better than calling it manually, which is obviously prone to too few/many invocations.
To be clear, the word "theory" in maths implies something which has been *proven*. Something which has neither been proven nor disproven is known as a "conjecture".
As far as mathematics is...
It just means the struct member 'pString' should be declared const (hence the complaint, "converting a string constant to 'char*'").
And yet you get tripped up on such trivial errors which have been so plainly spelled out to you in the compiler's output?
Look, I started learning C++ maybe one or two years after I started...
Should a "spade" be called by any other name? If a compiler can convert the code "*ptr++" to "*ptr; ++ptr;", it stands to reason it could do the same for objects which override those operators. As it...
Doubtful. I got better results playing around with Markov chains!
Well I couldn't get the same pointer-like behavior when defining a class and compiling under gcc/g++. (Rather unpleasant surprise, to say the least.) Which is why I decided to go with a different...
Yes, clearly total nonsense....
Well it is bound to happen sometimes. Thanks for the input, by the way. It really did help push me towards a more satisfactory solution. The "iterant functor" paradigm is very simple, which is great...
Well sure, at the assembly level perhaps. But the expression "int n = *p++;" effectively dereferences the pointer before incrementing. In other words, it acts like "int n = *p; ++p;". On the other...
Ah, right! I was definitely using the wrong terminology there. What I am talking about is the fact that *object++ behaves differently from *pointer++. If you print debugging statements from a class...
Another fun example:
template <typename Container>
class fixed_reverse_iterant_t {
typedef typename Container::reverse_iterator iter_t;
typedef typename Container::value_type value_t;
...
I think I've found an even better approach! We can "have our cake and eat it too" if we simply toss out the assumption that an iterant could ever even be in "equilibrium". Instead, the primary rule...
Ok, I finally get what you are saying now. The dereference happens on the copy, not the original object. But that was also (kind of!) my point. With a pointer, an expression like "*ptr++" is...
Why not just use 'NO_TOKEN' in place of the literal '0'? Otherwise, you could redefine 'token_code' to be a plain 'int'. As the compiler message say, you can also use the -fpermissive flag to cause...
Thanks for the pointers. This is what I was referring to. I'll start by defining a class with explicit methods just to demonstrate the basic idea.
template <typename Container>
class...
Only problem with that is it seems to violate the "separation of concerns" principal. The code I am working is meant to be used as a library, so I would really rather not design it specifically...
I am trying to implement a reasonable iterator interface, but the STL has me a little confused. Let's say we have defined the following (somewhat nonsensical) function:
#include <cstdlib>
...
Those strcpy calls are buffer-overflows just waiting to happen. Save yourself the headache and use strncpy.
The program should not segfault when called without arguments either. Print a "usage"...
It's an artifact. Your format string is all wrong. For doubles, use %g. The precision parameter goes between the % symbol and the format specifier.
You do know that the pow function does...
FWIW, unless you intend to modify it at some point, the `program_name` buffer isn't even necessary. The pointer returned by `basename` can be stored in a variable. No allocation needed.