Posts by Banfa

This Val & 0xFF is an unecessary operator since you already know at this point that 0 < Val < 0xFF

@L7Sqr - Doh! you're right of course.

@L7Sqr & @tinstaafl - Both your solutions use C++ but this is the C forum and in fact the original solution is valid on in C (it uses an implied return type).

I am beginning to suspect the original solution may well be the best C solution.

I assume you are missing a 0 between the first ? :.

You could use the modulous (%) operator rather than a second test. Whether this is better rather depends on the processor it is running on though

Clip(int Val)
{
    return ((curr < 0) ? 0 : (curr %= 256));
}

No there is only ever a single destructor

~a()
{
}

It never takes any parameters. This makes sense, the reason that you have parameterised constructors is that you may wish to initialise your object in several different ways, but when you destroy your object there is no need for any further data, you go from the current state of the object to no-object so the object already knows everything it needs in order to delete itself.

parameter row is unused.

The function returns a pointer to an object, arr, that is on the stack and that will therefore be deleted once the function exits which is almost certainly likely to produce undefined behaviour.

Line 10 and 12 are equivilent to return arr;

You need to install Java on your machine.

Also are you sure your path should contain C:\MinGW\i686-pc-mingw32\lib and not C:\MinGW\i686-pc-mingw32\bin

changerSignal is not a member of QLabel, it is a member of FenPrincipale but at line 173 you try this

QObject::connect(labelAfficherStatsHero[1], SIGNAL(changerSignal()), signalStatsHero , SLOT(heroNomChanger()));

labelAfficherStatsHero[1] is a QLabel and therefore only supports the signals defined for QLabel, that is

void QLabel linkActivated (const QString  &link )
void QLabel linkHovered (const QString  &link )

// Inherited from QFrame
void QWidget    customContextMenuRequested (const QPoint  &pos )

// Inherited from QObject
void QObject    destroyed (QObject *obj=0 )

At line 14 you still have a and b declared as int but you scanf them as floats at line 16 which will produce the strange results you are seeing.

The problem is not to do with you code it is to do with prototype, consider this program

#include <iostream>

 class Test
 {
 public:
    const char *text() const throw()
    {
      return "Const test";
    }

    const char *text() throw()
    {
      return "Non-Const test";
    }
 };

int main()
{ 
  Test t;
  const Test* pct = &t;

  std::cout << t.text() << " : " << pct->text() << std::endl;

  return 0;
}

This compiles, but there are 2 functions call text in the class test. The difference is that one is const and one isn't. The reason this compiles is that the cv_qualifier of the function (i.e. const) is part of the things consider when looking for function overloads, so Test::text has 2 overloads.

This is what is happening when you remove the const from the what in your exception class. Instead of providing an override of virtual std::exception::what() const, your method no longer matches and is an overloaded function instead of an override of the virtual function. Then when you call what through std::exception& it calls the base class method not your method because your method no-longer overrides it.

Given this header

// header.h
#include <string>

namespace company
{
  namespace module
  {
    class ProjectConstants
    {
    public:
      static const int CONSTANT1;
      static const std::string CONSTANT2;
    };
  }
}

and this source file

// header.cpp
#include "header.h"

using company::module::ProjectConstants;


const int ProjectConstants::CONSTANT1 = 10;
const std::string ProjectConstants::CONSTANT2("Hello World");

Are ProjectConstants::CONSTANT1 and ProjectConstants::CONSTANT2 declared in the global namespace or not?

I am asking this because our project follows a coding standard that requires that the global namespace is not polluted and I thought that this wouldn't do that, however when using static analysis, FlexeLint, it says that the code at lines 7 and 8 of the cpp file place the symbols in the global namespace.

When I compile this I get warning: ISO C++ forbids zero-size array 'a' although I am using the 2003 standard.

You have declared a zero size array in the class therefore the class has no data and is zero-sized. Since the array has members it appears that the compiler (mine at least) does not automatically make sure it's size is non-zero, which is normally required to ensure all objects have a different memory address which is a requirement of the standard.

