mboost-dp1

Hjælp med et stykke c++ kode


Gå til bund
Gravatar #1 - cyandk
29. aug. 2008 03:17
Ja, jeg har brug for lidt hjælp, min compiler siger der er en syntax fejl men skriver ikke hvilken row. Jeg har siddet og stirret på det men kan sq ikke finde fejlen..


#include <stdio.H>

int main(int argc, char* argv[])
{
for( int i=20; i<300 i++ )
{
double f = 800.0 / i;
int ipart = (int)f;
double fpart = f - ipart;

if( fpart > 0.5f )
{
printf( "%3d %.2f %3d %6.2f\n", i, fpart, (int)(i * .675), (1.0-fpart) * (int)(i*.675) );
}
}

return 0;
}
Gravatar #2 - XorpiZ
29. aug. 2008 05:16
for( int i=20; i<300 i++ )

Mangler et ; efter 300, så vidt jeg kan se :)
Gravatar #3 - Mort
29. aug. 2008 11:36
Det var da ikke en særlig sød compiler du har, som ikke fortæller dig hvor fejlen er henne. Hvilken computer bruger du og til hvilket operativ system ?
Gravatar #4 - arne_v
29. aug. 2008 13:18
#3

computer != compiler

:-)
Gravatar #5 - arne_v
29. aug. 2008 13:19
#0

#include <stdio.H>

skal nok også skrives som

#include <stdio.h>

eller er der problemer på case sensitive fil-systemer.
Gravatar #6 - cyandk
29. aug. 2008 19:36
#2 og #5 mange tak for hjælpen, glemte case sensitive ;)!

#3 jeg bruger p.t Borland C++ Compiler på XP x64...

Den plejer at vise row, men ikke lige i denne gang oO
Gravatar #7 - Mort
30. aug. 2008 19:41
#4: Du kunne godt lige have rettet i mit indlæg, når jeg skrev forkert =)
Gravatar #8 - cyandk
30. aug. 2008 21:43
fuck også, så gør den det igen..... Kan du hjælpe igen #2?

#include "quakedef.h"
#include "progsvm.h"
#include "pr_comp.h"


void check_player_name(void)
{

if(strlen(host_client->name) < 1) // ramzes: moved from progs.dat (cl_client.qc - first lines of PlayerPostThink)
{
strlcpy(host_client->name, Cvar_VariableString("default_name"), sizeof(host_client->name));
Host_ClientCommands("\nname %s\n", Cvar_VariableString("default_name"));
}

}


#define DEAD_NO 0
void CheckRules_Player(void)
{

double test = 0;

if(PRVM_EDICTFIELDVALUE(host_client->edict, prog->fieldoffsets.gameover)->float) // someone else quit the game already
return;

if(host_client->edict->fields.server->deadflag == DEAD_NO)
{
//host_client->edict->fields.server->play_time += sv.frametime;

//PRVM_EDICTFIELDVALUE(host_client->edict, prog->fieldoffsets.play_time)->_float += 1;


}

}


void OPR_PlayerPostThink(void)
{

check_player_name();

// if strcmp host_client->classname
if (!strcmp(PRVM_GetString(host_client->edict->fields.server->classname), "player"))
{
CheckRules_Player();

}

}
Gravatar #9 - arne_v
30. aug. 2008 21:49
Er de linie knæk et newz.dk problem ?
Gravatar #10 - arne_v
30. aug. 2008 21:50
->float

ser meget suspekt ud (float er et keyword).
Gravatar #11 - cyandk
30. aug. 2008 21:51
->float)

.. ja der skal stå ->_float jo.

Tak #10 :)

Og ja, de fleste linjeskift er news skyld :x
Gravatar #12 - kasperd
30. aug. 2008 22:32
[url=#10]#10[/url] arne_v
->float

ser meget suspekt ud (float er et keyword).
Hvorfor skal de interne typer også absolut være keywords? Variable og typer er jo to forskellige scopes, så man kan sagtens definere en type og en variabel med samme navn. Det eneste sted jeg kan se hvor der kan være tvivl er med sizeof der både kan anvendes på en variabel og på en type. Den her kode compilerer f.eks. fint:

#include <stdlib.h>
typedef struct foo{
int foo;
} foo;
int main()
{
foo *foo=calloc(1,sizeof(struct foo));
return foo->foo;
}
Gravatar #13 - arne_v
30. aug. 2008 22:44
#12

Det har de jo nu valgt. Formentligt for at undgå omdefineringer.

Og jeg synes heller ikke at det er specielt pænt at have variable og typer med samme navn.
Gravatar #14 - kasperd
30. aug. 2008 22:54
[url=#13]#13[/url] arne_v
Og jeg synes heller ikke at det er specielt pænt at have variable og typer med samme navn.
Som regel er det ikke nogen god idé, det vil jeg da give dig ret i. Og det stykke kode jeg skrev er da bestemt ikke noget jeg ville anvende i et seriøst program. Men i sjældne tilfælde kunne der være en grund til at navngive en variabel eller et felt i en struct med samme navn som en type.

En anden relateret ting, som kan være irriterende i nogle situationer er, at man ikke kan kalde et felt for errno. Jeg forstår godt hvorfor det er endt med at blive sådan, det demonstrerer bare, at makroer i C ikke altid kan opnå præcist det resultat man ønsker.
Gravatar #15 - cyandk
30. aug. 2008 23:13
såså der, vores kode er uber nice! :D
Gå til top

Opret dig som bruger i dag

Det er gratis, og du binder dig ikke til noget.

Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.

Opret Bruger Login