RafaelCLP

Certo, desses você só tem o HD? Se sim, troque a fonte por uma VS400, CX430 ou CX450 (acho que não vai encontrar nada de qualidade mais barato). Está custando quanto cada peça? Edit: tem o gabinete já né?

Você já tem algo que possa reaproveitar? Gabinete, HD, fonte? Tem como gastar mais do que R$ 1200?

Existem duas formas de resolver isso. Essas questões de competições de programação é comum o pessoal (incluindo eu, participei muito delas) usar algo como: #define MAXL 1000 #define MAXC 1000 // Ja define com o tamanho maximo que pode precisar! int matriz[MAXL][MAXC]; A segunda melhor opção é usar vector: int main() { vector< vector<int> > matriz; // le o tamanho da matriz cin >> L >> C; // le a matriz for (int i = 0; i < L; i++) { vector<int> linha; for (int j = 0; j < C; j++) { int x; cin >> x; // insere o inteiro na linha linha.push_back(x); } // insere a linha na matriz matriz.push_back(linha); } } // note que aqui temos um vector de vectors (ou seja, uma matriz).

É possível. Eu mantenho ele em 100% enquanto rodo fortnite, mas a temperatura fica bem louca, pulando de 65-70 pra >80 em um segundo e despencando de volta em seguida, o que acontece constantemente. É o único jogo que tenho esse problema. Edit: apesar de que olhando outros vídeos do g4560 rodando na hd 610 (https://www.youtube.com/watch?v=KzzPoPm5fiE) ele fica bem laggado mesmo, abaixo de 30 fps e com uso de cpu lá em cima. É bem estranho. Talvez fortnite tenha algo programado pra empurrar algumas tarefas da gpu pra cpu caso a gpu seja muito fraca, a fim de tentar equilibrar os dois. Não sei...

Pessoal, esqueçam o que eu falei. O g4560 consegue segurar fortnite sim se tiver uma gpu. Eu não faço ideia do porquê ele causar gargalo na própria iGPU naquele outro vídeo, e não causar gargalo na GT 1030, mas os dados estão aí, não dá pra contestar. Talvez alguma atualização recente tenha resolvido algum problema ou talvez esse jogo seja simplesmente estranho. Nesse vídeo está rodando até melhor que no meu i7-4710mq + gtx 850m.

Então excelente, pode pegar o g4560 mesmo. Entretanto, se conseguir comprar a placa de vídeo já junto com o resto do pc, eu recomendo o Ryzen 3 em vez do g4560 (vai sair praticamente o mesmo preço). Ele não tem GPU integrada, então só serve realmente se você comprar junto com uma placa de vídeo. adicionado 1 minuto depois Você já tem algo que possa reaproveitar? Gabinete, HD, fonte?

Nem, minha GPU não aguenta, é uma GTX 850M. Rodo com uma mistura de low e medium, mas distância de visão no far (eu testei e não afeta muito a performance). Mas aqui o ponto não é nem os gráficos (que em geral só afetam a GPU), e sim o CPU. Em alguns momentos o uso pula pra 100% e trava por uma fração de segundo. Quando eu jogava (até um mês e pouco atrás) morria direto porque quando atirava ou alguém atirava em mim o jogo travava... fora essas travadas a experiência é bem fluida com esse i7. Veja o Fortnite no g4560: No low, 480p, e pega menos de 30 fps. Em alguns momentos o CPU está em 90-100% com menos de 25 fps. Rola não. É sim, mas ainda é muito mal otimizado infelizmente. Edit: com o detalhe de que Fortnite não precisa de > 60 fps pra parecer fluido. Quando comecei a jogar eu configurava pra pegar entre 35 e 45 fps, e achava bem tranquilo pra jogar (o que não é comum em jogos fps).

Meu i7-4710MQ dá umas travadas em Fortnite (que roda a 50 - 60 fps), duvido que esse g4560 segure tranquilo. Acho que vai nem pegar 30 fps em média.

Ele tá montando na Terabyte, o preço está excelente mesmo pra essas memórias. Não tem 2x 8GB, então eu iria no pente de 16GB mesmo.

Outra coisa, eu abri o arquivo que você mandou aqui, e ele não começa com quebra de linha, começa direto com o cc. Então do jeito que você fez está perdendo o primeiro digito do cc do primeiro passageiro. Mude o while pra ser apenas: // sim, sem o fgetc... o espaço antes do %d já vai remover // o \n e outras porcarias pra você. while(fscanf(fp, " %d", &passageiro.cc) != EOF)

Então, você não pos do jeito que eu disse... tem que por != EOF.

A performance dos dois é praticamente idêntica. O i3-7100 é uns 10%-15% melhor só, e com certeza não vale a diferença de preço (g4560 R$ 270 vs i3-7100 R$ 500). Entretanto, se você não tiver comprado a placa-mãe ainda, eu recomendaria um Ryzen 3 1200 (aproveitando que está R$ 305 na promoção, geralmente é uns R$ 415 - R$ 430) com ou uma A320 baratinha (R$ 260) ou uma B350 pra fazer um leve overclock (R$ 430).

Teria como enviar o ficheiro no formato texto? Pela forma que você está usando o fgetc na condição do while, tem algum caractere extra em cada linha, certo? Se o seu arquivo estiver terminando com uma quebra de linha, quando você der fgetc ele pega o '\n' em vez de dar EOF. A solução que eu posso sugerir sem olhar o arquivo é: // ... resto do código ... while(fgetc(fp) != EOF && fscanf(fp, " %ld", &nr) != EOF) { // move o fscanf &nr daqui pra condição do while // ... resto do código ...

Isso mesmo, obrigado. Já vi o problema! Quem criou o arquivo conseguiu (não faço ideia de como) misturar little endian com big endian. O cc estava correto do jeito que você pos porque está em little endian no arquivo. O dia/data precisa inverter os bytes. Deve ficar assim o código: fread (&passageiro.cc, 4, 1, fps); fread (passageiro.nome, 1, 51, fps); fread (passageiro.partida, 1, 11, fps); fread (passageiro.chegada, 1, 11, fps); fread (&passageiro.dia, 2, 1, fps); // inverte os bytes do dia -- assumindo arquitetura que usa little endian passageiro.dia = ((passageiro.dia&255)<<8) + (passageiro.dia>>8); Edit: um outro detalhe é que aparenta ter um último byte 00 após cada entrada (o que por enquanto não dá problema, mas vai dar quando você fizer um loop pra pegar todos os passageiros). Nesse caso não esqueça de dar um último fread pegando e descartando um byte (bom, fica de sugestão pra quando der erro, não se preocupe em entender o problema até ele aparecer). Edit: assumindo que o primeiro byte do dia é sempre 0 (afinal, por que não seria?) um jeito mais portável (porque não tem que inverter bytes) é: fread (&passageiro.cc, 4, 1, fps); fread (passageiro.nome, 1, 51, fps); fread (passageiro.partida, 1, 11, fps); fread (passageiro.chegada, 1, 11, fps); // descarta um byte, que é sempre 0 char dia; fread (&dia, 1, 1, fps); // lê o dia fread (&dia, 1, 1, fps); // não leia direto pro passageiro.dia pois passageiro.dia = dia; // se ele não estiver zerado vai ficar errado

Compacta pra .zip ou .rar usando o winrar

Prefiro que me envie o ficheiro. Se está em binário mesmo a situação fica diferente do que eu tinha inicialmente entendido. Gostaria de confirmar exatamente como está.

O do passageiro.cc ficou errado, deveria ser: fscanf(fps, " %d", &passageiro.cc); Queria ver o arquivo "okb" como está também.

Como ficou a alteração? E como está o arquivo com os dados?

Não use o fread pra isso, use o fscanf. O que acontece com o fread é que ele lê 2 bytes e escreve esses 2 bytes no passageiro.dia. Só que, por exemplo, se você tem lá no arquivo "17" (que em binário fica 00110001 00110111), ele vai salvar no seu short o valor 00110001 00110111 (12599 em decimal, mas interpretado como 14129 porque x86 usa o formato little endian, em que o byte mais significativo fica no final, não no começo). Enfim: // apague fread (&passageiro.dia, 2, 1, fps); // ponha fscanf(fps, " %hd", &passageiro.dia); // e repare que o cc também está com o mesmo problema; eu recomendo trocar tudo por fscanf

O cin não tem essa "função". O jeito mais adequado de se fazer o que você quer é converter todas as letras das strings pra minúsculas, e então comparar com "lasanha", "suco" etc. Para isso, veja tolower que converte um caractere (se for letra) pra minuscula. #include <cctype> // para usar tolower // ... resto do codigo ... string transformar_em_minusculas(string s) { string nova_s; for (int i = 0; i < s.length(); i++) { nova_s += tolower(s[i]); } return nova_s; } int main() { // ... resto do codigo ... cin >> comida >> bebida; comida = transformar_em_minusculas(comida); // ... resto do codigo ... } Outra possível solução seria usar stricmp de C (de string insensitive comparison - o "i" é de case insensitive, ou seja, não é sensível a maiúscula/minúscula, marcando ambas como iguais; tem também o strcmp, que é case sensitive): if (!stricmp(comida.c_str(), "Lasanha")) { conta = conta + 8.0; } // etc

Em resumo: você que decide, ambas as abordagens funcionam. A vantagem de aprender as duas ao mesmo tempo é que você não perde tempo com uma linguagem tão incompleta (para os dias de hoje) como C, e vai direto pra algo mais produtivo (C++); a vantagem de aprender primeiro C e depois C++ é que você consegue se aprofundar mais na linguagem, pois C não vem com tantos recursos prontos / na biblioteca padrão quanto C++. Isso contribui para o entendimento tanto de C quanto de C++. Em detalhes: Se um código foi escrito em C, muito provavelmente compila também como C++. A ideia de C++ era ser C com algumas coisas a mais (como OO), e ser retrocompatível com C. Infelizmente nem tudo é compatível, mas quase sempre que eu vejo um arquivo .c e renomeio pra .cpp funciona sem ter que alterar nada. Em resumo, C++ = C com coisas a ++ (e algumas poucas incompatibilidades com C). Note também que o C++ que você usa provavelmente é o C++03 (a versão de C++ de 2003) ou até C++98 (de 1998). Após C++03 foi lançado C++11 (em 2011), com muitos recursos novos, e hoje já é o padrão em várias empresas, mas nem tanto no mundo acadêmico. C++14 (lançado em 2014) traz algumas coisas novas, mas ainda não é tão usado, e em breve teremos C++17. Qual a importância disso tudo? C++03 é extremamente usado em projetos anteriores a 2012-2013 (quando C++11 começou a se popularizar). Então se você aprender direto C++11 e depois tiver que mexer em um projeto C++03 (bem comum), vai ficar meio assustado ao ver que muitos recursos com os quais você está acostumado não funcionam. Da mesma forma, se começar com C++ (qualquer um) e depois tentar mexer em C, vai sair só gambiarra tentando fazer códigos simples funcionarem. Eu aprendi primeiro C (em 2008 - 2009), usei por cerca de 4 anos, e então passei a usar C++03 (lá por 2012 - 2013). Isso me ajudou a aprender bem C. Só fui pra C++11 em 2015, então consigo escrever código em C, C++03 e C++11 sem problema, e sei exatamente que recursos foram introduzidos em qual versão quando uso. Outras linguagens O que eu mais recomendo mesmo é não começar nem por C, nem por C++. Muito menos ainda por Java (eca!). Existem linguagens mais simples e fáceis de aprender que te tornam bem mais produtivo em bem menos tempo, como Python. Eu recomendaria aprender Python e C para começar (além do mais, saber várias linguagens não machuca ninguém... entrei na faculdade sabendo pelo menos umas 15 - depois das 3 ou 4 primeiras, a dificuldade de aprender uma nova linguagem reduz drasticamente).

@Vegetto Também acho que o i5 8400 não deixará a desejar independente do que aconteça na próxima geração (embora acredite que daqui a 3 anos possa começar a sofrer com alguns jogos sim, enquanto o Ryzen 7 deve durar muito mais), mas se formos justamente pensar no agora, sem considerar upgrade algum, o Ryzen 1700 @ 3.6GHz ainda oferece 50%-70% mais poder multithread por um preço levemente mais baixo. Sim, perde uns 10% em poder singlethread e acaba pegando 10-15% menos fps em vários jogos atuais. Mas a minha pergunta é: será que vale a pena trocar 50-70% mais poder multithread (= muito mais potencial pra programas/jogos futuros) por 10-15% mais fps em jogos atuais? Se a resposta for sim, ótimo, vá no i5 8400. Caso contrário eu não vejo atualmente nenhuma outra vantagem pra ir com esse processador enquanto não lançarem placas-mãe com chipset de entrada. Já não bastasse estar pagando preço de lançamento nesse processador (que em poucos meses deve baixar pelo menos uns 150 reais, fora as promoções), ainda está pagando 400 reais a mais numa placa que ele não consegue sequer tirar proveito... dizer que isso está compensando mais do que ir no Ryzen é realmente querer dizer que a plataforma atual da AMD não presta.

@Vegetto A respeito de frametimes eu concordo com você de que isso depende de jogo, então por falta de dados vou "aceitar" que os dois processadores estão equilibrados. Agora, dizer que a longevidade da plataforma é irrelevante, eu não posso deixar passar, dado que os Ryzen são excelentes processadores que trouxeram a AMD de volta à disputa. Claro que não há garantia alguma de que as próximas gerações serão muito superiores às atuais, mas há grande chance, pois caso não aconteça a AMD vai ficar muito pra tras novamente. O problema maior é que a Intel vai matar a plataforma atual ao lançar a próxima geração. Parece até que só lançaram a oitava geração às pressas pra equilibrar a disputa, e a próxima geração é que vai vir pra destruir os Ryzen atuais de vez. Se os rumores estiverem certos, o i5 8400 (que hoje bate de frente com um i7 7700) vai ficar equilibrado com os i3 9ª geração... pra deixar bem claro, vou repetir: se os rumores estiverem certos, esse i5, ano que vem, passaria a estar no nível de um i3. Isso é o que me assusta na plataforma atual da Intel. Investimento de mais de R$ 700 numa placa-mãe, mais quase R$ 900 em um i5 que ano que vem possivelmente perderá pra i3, e não vai sequer poder fazer upgrade (exceto pra um i7 com performance de i5) sem trocar toda a plataforma. Eu não estou sequer apostando que a AMD vai novamente superar a Intel nas próximas gerações. Estou apenas apostando que em 2 ou 3 anos vão começar a aparecer alguns jogos que precisam mais do que um i3 pra se tirar o máximo de proveito.

O i7 é melhor, mas também vai sair mais caro...

Eu sou a favor do Ryzen por enquanto (até a Intel liberar os chipsets mais baratos). Vou te dar os motivos pra escolha de cada um dos processadores. Por que escolher o Ryzen 1700? Longevidade da plataforma. A AMD prometeu dar total suporte à plataforma (AM4) e manter a compatibilidade com novos processadores até 2020. Você poderá fazer upgrade pros Ryzen 2ª geração (e possivelmente até 3ª geração) sem ter que trocar nada além do próprio processador. Mais poder multithread. O Ryzen 7, por ter 8 núcleos com SMT (16 threads), tem muito mais poder multithread que o i5-8400 (6 núcleos / 6 threads). Você nota uma diferença significativa de desempenho em programas pesados que fazem uso desses núcleos, e pode possivelmente notar alguma diferença se fizer streaming (o R7 tem thread de sobra pra dividir entre o jogo e os programas de captura de vídeo / encoding / streaming). Melhores frametimes (discutivelmente). Sim, o i5-8400 vai produzir mais frames por segundo, mas o Ryzen 7 consegue manter uma maior consistência nos tempos de seus frames, oferecendo (em teoria pelo menos) uma experiência mais fluida. Leia esta pergunta (e a resposta) no reddit a respeito de frametimes, se entender inglês. Desbloqueado pra overclock. Preço. R$ 890 (Ryzen 7 1700) + R$ 500 (B350). Por R$ 1400 ou até menos (se quiser poupar na placa-mãe) você consegue seu "kit". Mas um kit com i5-8400 vai sair por uns R$ 1600 - R$ 1650, então a diferença não é tão grande. Por que escolher o i5-8400? Mais poder singlethread. A grande vantagem dos Intel Core. Se um jogo ou software faz forte uso de um núcleo, ou se não usa mais do que 6 núcleos, vai se sair bem melhor com este processador. Isso inclui grande parte dos jogos atuais!! Maior frame rate. Indiscutivelmente. Na maioria dos jogos, os Intel Core pegam mais fps do que os Ryzen. Se tiver interesse por benchmarks: 1800X vs 8400. Pus o 1800X porque o 1700 alcança esse mesmo desempenho ao fazer overclock pra 3.6 GHz (chega em 3.9 - 4.1 GHz, dependendo de quão sortudo você for).