Declare an array of these and the all have the same address, this appears to be non-conforming, however since you have done something that is forbidden I guess that is not unexpected, I'm slightly surprised that it isn't an error.

Lucky (or unlucky depending on your point of view) happenstance that 14.375 is exactly representable as both a float and a double. Don't rely on this.

Basically a floating point number is an approximation and if nothing else is specified then floating point constants have the type double.

This means that in the line float f2=14.385; the compile converted the double constant 14.385 to a float and then assigned it to f2; then in if(f2==14.385), since the compiler always converts to the largest type present for comparisons it converted the floating point value of f2 to a double, in the process of all that converting the compiler took an approximation that was not quite equal to the original 14.385 so the == returned false.

On my system it happened on float f2=14.385;

f2 ended with a value of 14.38500023 when converted back to a double.

The 'left to right' order you refer to is the operators associativity. This is nothing to do with what order the operands are evaluated in but is to do with the order multiple operators of the same preceedence are evaluated in, for example the left-to-right associativity of + and -, which have the same preceedence, means that a - b + c is evaluated as (a - b) + c and not a - (b + c) which would result in a completely different answer.

As Moschops points out the compiler is free to evaluate the 2 operands of any operator in any order it chooses with the exception of || and && which have to evaluate the left hand operand first to achieve short-circuit evaluation.

When I say order of evaluation is unimportant I mean that order of evaluation is not important once you have resolved all the preceedence and associativity rules if they are then multiple things you could do first.

So in a * b + c * d were you could evaluate a * b first or c * d first it is not important which of these 2 sub-expressions are evaluated first and the compiler is free to choose. Then once it has evaluated both sub-expressions it can evaluate the +.

However in an expression like a + b * c once you have resolved the preceedence then it is clear that b * c must be evaluated before the +.

So yes as you say order of evaluation only comes into the picture once all the parenthases have been (conceptually) assigned. Once that is done it is order of evaluation is either self-evident as in a + b * c or it does matter as in a * b + c * d or in the case of || and && there are further rules that have to be followed, that is left hand expression is always evaluated before the right hand expression and the right hand expression is then not evaluated if the value of the left hand expression gives the result of the operator.

There are 2 things describing how/what order operators in an expression are evaluated; preceddence and associativity.

It is important to remeber that associativity is only ever applied to a series of operators of the same preceedence, that is in the line a = b + c; the associativity of the 2 operators, right-to-left for = and left-to-right for + do not come into play at all because = and + have different precences.

Preceedence only affects how the operands bind to the operators not the order in which the operators are evaluated; in A || B && C preceedence indicates that B and C will bind to && but the || operator is evaluated first.

Associativity defines the order in which operators are evaluated (and therefore sometimes how the operands bind to them) in a + b + c + has left-to-right associativity and therefore the left hand + is evauluated first and b binds to the first plus so it is equivilent to (a + b) + c.

A couple of operators, notably && and || have special rules (shortcut evauluation) which have to be taken into account when the order of evaulation is determined.

However that asside I believe there is no constraint on the compiler to evaulate in a specific order as long as it has satisfied the rules of precedence and associativty and the operators used; i.e. in a * b + c * d * has higher preceedence than + so this is evaulated as …

Opps made another mistake, this

store_other=store_other+(double(thick[i])/(cond[i] * area[i]));

should not work in a C compiler because double(thick[i]) is not a cast it is instantiating a double object through its constructor which takes an initialiser which is C++. A true C version of this line is

store_other=store_other+(((double)thick[i])/(cond[i] * area[i]));

which actualy does a cast to double.

When p is int* p it is a pointer to an int, taking sizeof(p) gives the size of a pointer (4).

When p is int (*p)[5] it is a pointer to an array of 5 ints, taking sizeof(p) still returns the size of a pointer (4). Look at my code again, I did not use sizeof(p) in my final example. I used sizeof(*p) i.e. not the size of the pointer p but the size of what p is pointing to.

