Posts by Salem

Well you need to read how printf() and scanf() work. scanf ("%f", METERS); should be scanf ("%f", [B]&[/B]METERS); Now go find out how to print parameters using printf as well (%d and all that jazz)

> can u pls teach me how to start
http://cboard.cprogramming.com/c-programming/88495-development-process.html

http://www.daniweb.com/forums/announcement8-2.html
Read this, make an effort, post that attempt and then ask a specific question.

Don't just dump your assignment on us and then go party, hoping to have a nice finished program sitting in your in-box.

There are a lot of reported posts on the main site entrance (see pic)

The console is what you learn with.

GUI programming is no different, it's just a different API. But it takes half a book to explain "hello world" rather than half a page, to an absolute newbie.

What you see today in the C pre-processor is a faint echo of how the pre-processor was originally implemented.

m4 is a macro pre-processor and then plenty.

The original C pre-processor (when C was still on a single machine in the 70's) was just an input to m4.

Oh, but you're on vista - that is unfortunate....

> well i am planning to record information in a database and the data can be accessed via the web in a well formatted web page.
That has to be the most bone-headed idea going.

"I know, lets publish all my keystokes on a web page for all to see - ohh, passwords, yummy!"

If you want to do something useful, write a program which finds keylogging malware, rather than adding to the considerable amount of pond life which is already out there.

> If i put #include "zlib.h" the errors are the same.
Include files tell the compiler HOW to call something.

Libraries (the thing you're missing) tell the linker (the stage after compiling) WHAT actually provides the implementation of the thing you wanted to call.

For a simple command line, it's something like g++ comp.cpp -o comp -lzlib You need to look up how to use the -l options, and substitute an appropriate name for the library.

http://lmgtfy.com/?q=usb+webcam+via+Python

All the files are in the same directory?

If so, all you need to do is add the two .cpp files to some kind of project (or makefile), and then build.

> cannot find -lfunctions.h".
-l is for libraries, not header files.
Like I said, in a simple case with everything in the same place, you don't need any additional compiler flags.

Oh, and remove the namespace from the header file. In future, if someone wants to use your header files, they may not want the namespace. There is no "undo" once a namespace has been added.
Instead, write

#ifndef FUNCTIONS_H
#define FUNCTIONS_H

#include <string>

// don't do this using namespace std;

int do_action(std::string a, std::string filename);

#endif

using namespace std is a pretty lazy habit anyway. You might try something like

using std::cin;
using std::cout;

to cut down on the really repetitive stuff, and use the full std:: approach for everything else.

When you start using other namespaces, the transition will be less harsh.

Running around YELLING and cross-posting all over the web won't make it happen any quicker.

> when i am runing the server program and doing telnet 127.0.0.1 int the console
What command did you actually type?
telnet without additional parameters will try to connect to port 23
Your server is listening to something else.

> my problem is that my teacher give an activity to do to make a c++ program that will determine
That's not all.

It also determines who gets to stay on the course and learn something advanced, and who gets extra free time to explore alternative paths through life.

For you, it's looking a lot like door number 2.

> it states debug assertion failure fseeki64.c line 61 stream !=null.
You opened a file, say

FILE *fp = fopen("doofus.txt", "r" );

You then tried to seek somewhere - I guessed that fseeki64.c

> stream !=null
How many parameters does fseek() have?
Which one's are
a) pointers (the message says NULL)
b) could be interpreted as being a stream of some sort.

int fseek(FILE *stream, long offset, int whence);
Mmm, only one thing is a pointer, and it's called stream.

Answer, you passed NULL to fseek.
In other words, you blindly assumed that your file open succeeded and you were wrong.

Improve the error checking in your code.

I've no idea.
I stripped the code down to something simple, and it seems clean here.

/*-------------------------------------------------------------------------
 *  SphereInterface.c - Library of functions to read different wavefile formats
 *  Version:  $Name:  $
 *  Module:  
 *
 *  Purpose:  
 *  See:  
 *
 *  Author:  Hema Murthy (hema@bhairavi.iitm.ernet.in)
 *
 *  Created:        Thu 01-Mar-2007 12:19:44
 *  Last modified:  Wed 13-Jun-2007 08:45:53 by hema
 *  $Id: SphereInterface.c,v 1.4 2007/06/14 08:25:49 hema Exp hema $
 *
 *  Bugs:  
 *
 *  Change Log:  <Date> <Author>
 *      <Changes>
 -------------------------------------------------------------------------*/

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

/*****************************************************************************
  function : WriteRIFF - write to a file in RIFF format assumes
             data is sampled at 16KHz and quantised to 16bits/sample
  Inputs   : wavefilename
  Outputs  : short waveform, numSamples
  **************************************************************************/

