evertonportela/42sp_projects

Projetos desenvolvidos desde a Piscina Mar2023

Hi there

Thanks for visiting! 😄

I currently work as a developer at @nstech. Not long ago, I was studying at 42 São Paulo🧑‍🚀 a degree in Software Engineering, you will find some projects here too. I have worked with some languages ​​and technologies such as: C, Java, Javascript, Typescript, Docker, React, AdonisJS, PostgreSQL, Oracle, AWS.

You can find more about me on my Linkedin, feel free to make connections.

Have a variety of interests:

• 🎓 Bachelor in Information Systems
• ✏️ I worked with project management
• 📚 Social Projects and Education
• 📷 Photography
• 🥁 Drums
• 🦉 Owls
• 🐾 Pet

42sp_projects's Issues

Avaliar 3x - outros projetos

Abrir horários de avaliação na intranet para conhecer e avaliar outras pessoas e outros projetos

• Avaliação 1
• Avaliação 2
• Avaliação 3

Part 3 - Bonus Part

• ft_lstnew
• ft_lstadd_front
• ft_lstsize
• ft_lstlast
• ft_lstadd_back
• ft_lstdelone
• ft_lstclear
• ft_lstiter
• ft_lstmap

Mandatory Part

funtion name: get_next_line
prototype: char *get_next_line(int fd);
turn in files: get_next_line.c get_next_line_utils.c get_next_line.h
Parameters: fd: O descritor de arquivo para ler
Return: Leitura de linha: comportamento correto. NULL: não há mais nada para ler ou um erro ocorreu
External functs: read, malloc, free
Description: Escreva uma função que retorne uma linha lida de um descritor de arquivo

• Chamadas repetidas (por exemplo, usando um loop) para sua função get_next_line() devem permitir que você leia o arquivo de texto apontado pelo descritor de arquivo, uma linha por vez.

• Sua função deve retornar a linha que foi lida.
  Se não houver mais nada para ler ou se ocorreu um erro, ele deve retornar NULL.

• Certifique-se de que sua função funcione conforme o esperado ao ler um arquivo e ao ler a partir da entrada padrão.

• Observe que a linha retornada deve incluir o caractere final \n, exceto se o final do arquivo for alcançado e não terminar com um caractere \n.

• Seu arquivo de cabeçalho get_next_line.h deve conter pelo menos o protótipo da função get_next_line().

• Adicione todas as funções auxiliares necessárias no arquivo get_next_line_utils.c.

!!! Um bom começo seria saber o que é uma variável estática.

• Como você terá que ler arquivos em get_next_line(), adicione esta opção à sua chamada de compilador: -D BUFFER_SIZE=n
  Ele definirá o tamanho do buffer para read().
  O valor do tamanho do buffer será modificado por seus pares avaliadores e pela Moulinette para testar seu código.

- [ ] Devemos ser capazes de compilar este projeto com e sem o sinalizador -D BUFFER_SIZE além dos sinalizadores usuais. Você pode escolher o valor padrão de sua escolha.

• Você compilará seu código da seguinte maneira (um tamanho de buffer de 42 é usado como exemplo): cc -Wall -Wextra -Werror -D BUFFER_SIZE=42 .c

• Consideramos que get_next_line() tem comportamento indefinido se o arquivo apontado pelo descritor de arquivo mudou desde a última chamada enquanto read() não chegou ao final do arquivo.

• Também consideramos que get_next_line() tem um comportamento indefinido ao ler um arquivo binário. No entanto, você pode implementar uma maneira lógica de lidar com esse comportamento, se desejar.

Sua função ainda funciona se o valor de BUFFER_SIZE for 9999? Se for 1? 10000000? Você sabe por quê?

Tente ler o mínimo possível cada vez que get_next_line() for chamado. Se você encontrar uma nova linha, deverá retornar a linha atual.
Não leia o arquivo inteiro e depois processe cada linha.

Proibido