If p is int* p the sizeof(*p) is still 4 because p is pointing to an int so this is sizeof(int). However if p is int (*p)[5] then p is pointing to an array of 5 ints and sizeof(*p) is the size of an array of 5 ints or 20 because that is what p is pointing to.

In summary in my code p was always a pointer and taking sizeof(p) always returned the size of a pointer. What I changed is what p was pointing to, an array of ints rather than a single int and then I got the size of what p was pointing to not the size of p sizeof(*p).

As moschops said in a function

void function(int* p)
{
}

That has been passed some arbitary array then there is not way to know what the size of that array is from the passed parameter. Standard practice is to pass the array size in another function parameter

void function2(int* p, int size)
{
}

If you are not allowed to do that but you are using fixed size arrays then you could

Use a constant to define your array size

#define SIZE (5)

int array[SIZE];

void function3(int* p)
{
  int ix;

  for(ix=0; ix<SIZE; ix++)
  {
    p[ix] = ix;
  }
}

Or declare the function to take a point to an array of the right size

void function4(int (*p)[5])
{
  int count = sizeof(*p)/sizeof(int);
}

OK that code makes sense.

Assuming that n != 0 then 1.soef# looks like some error has happened in the maths. I would suggest that you output the values of store_temp and store_other to see what they are.

One possible error that suggests itself is from line 37

    store_other=store_other+(thick[i]/(cond[i] * area[i]));