//=================== WriteWaveFile ===================//
int
WriteRIFF (char *waveFileName, short *waveform, long numsamples,
	   long samplingRate, int bytesPerSample)
{
  FILE *file;
  RIFFWaveFile *myRIFF = NULL;
  long i = 0;
  long size = 0;
  int result = SUCCESS;
  file = fopen (waveFileName, "w");
  myRIFF = (RIFFWaveFile *) malloc (sizeof (RIFFWaveFile));
  myRIFF->header = (RIFFHeader *) malloc (sizeof (RIFFHeader));

  strcpy (myRIFF->header->riffChunkID, "RIFF");
  myRIFF->header->riffChunkDataSize = numsamples * 2 + 36;
  strcpy (myRIFF->header->riffType, "WAVE");


  strcpy (myRIFF->header->fmtChunkID, "fmt ");
  myRIFF->header->fmtChunkDataSize = 16;
  myRIFF->header->compressionCode = 1;
  myRIFF->header->numberOfChannel = 1;
  myRIFF->header->sampleRate = samplingRate;
  myRIFF->header->averageBytesPerSecond = bytesPerSample * samplingRate;
  myRIFF->header->blockAlign = 2;
  myRIFF->header->sigBitsPerSample = bytesPerSample * 8;

  strcpy (myRIFF->header->dataChunkID, "data");
  myRIFF->header->dataChunkDataSize = numsamples * 2;
  size = myRIFF->header->dataChunkDataSize / 2;

  printf ("size:%d\n", size);
  myRIFF->data = (short int *) malloc (sizeof (short int) * size);
  for (i = 0; i < …

> I'm running on fedora 10
Excellent.

Then you can try either of these and see what's going on. valgrind ./myprog valgrind is a tool used for spotting all sorts of memory management problems.

gcc -o myprog prog.c -lefence
gdb ./myprog

electric fence (which you link with -lefence) is a malloc debugger. Should you overstep any malloc'ed memory, you will immediately get a segfault, and be dropped in the debugger at the exact line of code causing the problem.

Use a different separator.
Eg.

sed -e "s@DATEST\@$DATESTART@g"

I can't figure out where the real separator is in the middle of the expression.
But you get the idea.

Regarding casting malloc.
Here's why it's a really BAD idea.
http://faq.cprogramming.com/cgi-bin/smartfaq.cgi?answer=1047673478&id=1043284351

Second, are these the ONLY malloc calls in your code, or are there others?
If you screw up with malloc even once, then any subsequent use of malloc/free can fail for any reason, at any time.
Staring at where it crashes will NOT tell you anything useful.

The only realistic chance that we (as remote viewers) have of telling you where such a problem is is by having the whole source code. If you've got masses of code, this is probably a non-starter. If you can trim it down to a couple of functions which still crash, then we could probably help.

Finally, let's talk about how you're corrupting memory (so my bet is you're doing this somewhere else where it would matter, only you don't realise it).

strcpy(myRIFF->header->riffChunkID, "RIFF");
myRIFF->header->riffChunkDataSize = numsamples*2 + 36;

The size immediately follows the ID.
Which is unfortunate, because the strcpy is going to copy FIVE bytes into space where there is only room for FOUR.
Fortunately, initialising the size takes place afterwards, so you get lucky.
But reverse the code, and your strcpy() would trash part of the size!

Maybe somewhere else, you're allocating a lot less that you thought (after all, \0 has overwritten some part of a size). Or maybe you're allocating a hell of a lot more than you bargained for, Either way, it isn't good.

You've got

#include "somethingElse.h"
#include "DoTestData.h"

The last thing in somethingElse.h is the real cause of the problem, and it will be missing the ; in question.

http://www.daniweb.com/forums/announcement9-2.html

There's a mine of information here
http://www.daniweb.com/forums/thread99132.html
Try spending an hour or two trying to figure something out for yourself. Making a start, and getting stuck earns brownie points.
Just dumping 1 liner of 0% effort doesn't.

While I'm at it, help me please isn't a title for a thread.

> I've learned Java, C++, and most recently C ( Fall of last year).
But have you actually learnt how to PROGRAM yet?

Learning a new language a year makes you an experienced "hello world" programmer. The world is knee-deep in these kinds of programmers.

The real trick comes when you have to design and implement programs which take months (or years) of effort, and have many 10's of thousands of lines of code.
Having memorised syntax and libraries for half a dozen languages simply won't cut it. You'll just be a library book on legs.

> Seeing how there is a great deal of threads for C++
Probably something to do with it being a C++ forum.
You'll find a lot of perl threads on the perl forum, but it doesn't prove your point.

> I'm thinking that I should go for C++.
Wait, your first statement was that you already knew C++ ...

http://www.parashift.com/c++-faq-lite/operator-overloading.html

The best place is project->settings->preprocessor and set the flag there.

You're assuming
a) the network has zero latency, by calling recv() directly after send()
b) that recv() will just stick around until a \r\n arrives - it won't.
c) that recv() will add a \0 to the end of the buffer to make it a proper C string - it won't do that either.

