Posts by Banfa

I feel that someone should point out that having public member variables is generally very poor practice. The coding standards at my work require all member variables to be private.

That is because you still have 3 loops, get rid of the third loop as I showed you. The problem with your implementation is that because of the nested loops it has a complexity of N^3. By removing a loop you reduce the complexity to N^2 which makes a huge difference to execution time.

It is slow because of the number of nested loops you use.

If I just compile the C++ code I get the following runtimes

                      Compiler      Execution
Code                  Optomised       Time
Your Original Code      No            7.237s
Your Original Code      Yes           1.144s
Rewritten With 2 Loops  No            0.018s
Rewritten With 2 Loops  Yes           0.002s

You ought to be able to get at least as good as the unoptomised compilation of the C++ code.

Also the code in assembly at lines 9-10 does not implement either the equation of you C++ code or the equation in the comments.

Alternatively consider that your assembly routine takes 33s, my original C++ port of your assembly routine without optomisation also takes 33s but with optomisation takes 20s and accept that the C++ compiler and optomiser does a better job than you of producing assembly/machine code and just use the C++ implementation with optomisation switched on.

You have used more loops than is necassary. The thing is once you have chosen a value of a and b you can calculate the value of c that solves the equation 2a + b - c = y. You do not need a loop that checks every value of c.

In fact since you just want a count of solutions you don't even need to calculate the value of c all you need to check is that the value would be in the right range 0 <= c <= y.

Written in c++ it looks something like

for(a=0; a<=y; a++)
{
    for(b=0; b<=y; b++)
    {
        if ((((2 * a) + b - y) <= y) && (((2 * a) + b) >= y))
        {
            ++count;
        }
    }
}

This takes about 0.019s to run or if you switch on the optomiser 0.006s for an input of 2000. (NOTE with 3 loops the C++ solution was taking around 33s to complete or 20s under optomisation).

Interestingly the calculate c and then check it's in the right range solution

for(a=0; a<=y; a++)
{
    for(b=0; b<=y; b++)
    {
        c = (2 * a) + b - y;

        if (0 <=c && c <=y)
        {
            ++count;
        }
    }
}

takes 0.039s with no optomisation (slower) about 0.004s with optomisation (faster) which kind of suggests the optomiser finds it easier to optomise simpler code (which makes sense).

I imagine this is an endian issue. When storing an integer in memory little endian processors store least significant byte first, big endian processors store most significant byte first.

So the numbers are stored in memory as follows

30030 
little endian machine: 4E 75 00 00
big endian machine:    00 00 75 4E

34094
little endian machine: 2E 85 00 00
big endian machine:    00 00 85 2E

Taking -16 to mean second one bigger and 1 to mean first one bigger and remembering that memcmp compares a byte at a time then.

On a little endian, Linux, it compares
1st Byte: 4E with 2E; they are different, 4E is bigger so the first parameter is bigger so it returns 1 and stops.

On big endian, HP, it compares:
1st Byte: 00 with 00, the same continue to 2nd byte
2nd Byte: 00 with 00, the same continue to 3rd byte
3rd Byte: 75 with 85; they are different, 75 is smaller so return negative. It is doing the comparison by subtraction and returning the result if it is not 0, 0x75 - 0x85 = -16

That is how you get different results on different machines with them both being correct.

int a[10][10];

is same as,

int(*a)[10];

Err, NO.

The first, a is an array of 10 arrays of 10 integers.

The second a is a pointer to an array of 10 integers.

Assuming the first, int a[10][10];, then the expression a evaulates to a type int(*)[10];.

Which is the same type as a in the second case.