Thick, cond and area are all ints which means that the bracketed section at the end of the line will be done as integer division. If cond[i]*area[i] is always greater than thick[i] this means that the result of (thick[i]/(cond[i] * area[i])) will always be 0. In that case you will always be adding 0 to store_other and since your divide by store_other you will be getting a divide by zero error (causing the 1.soef#). Even if store_other is not ending up as 0 it is going to end up having an integer value rather than being the sum of decimal values suggested by the code line.

If this is the problem then you can solve it by changing line 37 to

    store_other=store_other+(double(thick[i])/(cond[i] * area[i]));

The cast of the denominator (thick[i]) forces the whole calculation to be done as floating point arithmetic.

It is important when mixing integers and floating point types to make sure you do your calculation with the correct type.

In the main function they are not pointers they are arrays and the size of an array is the sum of the size of each its elements. When you divide by the size of a single element you get the number of elements in the array.

So in this code example

int a[]={1,3,4,5,7};

int* p = a;

int m=sizeof(a)/sizeof(int);

int n=sizeof(p)/sizeof(int);

a is an array with 5 int elements (assuming that an int is 4 bytes) the size of a is 4 * 5 = 20. m is set equal to 20 (size of a) divided by 4 (size of int) which is 5, the number of entries in a.

By contrast p is a pointer it has a size of 4 bytes (on a 32 bit OS) although it points to a the size of a is not part of the information storred in a pointer so n is set equal to 4 (size of a pointer) divided by 4 (size of int) which is 1.

Despite what you see here and there on the internet it is very important to remember that arrays and pointers are not the same thing they are really quite different objects, it is just quite easy to convert an array to a pointer (line 3 of my example).

Just noticed that you wrote

and the final 'q' is a double value.but its showing some abnormal values during compilatio.
So that through me off because you don't normally get values during complation, do you mean you got error messages? If you got compilation errors then post them.

Actually I think I should have used 'declaration' not 'definition'.

However what I mean is that you use the variable store_temp but no-where is there a line int store_temp or something similar. The variables store_temp and store_other are not declared so in theory your code does not compile.

Even if you did declare them they are only ever assigned the value 0 so q is assigned the value 0/0 which actually I might expect to cause some sort of crash at least some of the time.

You can increment using something like this assuming a grey code number with n bits numbered from LSB 0 to MSB n-1

Get the count of the number of bits set to 1

if count is even
    invert bit 0
else
   set j = the number of the least significant bit set to 1
   if (j == n-1)
       invert bit j
   else
       invert bit j+1
   endif
endif

I kind of worked this out emperically rather than finding a proof for it so you may wish to verify it over a wide range of numbers.

1. There is not other option in your printf statement, the only way to output a value multiple times is to put in multiple times on the parameter list.

2. Not surprised that q has odd values. You have not included a definition of store_temp or store_other but they both are only ever assigned the value 0. Sure you should have total_temp and total_other respectively insead?

Your problem is line 15, you use n to get the size of memory to allocate but at this point it is uninitialised (using, reading the value of, an uninitialised automatic variable is undefined behaviour) because you do not get the value from the user until line 17.

You need to split line 15 into 2 lines

struct laptimes *ptr = NULL; // Note always initialising pointers is good practice

ptr = malloc(n * sizeof(*ptr));

The first of those 2 should still be at line 15 and the second at line 18 so that you declare your pointer at the top of the function but allocate the memory for it after line 17 where the value of n is input by the user.

Also it is generally best practice after calling malloc to check that the pointer is not NULL before using it:

ptr = malloc(n * sizeof(*ptr));

if (ptr != NULL)
{
    // for loop scanf, printf etc

    free(ptr);
}

Actually the standard says that use of any automatic variable before it has been either initialised or assigned is undefined behaviour, which as we all know is bad.

<pedantic>

If you need to say conclusively that something like 1001011001 is binary, it's much harder. That particular number is perfectly valid for any base

Strictly speaking that number is not valid in base 1 which is a valid base which has a single arbitary digit (normally 1 is used). Since this number uses 2 digits 0 and 1 it can not be a base 1 number.
</pedantic>

It is not looking too bad.

Line 16: you don't use p and there is no need to for this line

Line 21: You need to provide pointers to scanf because it needs locations in which to store values not the values themselves, this should be written scanf("%f%f%f%f",&ptr->lap1,&ptr->lap2,&ptr->lap3,&ptr->lap4);

Line 22: Some space between your output values will make them easier to read

Line 27: You have 1 more closing brace than opening brace, just delete this one

Finally I'm not sure if you are using the C90 standard or the C99 standard. In the former case then you can not declare variables halfway through a code block as you have done at lines 16 and 17, in the latter case you can.

You must declare a function before you call it, at lines 16/19 you respectively call ftoc/ctoc but this is the first time the compiler has seen those functions (it reads the file line by line).

All you need to do is arround line 3 add the code lines

static float ctof(float d);
static float ctof(float d);

This tells the compiler about those functions, their parameters what they return and allows the calls at line 16/19. This is part of the stricter type checking that C++ does.

Now I feel I should have explained more (especially having remembered what the issue is).

The problem is that in C you do not need to have a prototype for a function before you call it. That means you don't have to include stdlib.h before calling malloc/calloc. Without the inclusion the compiler assumes malloc/calloc return int.

If you don't have the cast then you get a warning at least however if you have the case you get no warning. This is bad on a 64 bit system because on most 64 bit systems today int is 32 bits and pointers are 64 bits. With the hidden implicit return type the 64 bit void * returned by malloc is converted to a 32 bit int and then converted to a 64 bit pointer, you corrupt the pointer value by loosing the top 32 bits.

Try compiling this code (as is i.e. no headers)

int main()
{
  long* pl1 = malloc(sizeof(long)*10);
  long* pl2 = (long*)malloc(sizeof(long)*10);

  return 0;
}

You only get warnings at line 3, none at line 4 the cast hides them.

That is why you shouldn't cast, to cover the case of you forgot to include the correct header.

Not quite sure where sizeInTChars comes from but it would appear that it's value is 0 when is should be at least 1 or 2. This looks like parameter checking of a function so I'm guessing sizeInTChars might be a function parameter in which case somewhere you have called the function (xtoa?) with invalid parameters.

NOTE: calloc returns a void pointer (void) which has to be cast to a pointer of the appropriate type - in this case we need to cast it to a laptimes pointer (laptimes)

Very wrong, calloc does return void* but you do not need to cast it if you are using C, in fact casting void* in C is poor practice the compiler knows what to do and you should let it. By casting you are telling the compiler you know better than it and to just do what you say without any sanity check but actually you don't know better than the compiler.

If you are going to reply to say that you get an error if you don't put the cast in then you are almost certainly using a C++ compiler which does not automatically convert void*. In this case you shouldn't be using malloc or calloc any but rather new since you are using C++.

Line 18 is just wrong, I didn't say to put in anything like that and I can't tell why you think it is required but you can just remove it.

free has to be called with the pointer you wish to free so the syntax at line 30 is wrong.

comp is never used you can remove lines 13 and 17 without affecting your program.

line2 20, 21 and 23 really make no sense. What you want to do is allocate an array of struct laptimes to hold you results. What you do is point you laptimes pointer ptr to the address of an integer, then you allocate memory and assign it's address to the integer.

line 21 ptr = address of p
line 23 p = address of memory block that is the size of an int.

replace lines 20 - 23 with

struct laptimes * ptr = malloc(n * sizeof(*ptr));

replace line 30 with

free(ptr);

Finally at lines 27 and 28 this (*ptr).lap1 is a slightly strange construct (although not wrong) however most people would use ptr->lap1, once ptr is allocated an array you may wish to use ptr[0].lap1 to get the idea of an array across.

int control = 1;

while( control == 1)
{
   if (<IWantToStopTheLoop>)
   {
       control = 0;
   }
}

Are you sure you solved the issue? Try this input data

hello worlds
a b c d

NOTE The added s on worlds

Does that work with your new code.

The problem is that your comparison at line 39 is effected by the assignments at lines 43 and 56 which relate to the lengths of the current strings. This means that the comparison at 39 is dependent on the relative sizes of maxString and length of str[strNum-1]. That is the data you input and the order of that data both alter the comparison at 39.

For your current data that is the difference between the length of the maximum string (hello or world both length 5) and the length of d which is why I ask you to try changing world to worlds.

The truth is this code does not properly detect the end of its loop, you need a condition that is not dependent on j which varies with the data.

The actual stop condition is that you have output all words from all strings, that is you have a complete iteration of the for loop at 41 that never enters the if block at 45.

It wont do either it will cause undefined behaviour.

You must call free on the actually pointer value returned by malloc. If for some reason you need to increment the pointer you should use a copy so you can still free the original pointer.

int main ()
{
  int * buffer1;
  int * buffer2;
  buffer1 = malloc (100*sizeof(int));
  buffer2 = buffer1 + 5;

  free (buffer1);
  return 0;
}

That rather depends on the size of int on your computer.

If size of int is 2 and size of long is 4 then in your struct ss there is likely to be 2 padding bytes in the structure between c and d. These bytes are never assign but it is these bytes that are shared with the b in struct s.

This is all to do with the size of basic types on your platform and the your platforms structure packing algorithm.

trying outputing

sizeof(int)
sizeof(long)
sizeof(struct s)
sizeof(struct ss)

Actually th order of evaluation of operators of the same precedence is defined by the language. If you look at the page you linked to 3 posts ago then it is listed there as the operators associativity.

Precedence is not about which operator is evaluated first, it is about how the operands bind to the operators.

So in the expression A || (B && C) the parentheses overide precedence, B and C bind to && and A and the result of the && bind to the ||.

In the expression A || B && C there are no parentheses to overide precedence, so in this case precedence takes effect an since && has a higher precedence the B and C bind to the && and A and the result of the && bind to the ||. Note this is the same as the previous example.

In the expression (A || B) && C the parentheses actually overide precedence. Normally the && having a higher precedence would use B as it's left hand side however because of the parentheses the A and B bind to || and the result of the || and C bind to the &&.

Again this is not about which operator gets evaluated first, they are evaluated as they are needed. This is about what each operator uses as its operands.

Because since i Have mentioned the brace for && operator to make it execute first

The parentheses () do not make the contained code execute first. That is a simplistic way to think of them and wrong. The parentheses create a sub-expression with-in a complete expression. The sub-expression is evaluated when it's value is required.

So in the statement

j = j || (printf("you can")&&(i=5));

the expression is j || (printf("you can")&&(i=5)) which consists of 2 sub-expressions j and (printf("you can")&&(i=5)). The operator using these 2 sub-expressions is || which as deceptikon explained is a short-circuiting operator (only || and && are short circuit operators in C/C++) that means it evaluates its left hand expression first, since this is or if it is true the answer can be deduced from that single result and the right hand expression is not evaluated. j is 7 and this equates to true so in your code the left hand sub-expression j is evaluated as true and because of that the right hand sub-expression (printf("you can")&&(i=5)) is never evaluated.

In your more simple example a=4*(5+6) the parentheses create a sub-expression (5+6) but since the multiplication operator requires the values of both its sub-expression this is always evaulated. It is platform dependent weather the sub-expressions (5+6) or 4 is actually evaluated first but both are evaluated before the multiplication is done.

Reference variables are much like pointers, but you can declare them as const

You seem to imply that points can't be declared const, I'm not sure if that was your intention but pointers can be declared const just to clear up any confusion.

Line 43: you ask the user for a string but the variable str is only a single character not a string (an array of char)

Your 2 arrays alpha and ALPHA seem unlikely, at this stage to be of any use.

Your encrypt function just needs to read everry letter in the string and replace it with another letter offset places down the alphabet. You could do this as modulo arithmetic, convert the letter to an index into the alphabet, add the offset in modulo 26 arithmatic.

Pointers are passed by value. What this means is that for POD types passing a value to a function by pointer instead of by value makes very little difference. Imagine a 32 bit machine with 32 bit ints and 32 bit pointers. You have an integer to pass so in either case you are poutting 32 bits onto the stack.

You only really need to use pointers to pass POD types if the function you are calling is going to alter that parameter and the calling code wants to receive the new value set by the function.

However once you introduce classes then passing by pointer can have a very large effect. You may not know the implementation of a particular class but passing it by value means that the entire class needs to be copied. In this instance passing the class to the function by pointer can save a lot of processing and memory allocation/deallocation.

If you are going to pass by pointer then remember it is better where possible to actually pass by reference (since the calling code does not then need to check that the pointer is valid) and where possible, where the function does not actually change the data pointed to/referenced you should make the pointer or reference const.

It only appears to work, it is in fact undefined behaviour, this is exactly what it says the behaviour may be a crash or it may appear to work or anything inbetween and it may do different things every time it is run. If you put this sort of code into a larger program that ran for longer you would run a very serious risk of the program crashing at some unknown point in the future.

And the moral: If you know it is wrong don't do it just because it "appears to work", do it the right way.

It is hard to know precisely what is wrong because you give no context but here are a few possibilities (with reference to the line numbers in the code you posted).

1. Line 235 you create a variable of RomanType, you try to return this from operator+ but the defined return type is extRomanType and there is no way to convert between the 2.
2. If you try to change RomanType at line 235 to extRomanType you get an error because extRomanType has no constructor that takes a string. In fact there is a complete mismatch in constructors between RomanType and extRomanType. The first has constructors taking string and int but no default constructor while the second has a default constructor but no other type of constructor.
3. The default constructor of extRomanType calls the, non-existant, default constructor of RomanType. From the sketchy information you give this looks like the likely cause of your error.

Your problem is in the while loop at line 9. The thing is that cin is always going to return ok (true) while it can perform the operation you have requested so the only way to break this loop is to input data that can't be converted to a number, a letter for example so if you input the string "4 5 6 7 8 9f" for example you code works fine outputing the list of numbers.

You could change the text at line 8 to read "Please enter several integer numbers, enter q when finished." without changing anything else to get a program that works as instructed. The other alternative is to ask how many numbers the user wishes to input first and then when you have got that many numbers to stop asking for any more.

Your syntax on line 7 is never going to work, it could only ever work is C was an acester of A.

But you can initialise a class in its constructor from another class like this

class C
{
public:
  explicit C(const A& inita) : a (inita)
  {
  }

private:
  A a;
};

C *pointer = new C(a);

At line 107 you are missing the const on the declaration of the inclass parameter

Your declaration and definition of list_clear at lines 28 and 55 do not match