You need to seriously improve the recv() side of things to check for errors AND process the characters more carefully.

And so it begins.....

If someone isn't smart enough to think of a project to do, offering them a project title doesn't do anybody any good.

First they can't think of a title, so you suggest one.
Then they can't figure out what that means, so they ask you to explain it (we've reached that step).
Then you explain it. As sure as eggs are eggs, they're going to come back and ask you how to implement it.
Then actually help them to implement it.
Then how to debug it.

See where all this is going?

Before you know what's happened, you've earned another degree. Except it won't have your name on it.

@sam
You've got some keywords, start googling and doing some reading.

So what have you learnt (or even attempted) in the past two weeks?
http://www.daniweb.com/forums/thread208111.html

Yes, it's OLD C, and it defaults to int.

Congrats AD :)

> Now this is a marriage to be proud of Married 83 years, they have 186 descendants.
A birthday to remember every other day - that's gotta be hard work.
"What are you doing? Buying a present. Who for? Dunno, bound to be someone's either today or tomorrow".
Mind you, come xmas, it's payback time :)

> int a; //which is a definition
Actually, this is just a tentative definition
At the point of compiling it, storage space is not yet allocated to it, so you won't find it as such in the object file.

If you said nothing else, then the linker would create a single
int a = 0;
for you.

Or if you had exactly ONE
int a = 42;
in one of your source files, then all the other int a; would refer to that.

This is a catalogue of some experiments on just two aspects of undefined behaviour.

This was inspired by yet another long bout of explanation in a recent thread, so I thought it was time to dust off a bunch of compilers, and compare.

This is the test code.

#include <stdio.h>

int f1 ( void ) {
  printf( "f1 called = 1\n" );
  return 1;
}
int f2 ( void ) {
  printf( "f2 called = 2\n" );
  return 2;
}
int f3 ( void ) {
  printf( "f3 called = 3\n" );
  return 3;
}
int f4 ( void ) {
  printf( "f4 called = 4\n" );
  return 4;
}
int f5 ( void ) {
  printf( "f5 called = 5\n" );
  return 5;
}

/* Although * happens before +, there is NO guarantee that */
/* f1() will always be called after f2() and f3() */
/* http://c-faq.com/expr/precvsooe.html */
void test1 ( void ) {
  int result;
  printf( "Precedence is not the same as sub-expression evaluation order\n" );
  result = f1() + f2() * f3() - f4() / f5();
  printf( "Result=%d\n", result );
  printf( "inline=%d\n", f1() + f2() * f3() - f4() / f5() );
}