So then break down the statment `((a+1)+1)'

a is a pointer to an array of 10 ints
a+1 increments a, the compiler knows the size of a so it increments it by that size to the next array of 10 ints in the array
(a+1) converts us from a pointer to an array of 10 ints to an array of 10 ints which evaluates to a type int *
*(a+1)+1 increments our int * point to the next one in the array
*((a+1)+1) converts out int * to an int

Basically giving the second integer in the second array of 10 ints, functionally equivilent to a[1][1].

I would say that, particularly in portable code, the C bitfield syntax is of no use. It is a syntactic sugar for accessing bits in an integer type that can easily be achieved using the bitwise operators (& | ~ << >>) the difference is that while using the bitwise operators you can easily write portable code the C bitfield syntax is not properly portable because it is very loosely defined. Different platforms do not need to put the bits in the same order and do not have to use the same padding bits.

In general I would avoid using C bitfield syntax.

Which means if you added the switchs -Wall -pedantic to your compiler command you code would not compile (try and see)

• -Wall - output all warnings and errors (actually not quite all a few esoteric ones still need to be explicitly enabled if you want them)
• -pedantic - pendantically follow the C++ (or C) standard and do not use any extentions.

Because 0.3f has type float and 0.3 has type double so using 0.3 inloves an implicit conversion of your variable i to type double and since, as discussed, floating point representations are approximations and double as a different represenation to float the conversion can change the value slightly making it higher or lower.

You should not use comparisons in floating point anywhere that you require absolute acuracy, it is fine if you are testing some tolerance, you have a complex equation with a check value and the output is right if the check value is <0.1 because if the check value is actually 0.1000001 then the result was borderline anyway and it is probably fine to discard it.

If you want accuracy, or you are on an embedded platform and you don't want to pull the bloat of the floating-point emulation library into your application then you use scaled integers. A typical example is the banking world, they do not hold money as pounds (£) in a float type with pence as a fractional part. Rather they use a scaled integer and hold money as pence (or may be even 1/10th of pence) in an integer value where practical maths operates as you would expect theoryetical maths to work. Of course you have to watch out for the upper bound of an integer but generally today that can be solved by using some sort of big-int class that has no upper bound.

Basicall you can't do what you are trying to do at line 8. You can not compare a value to an array of values, you have to do the comparison individually, or in this case have a string containing your hexadecimal characters and use a string search function (such as strchr) to see if your entered character is contained in that string.

To start with scanf("%s",&sh); is incorrect it should be scanf("%s",sh); because sh is an array so using it without any [] already produces a pointer to it, you don't need to de-reference it.

Secondly, never, ever use gets, always use fgets, so not gets(sh); but fgets(sh, sizeof sh, stdin); it is safer since you can't overwrite the buffer, but note that gets does not return the '\n' at the end of the line and fgets does.

So the problem is mixing scanf and gets. gets reads up to the first '\n' character in the stream, scanf reads a data to fit the provided format string, skipping white space. So when you make this call scanf("%d",& cont_flag); it leaves a '\n' in the stream since you didn't tell it to read it in any way and the following call to gets reads the '\n' that is left in the stream and returns immediately. When you use scanf("%s",&sh); it is not looking for '\n' characters so it just skips it as whitespace and looks for actual data.

Mixing input methods nearly always leads to confusion.

You can't implement what sizeof does because it is done by the compiler at compile time, the only way to get sizeof behaviour is to use sizeof.

It you pass an array to a function

void function1(int* parameter)
{
    // Some code using parameter but element count in parameter not known
}

int array[5];

function1(array);

Then the function does not know how many elements where in the array unless you also pass that it, there is no way of knowing this.

void function2(int* array, int size)
{
    // Some code using array, element count given by size
}

int array[5];

function2(array, 5);

In C++ the way to get round this is to use a std::vector. This is an object that encasulates an array and one of the things it maintains is the array size so it does not need to be passed separately

void function3(std::vector<int> vec)
{
    // Some code using vec, vec knows its own element count
}

std::vector<int> array(5);

function3(vec);

Do you check your return value from strchr for NULL? I ask because you search for '*' but you string does not appear to contain any *.

Also you do not appear to be assigning any memory to the pointer nameBuffer before you copy into it.

You need something like

char *nameBuffer = 0;
if (nameEnd != 0 && msgStart != 0)
{
    int size = nameEnd - msgStart;
    if (size > 0)
    {
        char *nameBuffer = new char[size+1];
        if (nameBuffer != 0)
        {
            strncpy (nameBuffer, msg, size);
        }
    }
}

The hard way is long (and hard) you need to check everything worked before continuing.

At line 12 of you code where you create the new node there seems to have been nothing done to check that the value produced is a valid index for the tileMap array.

For example if newParent->x == 0 then on the loop iterations where x == -1 the result will be -1 which if used at lines 16 or 21 or anywhere else tileMap s accessed seems likely to produce an out of bounds access to the tileMap array which would certainly result in the unhandled exception.

Probably the easiest way to catch the error would be to run you program in the symbolic debugger, it should trap the exception and halt allowing you to examine the code and variables at the point of the exception.

It is very important to comment why some code does a particular thing, you can normally tell what it does just from reading the code itself. If you happen to have implement some specific algorithm then I would also comment what algorithm and may be why it was chosen.

If you work in any sort of sized company then comments are extemely important because the next person editing the code may not be you and they will need to know what it going on and why it was done like that.

Because you return s from mkUpperCase which by the time the function has finished running points to the termintor of the string.

If you print name as well as the return from mkUppercase you can see the function actually did it's job.

mkUpperCase should store and return the input pointer.

In operator= (lines 41 - 46) you create a temporary stack which gets deleted as soon as the function exits. This is surely not what you intend, I imagine you want to push onto the current stack don't you?

You are already in side a member of stack so you can just use the this pointer to access the current object to execute the push operation return this->push(right);

Should work fine but why not just divide by matrix1.size()?

A segmentation fault is normally a memory error, access to an invalid or NULL address. Basically your compiler has crashed compiling your code. This does not necessarily mean there is any error in the code, there could be an bug in the compiler.

Common fixes would be

1. Use a new version of the compiler with the bug fixed
2. Restructure your code so it doesn't produce the fault

Lines 41 - 43 have the assignments the wrong way round, you are assigning the value of the class members to the initialisation parameters rather than the value of the initialisation parameters to the class variables e.g. base = i;

A bit of a sledgehammer approach but try calling InvalidateRect on you controls as you paint your window e.g. InvalidateRect(License, NULL, FALSE);

That just ain't how you do it, you need to implement (overload) ArrayOfTypes::operator[] and MyType::operator= separately to achieve what you want not try and do it together which is presumably this

ArrayOfTypes array;
MyType value;

array[10] = value;

ArrayOfTypes::operator[] returns a reference to a location in the array which can then be used to invoke MyType::operator= to assign to that location

class ArrayOfTypes
{
public: // ?
  vector<MyType> P;
     
  MyType& operator [](int I)
  {
    // Validate I in range ?
    return P[I];
  }

  // Implement a const version too for calling in const contexts to read the array
  const MyType& operator [](int I) const
  {
    // Validate I in range ?
    return P[I];
  }
};

class MyType
{
public:
  const MyType& operator=(const MyType& cpy)
  {
    // Don't copy self
    if (this != &cpy)
    {
      // Code to copy a MyType
    }

    return *this;
  }
};

A-ha well the answer is yes there is, pre-pend a ::

::shutdown(socketId);

this will call the method defined at the global scope (i.e. the one in the C WinSock2 API).

It would help if you posted your code in CODE tags.

As well has having functions called smallest and largest you also have variables (int) called smallest and largest.

You can't initialise anything that has already been declared. You can only initialise something at the time it is created, after that it becomes assignment.

And to answer the spirit of your question no there is no way to assign to all members of an existing array without recourse to a for loop (with the exception of using memset on an array of char).

Start a command prompt and run you program in it.

Dev-C++ is a bit long in the tooth you may want to try something a little more up-to-date like CodeBlocks.

You shouldn't be putting paths into #include statements on the whole, it makes it very hard to take the code to another computer unless it has exactly the same hard-drive and directory set-up.

You can pass the directory(ies) to search for include files into the compile normally using the -I switch or set it in your IDE in the project properties.

I would say you have 2 options (remembering that the majority of processes, even multi-threaded ones do not actually run concurrently, mostly they time-slice, that is each thread gets a chance to run in turn and while a thread is running non- of the other threads of the process are running).

Firstly you could create a properly multi-threaded program using the API of your OS to create 1 (or more) threads to perform the required tasks. You will need to ensure you protect any data you use in both threads from simultaneous access by both threads, normally done with a mutex (or Critical Section on Windows).

Secondly, if this is a small and simple program you could use a super-loop. Super-loops were more common before the days of (pseudo) multi-tasking (on DOS then) but I still see them occasionally on very low powered micro-processors that really do not need or don't have the resources for an OS.

A super-loop construction is simple, it is a loop (for/while/do while) and each task has a function that is called from the loop. It is important that those task functions do not "pause" because that would interrupt the other tasks. An advantage is that because there is only 1 thread of execution you are guaranteed that when 1 task is running the other tasks are not accessing any data.

The top-level of a super-loop would look something like this

bool task1();
bool task2();

int main()
{
  bool task1Finished; …

Your code doesn't try to send anything.

Most UARTs also produce an interrupt, normally on data received, on error and possibly on ready to send data.

It is common (and therefore I assume I good approach) to handle data receive using the UARTs interrupt and it is often a requirement to handle the error states of the UART which is also most easily done using the interrupt. Send can either be polled or interrupt driven, polled works well if you want to be sure the data has been sent before your program continues while interrupt driven works if you want to just fire and forget i.e. you don't need to know when the data has been written.

Global data is bad, however it is not always avoidable. There are no hard and fast rules in C++ just best practice and less good practice and you need to know when to ignore best practice.

I would say make a big effort to avoid making any global variables that are not a pod type (pointers, char, integers, floats, bools) i.e. no global data with a type of class or struct (noting that structs and class are more or less the same).

I say this because if you do then those variables get constructed before main is running and destructed after main exits and you end up with code running at times when you can not really be sure of the state of the system. And if you have more than one defined in different files you have no control over the order the construction takes place in.

Singletons do have there uses but remember the purpose of a singleton is not to replace global data but to provide a class that guarantees that the entire program uses the same instance of it while still providing the object orientated advantages of encapsulation, hierarchy and polymorphism.

However I implement them with a static pointer to the type rather than a static copy of the type. A pointer is a pod and causes no problems with code running outside main, then you first time the singleton is accessed you simple construct it (or if you prefer have a …

Or a set would work, a set of the actual values would returned not found if you looked up a non-existing value.

On NULL it really only applies to pointers. It is a special representation for the platform that indicates that the pointer is invalid. The NULL pointer for a platform does not have to have the value 0 but a compliant C++ compiler does have to convert the value 0 used in a pointer context in the code to the platforms NULL pointer value. Of course on many(most?) platforms the NULL pointer value for the platform is actually 0 so the conversion is quite simple.

This should not be confused with NUL the name of one of the control characters (the first 26 characters) in the ASCII character set that has the value 0 or '\0'.

Neither NULL or NUL apply to any form of integer(int) or floating point type.

The #define LWIP_MEMPOOL line creates the elements of the enum when combined with memp_std.h. This #define causes every line in memp_std.h to be an element in the enum including the comma.

It doesn't matter where the #define is written, it is a text substitution and gets included where the symbol LWIP_MEMPOOL appears in the code. That is in the code included from memp_std.h.

The process in the preprocessor is something like this (assuming the format for memp_std.h is what I gave in my first post)

#define LWIP_MEMPOOL(name,num,size,desc) MEMP_##name,
typedef enum {
#include "lwip/memp_std.h"
MEMP_MAX
} memp_t;
#undef LWIP_MEMPOO

1. Read line 1: it is a #define, remember the definition and remove it from the code.
2. Read line 2: there are no preprocessor directives on the line so leave it alone
3. Read line 3: it is a #include directive, open the given file and copy it into the current source file. At this point the code looks like this

   typedef enum {
   
   LWIP_MEMPOOL(Pool1,100,8,"8 byte pool") 
   LWIP_MEMPOOL(Pool2,100,16,"16 byte pool") 
   LWIP_MEMPOOL(Pool3,100,32,"32 byte pool") 
   LWIP_MEMPOOL(Pool4,100,64,"64 byte pool") 
   
   MEMP_MAX
   } memp_t;
   #undef LWIP_MEMPOO

4. Read the contents just included starting at line 4
5. Read line 4: It contains the symbol LWIP_MEMPOOL, the preprocessor has a definition for this symbol so make the text substitution for line 4
6. Read line 5: It contains the symbol LWIP_MEMPOOL, the preprocessor has a definition for this symbol so make the text substitution for line 5. At this point the code looks like this

   typedef enum {
   
   MEMP_Pool1,
   MEMP_Pool2, …

It has no formal definition so its meaning is defined by the context.

Normally it just means group of related things so a module could be a group of related classes or a group of related source files, possible with-in a single process or in separate processes.

I think in your quote it problem just means "a chunk of code".

OK lets get this straight, I personally would write this

typedef enum {
#define LWIP_MEMPOOL(name,num,size,desc) MEMP_##name,
#include "lwip/memp_std.h"
MEMP_MAX
} memp_t;

as

#define LWIP_MEMPOOL(name,num,size,desc) MEMP_##name,
typedef enum {
#include "lwip/memp_std.h"
MEMP_MAX
} memp_t;
#undef LWIP_MEMPOOL

I put the #define outside the enum because I don't think it looks good inside and I #undef the symbol once I have finished using it in case I need to use it again later.

The exact use, in this case of the #define LWIP_MEMPOOL(name,num,size,desc) MEMP_##name, in combination with the file memp_std.h is to provide a definition of LWIP_MEMPOOL that results in a valid line in the enum, the result being an enum value for every pool in the memory manager.

The line LWIP_MEMPOOL(Pool1,100,8,"8 byte pool") under the definition of the the symbol LWIP_MEMPOOL as #define LWIP_MEMPOOL(name,num,size,desc) MEMP_##name, processed by the preprocessor results in the compiler seeing the code line MEMP_Pool1,

so the actual code listing

typedef enum {
#define LWIP_MEMPOOL(name,num,size,desc) MEMP_##name,
#include "lwip/memp_std.h"
MEMP_MAX
} memp_t;

After preprocessing using the version of memp_std.h that I gave results in the compiler seeing

typedef enum {
MEMP_Pool1,
MEMP_Pool2,
MEMP_Pool3,
MEMP_Pool4,
MEMP_MAX
} memp_t;

ie it defines an enum entry for every pool.

The concept is simple, you have a group of objects whose values are never going to change an runtime and you want to automatically produce the data and symbols to handle them, but there are several different data objects and symbols being defined and you want …

I see no new function in that code.

Surely by now you have learnt when posting to post all the information including errors?

main()
{
	void USERF(double *,double *,double);
.
.
}

You can't declare functions-in-functions in C, perhaps in JavaScript or Pascal but not in C/C++. Take that declaration outside main().

Actually you are wrong, you can declare functions inside functions like that. What you can't do is define functions inside other functions like this

int main()
{
	void USERF(double *,double *,double)
	{
	}
.
.
   return 0;
}

Here is your function S_NEWT with the code removed and the relevant parameter highlighted

void S_NEWT(int *n,double *x0,double e,int NMAX,[b]double (*FUNC)()[/b])
{
   <snip>
}

The () at the end of the highlighted parameter represents the parameter list for the function pointer FUNC.

Here is the prototype of your function USERF

void USERF(double *,double *,double);

The parameter list is everything between ( and ). () and (double *,double *,double) are not equivalent, you need to alter the () in your function S_NEWT to match what is in USERF.

This needs to be done both where S_NEWT is declared and defined.

I am using fstream, so it should include cin and cout. What I learn is that fstream is inherited from iostream,ifstream,ofstream and some other header files so includes the functions of iostream as well.

I took note of your suggestions, thanks for it. I took note of it.

No fstream in <fstream> inherits iostream in <istream>. cin in <iostream> inherits istream in <istream> and cout in <iostream> inherits ostream in <ostream>.

There is no connection in inheritance or filewise between fstream and cin or cout. To use cin or cout you must specifically include iostream.

NOTE: the class iostream is not declared in the header <iostream>

See here

That is because fstream.h (and all other C++ headers ending .h) is a pre-standardisation header i.e. over a decade old and has been depricated for sometime and I expect MS has taken action and removed it from their IDE/compiler.

use #include <fstream>

Functions are in the global scope, you can return a pointer to any function (even a static one) and the pointer will be valid.

The address might well be the address of the first instruction in the function however the true answer to your question is that it is platform defined, i.e. there is no one answer that is necessarily correct for all platforms.

yes there is a rule. types are promoted to a higher type if assigned to a higher type. going from a higher type to a lower type works as well but there can be truncation of the number

That's not the complete picture, types are promoted to a higher type if used in a calculation with a higher type or when assigned to a higher type, whichever happens last so

int foo = 5;
float bar = 3.5;
float result = foo + bar;
// result is now 8.5 because foo gets converted to a float and then added.

// but
int foo = 5;
int bar = 2;
float result = foo / bar;
// result is 2.0 not 2.5 because the calculation uses integer arithmetic

In the second example the values are not promoted to float until after the calculation has happened and the result is stored in result. That means that the calculation takes place using ints and integer arithmetic and all fractions are dropped.

But my question is for SQ(a+2) >> a+(2*a)+2 ...that means when a=5 the answer is 17.

You could easily follow the same process griswolf already did he left out the - but put it in and you get

-SQ(a+2) == -a+2*a+2 == -a+(2*a)+2 == a+2

Therefore for a=5, -SQ(a+2) == 5

By the way the answer to your second post is its undefined behaviour.

What you also need to be aware of is that right shift of a signed value in C is a platform defined operation and may be either arithmetic shift or logical shift.

That means the the operation

-2 >> 1

is not truely portable because the result could be either -1 or 127 depending on how the compiler has implemented right shift of a signed value.

In binary(decimal equivalent)

// arithmetic Shift
11111110(-2) >> 1 = 11111111(-1)
// logical shift
11111110(-2) >> 1 = 01111111(254)

Left shift of a signed value by more than the number of the bits in the value is undefined behaviour.

Generally it is considered best practice to avoid shifting signed values.

I think you will find this easier to do if you start-up a worker thread to perform your "process" leaving the original thread running the user interface.

My C++/CLR is quite rusty but I think you could use a delegate to call back to the interface thread with process updates to display and you could easily use an interprocess communications object such as an event to communicate a stop event to the background worker thread.

See System.Threading in the .NET documentation

Line 43 and 44, you copy to the char pointers fname and lname but you have not allocated any data for those pointers to point to. They are uninitialised.

The compiler probably doesn't crash after entering c because the compiler never requests that you enter c. Presumably you are actually running the program to get to the enter c phase. The program doesn't crash either, it does what you have asked and exits normally (or it does for me but then since this program exhibits undefined behaviour it is impossible to say what is happening for you).

You have the following problems

Line 4: Returning void is an extension that not all compilers support, get in the habit of returning int now.

Line 11: Unnecessarily declare c which is never initialised to anything.

Line 12: Attempt to add a and b and store the result in s before you have obtain values for a and b. Reading uninitialised/unassigned automatic variables is undefined behaviour.

Line 15: you don't scan the input return you typed so it is left in the input buffer, we'll come back to this ...

Line 19: Here where you ask for a character, the system looks at the input buffer which contains a line feed and returns that to you, no extra input is required.

Line 20: Access to the initialised variable c is undefined behaviour also this is not how you check if variable d is equal to the character c. You need to use a character constant (you can Google that).

As always with programs when you have a problem with your command line arguments put them in quotes -D"COMPLEX=std::complex<double>" I imagine that the command line interpreter is < as the input piping operator.

Of course strlen() returns the number of chars - NULL but in a string indexing starts from 0.
So
str[11] is sufficient to hold 11 characters plus 1 null char. As 0-11 is 12 characters in all

No very VERY wrong. strlen does not return the size of the array holding the string it returns the number of characters in the string up to but not including the NULL.

Try this code for proof

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main()
{
   char Text[] = "Hello World"; // Allocate an array just the right size of the text

   //Now print the two strings
   printf("Text: %s\n", Text);
   printf("strlen: %d\n", strlen(Text));
   printf("size: %d\n", sizeof Text);
}

And you will see that strlen returns a value 1 less than the size of the array required to hold the string.

Output

Text: Hello World
strlen: 11
size: 12

i have red in my lectures, that the following code

m-=m*3-h++*2;

can also be written as

m=m-m*3-h++*2;

No m-=m*3-h++*2; can be written as m=m-(m*3-h++*2); Those parentheses make all the difference because when you factor them out it becomes m=m-m*3+h++*2; Which is different to m=m-m*3-h++*2;

No your question is so lacking in detail that it is not answerable.