• Você não tem permissão para usar sua libft neste projeto.
• lseek() é proibido.
• Variáveis globais são proibidas.

Norminette

Regras para entrega

Seu projeto deve ser escrito em C.

• Seu projeto deve ser redigido de acordo com a Norma. Se você tiver arquivos/funções de bônus, eles serão incluídos na verificação da norma e você receberá um 0 se houver um erro de norma dentro.

• Suas funções não devem ser encerradas inesperadamente (falha de segmentação, erro de barramento, double free, etc.) além de comportamentos indefinidos. Se isso acontecer, seu projeto será considerado não funcional e receberá nota 0 na avaliação.

• Todo o espaço de memória alocado no heap deve ser liberado adequadamente quando necessário. Nenhum vazamento será tolerado.

• Se o assunto exigir, você deve enviar um Makefile que irá compilar seus arquivos de origem para a saída necessária com os sinalizadores -Wall, -Wextra e -Werror, use cc e seu Makefile não deve revincular.

• Seu Makefile deve conter pelo menos as regras $(NAME), all, clean, fclean e re.

• Para ativar bônus em seu projeto, você deve incluir uma regra de bônus em seu Makefile, que adicionará todos os vários cabeçalhos, bibliotecas ou funções que são proibidas na parte principal do projeto. Os bônus devem estar em um arquivo diferente _bonus.{c/h} se o assunto não especificar mais nada. A avaliação da parte obrigatória e bônus é feita separadamente.

• Se seu projeto permite que você use sua libft, você deve copiar suas fontes e seu Makefile associado em uma pasta libft com seu Makefile associado. O Makefile do seu projeto deve compilar a biblioteca usando seu Makefile e, em seguida, compilar o projeto.

• Incentivamos você a criar programas de teste para o seu projeto, mesmo que este trabalho não precise ser enviado e não seja avaliado. Isso lhe dará a chance de testar facilmente seu trabalho e o trabalho de seus colegas. Você achará esses testes especialmente úteis durante sua defesa. De fato, durante a defesa, você é livre para usar seus testes e/ou os testes do colega que está avaliando.

• Envie seu trabalho para o repositório git atribuído. Apenas o trabalho no repositório git será avaliado. Se o Deepthought for designado para avaliar seu trabalho, isso será feito após suas avaliações de pares. Se ocorrer um erro em qualquer seção do seu trabalho durante a avaliação do Deepthought, a avaliação será interrompida.

Part I - Mandatory Part - libc functions

Você deve recodificar as seguintes funções:
libft.a
Makefile libft.h ft_*.c

Makefile - NAME, all, clean, fclean, re
Descrição: Escreva sua própria biblioteca: uma coleção de funções que serão uma ferramenta útil para o seu cursus.

• É proibido declarar variáveis globais.
• Se você precisar de funções auxiliares para dividir uma função mais complexa, defina-as como funções estáticas. Dessa forma, seu escopo será limitado ao arquivo apropriado.
• Coloque todos os seus arquivos na raiz do seu repositório.
• É proibido entregar arquivos não utilizados.
• Todos os arquivos.c devem ser compilados com as flags -Wall -Wextra -Werror.
• Você deve usar o comando ar para criar sua biblioteca. Usar o comando libtool é proibido.
• Seu libft.a deve ser criado na raiz do seu repositório.

Para começar, você deve refazer um conjunto de funções da libc. Suas funções terão os mesmos protótipos e implementarão os mesmos comportamentos das originais. Eles devem obedecer à maneira como são definidos em seu homem. A única diferença serão seus nomes. Eles começarão com o prefixo 'ft_'. Por exemplo, strlen se torna ft_strlenPara começar, você deve refazer um conjunto de funções da libc. Suas funções terão os mesmos protótipos e implementarão os mesmos comportamentos das originais. Eles devem obedecer à maneira como são definidos em seu homem. A única diferença serão seus nomes. Eles começarão com o prefixo 'ft_'. Por exemplo, strlen se torna ft_strlen