/* The nature of 'before' and 'after' is poorly understood */
/* http://c-faq.com/expr/evalorder2.html */
void test2 ( void ) {
  int i = 3, j = 3;
  int r1 = ++i * i++;
  printf( "Multiple side effects are undefined\n" );
  printf( "R1=%d, i=%d\n", r1, i …

If you're creating a win32 console game, try
http://www.adrianxw.dk/SoftwareSite/Consoles/Consoles5.html

Are you sure it's not skew in your printer as the print head tracks left/right?

Create some known test images using say mspaint to check.

Say something like this.

If these come out fine, or other printing applications come out fine, then you may have a software problem.

If something simple like an image is broken, then you've got a hardware problem.

Check if your printer has a setup/calibration option (try right-click on it's status icon in the systray ).

> If f() is called first than, the whole purpose of precedency is lost.
Oh man, learn to read.

f() called first, result stored in temp1 - have we done + or * yet - no.
g() called next, result stored in temp2, have we done + or * yet - no.
h() called last, result is still in a register.
Multiply register with temp2 - woohoo!, we did * first.

Sure, you might be thinking
call g(), result in temp1, call h(), multiply by temp1, store in temp2
Then call f(), add temp2 and store result.

Different - yes
Same result if all the functions are free of side effects - yes
This order is mandated by the standard - nope.
Undefined outcome if any of the functions have overlapping side effects - you bet your ass it's undefined!.

So why are you telling me, and not your other kind helper?

Or better yet, why haven't you taken what has already been given and made an attempt to change it to your needs (and posted the result of that attempt)?

http://clusty.com/search?query=company+formation+chennai+india&sourceid=Mozilla-search
Find a specialist company that deals with company formations.

a) it will be a lot quicker. Here in the UK, you can buy a new company off the shelf in less than 24 hours, for the cost of a mornings work on your part.
b) it will be cheaper (you can carry on earning at what you're good at, rather than spending weeks getting to grips with legalities)
c) it will probably be done right first time. You don't want to find your new company in some legal mire a few years later.

to post in this thread, wins.

You're already too late - losers!
I WIN!

> main() or void main() or int main() it worked for me
Understand that there is a difference between the language and a compiler.

The language states that main returns int.

Your compiler (just one of many) is an implementation of that language. All compilers extend the language in some way, for a number of reasons.

Learn the language, and not the compiler.
Or at least learn that there is a difference, so that it is not a total surprise to you when you come to use another compiler.

It's a nice idea.
But there are at least 6 places where code tags are mentioned, and still about 99% of noobs fail to use them on the first post. People get +ve rep just for proving they can read - it's that rare!

Some continue to fail to use code tags despite numerous reminders.

Getting any of them to do anything more than press "submit" is hard work.

Further, where threads are marked as "solved", this can sometimes happen when the OP gets the first working answer (as opposed to the best correct answer).

Nor does marking a thread "solved" mean that some dimwit will happen along a few years later with some untagged "void main" horror just to show the world how little they know.

A lot of software is written along the lines of "You start coding, I'll go and find out what they want".

First you need a set of requirements ("What do you want?").
For non-programmers, these tend to be unfocussed and vague statements like "I want a word processor".

Your first task is to break these down into separate things you can test
- the program shall be able to load a file
- .... save a file
- the external data shall be represented as an XML document.

The next task is to produce a design ("How am I going to do it").
UML (as already mentioned) is one way of going about this.
- Think about objects (document, paragraph etc) and methods.
- Think about additional requirements such as "shall run on XP and Linux".

Imagine how say "save file" would traverse the functionality of your design. Does it actually work on paper? Keep refining it until everything does. It takes moments to fix a diagram, but it would take you weeks in the code much later on.

Next think about how you're going to implement it. What language(s) to use, what libraries to use.

> i is an independent value and i think it's value should increase infinitely
It has to exist in memory SOMEWHERE.

The most likely scenarios are

+=========+
|    i    |
+=========+
| arr[99] |
+=========+
|   ...   |
+=========+
| arr[0]  |
+=========+

OR

+=========+
| arr[99] |
+=========+
|   ...   |
+=========+
| arr[0]  |
+=========+
|    i    |
+=========+

In one case, writing the mythical arr[100] in fact trashes i instead.
In the other case, you miss i, but probably go on to trash something else instead.

In either case, the code is trash.

Start with something simple, like python.

You'll actually get some useful things done in a fairly short time frame.

It'll take 6 months of hard graft before you're in any shape to write a useful program in C. You HAVE to think of everything (and there's a lot to think about). Whole books have been written on the traps which exist in C for the unwary programmer.

C is the kind of language where if you ask "I want to hang myself", it will happily give you the rope to do it. And just for fun, it will occasionally replace the rope with bungee cord just to see what happens next.

Yeah, exactly 18 months too late, and exactly before you read this too :(
http://www.daniweb.com/forums/thread78223.html

One is a language
http://java.sun.com/

One is a framework
http://www.microsoft.com/net/

The question it as meaningless as asking a carpenter whether a hammer or chisel is better.

> Tell me how this advice will help the op solves his(her) problem, I'm curious...
The OP is basically looking for the front end of a C compiler.
This is far from being a trivial problem.

lex / yacc / bison are parser generator tools (perfect for this problem).

SELECT * FROM users WHERE postcount = 1 AND effort = 0%
Error - too many rows

Well reading a file a block at a time might be something like this.

#include <iostream>
#include <fstream>

int main ( ) {
  char buff[1000];
  std::ifstream in("a.out", std::ios::in | std::ios::binary);
  if ( in ) {
    int errorCount = 1;
    while ( in.read(buff,sizeof buff) || errorCount-- > 0 ) {
      std::streamsize n = in.gcount();
      if ( n > 0 ) {
        std::cout << "Read " << n << " bytes" << std::endl;
      }
    }
    in.close();
  }
}

I'm shocked that read() returns an error state on a partial read. The C-style fread() approach is far easier.

As for the key, you should be using some kind of counter so you do buff[i] ^= key[k]; Where k is a subscript looping over the length of the key.

> Does anybody see anything wrong with this approach or something I should do differently?
1. You should deal with the file in fixed sized blocks. Don't assume that you'll always be able to fit the file in memory in one go.

2. You only use the first letter of your key.

> .c vs .cpp file
If you're already making statements like "this works in C and not C++", then you really need to take a big step back and look at what it is you're trying to learn.

Some half-assed c/c++ hybrid (what you're going to end up with) isn't going to do you or anyone else any good in the long run.

C is traffic moving in one direction.
C++ is traffic moving in the other direction.
C/C++ is walking the median line, waiting to be road-kill.

Agrees. The first half isn't too shabby.
But it looks for all the world like the 2nd half was written by someone else without a clue.

It's trivial to achieve with -I. As an addition to the compiler include search path (for details, see your manual).

But if your only reason is "just because I want to", then it's not really recommended.