• Makefile

• isalpha - [x] test

• isdigit - [x] test

• isalnum - [x] test

• isascii - [x] test

• isprint - [x] test

• strlen - [x] test

• memset - [x] test

• bzero - [x] test

• memcpy - [x] test

• memmove - [x] test

• strlcpy - [x] test

• strlcat - [x] test

• toupper - [x] test

• tolower - [x] test

• strchr - [x] test

• strrchr - [x] test

• strncmp - [x] test

• memchr - [x] test

• memcmp - [x] test

• strnstr - [x] test

• atoi - [x] test

Para implementar as duas funções a seguir, você usará malloc():

• calloc - [x] test
• strdup - [x] test

Norminette

• - Norminette Part I
• - Norminette Part II

Avaliar 3x - meu projeto

Abrir horários de avaliação na intranet para conhecer e ser avaliado por outras pessoas

Regras para entrega

• Seu projeto deve ser escrito em C.
• Seu projeto deve ser redigido de acordo com a Norma. Se você tiver arquivos/funções de bônus, eles serão incluídos na verificação da norma e você receberá um 0 se houver um erro de norma dentro.
• Suas funções não devem ser encerradas inesperadamente (falha de segmentação, erro de barramento, double free, etc.) além de comportamentos indefinidos. Se isso acontecer, seu projeto será considerado não funcional e receberá nota 0 na avaliação.
• Todo o espaço de memória alocado no heap deve ser liberado adequadamente quando necessário. Nenhum vazamento será tolerado.
• Se o assunto exigir, você deve enviar um Makefile que irá compilar seus arquivos de origem para a saída necessária com os sinalizadores -Wall, -Wextra e -Werror, use cc e seu Makefile não deve revincular.
• Seu Makefile deve conter pelo menos as regras $(NAME), all, clean, fclean e re.
• Para ativar bônus em seu projeto, você deve incluir uma regra de bônus em seu Makefile, que adicionará todos os vários cabeçalhos, bibliotecas ou funções proibidas na parte principal do projeto. Os bônus devem estar em um arquivo diferente _bonus.{c/h} se o assunto não especificar mais nada. A avaliação da parte obrigatória e bônus é feita separadamente.
• Se seu projeto permite que você use sua libft, você deve copiar suas fontes e seu Makefile associado em uma pasta libft com seu Makefile associado. O Makefile do seu projeto deve compilar a biblioteca usando seu Makefile e, em seguida, compilar o projeto.
• Incentivamos você a criar programas de teste para o seu projeto, mesmo que este trabalho não precise ser enviado e não seja avaliado. Isso lhe dará a chance de testar facilmente seu trabalho e o trabalho de seus colegas. Você achará esses testes especialmente úteis durante sua defesa. De fato, durante a defesa, você é livre para usar seus testes e/ou os testes do par que está avaliando.
• Envie seu trabalho para o repositório git atribuído. Apenas o trabalho no repositório git será avaliado. Se o Deepthought for designado para avaliar seu trabalho, isso será feito após suas avaliações de pares. Se ocorrer um erro em qualquer seção do seu trabalho durante a avaliação do Deepthought, a avaliação será interrompida.

Testar projeto finalizado

• - Test Part I
  Tripoulle - inserindo testes na calloc
• - Test Part II

Tester usados: War Machine, Tripouille, Unit Tester

Part 2 - Mandatory Part - Addtional functions

Nesta segunda parte, você deve desenvolver um conjunto de funções que não estão na libc ou que fazem parte dela, mas de uma forma diferente.
Você deve recodificar as seguintes funções:

Algumas das seguintes funções podem ser úteis para escrever as funções da Parte 1.

• ft_substr
• ft_strjoin
• ft_strtrim
• ft_split
• ft_itoa
• ft_strmapi
• ft_striteri
• ft_putchar_fd
• ft_putstr_fd
• ft_putendl_fd
• ft_putnbr_fd