Program that generates brainfuck code that outputs given text Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm US/Eastern) Announcing the arrival of Valued Associate #679: Cesar Manara Unicorn Meta Zoo #1: Why another podcast?Brainfuck interpreter in C 3Optimizing string replacement program that uses recursionClassifying lexemes in a given C programInterpreting Brainfuck code to C#, then compiling to a .exeC program that reverses a stringBrainfuck code optimization in PythonC program that recovers lost JPEG filesProgram to find megaPrime numbers between 2 given integersDice roll game that generates random numberProgram that prints out the initials of a given nameText to Brainfuck translator

Girl Hackers - Logic Puzzle

Project Euler #1 in C++

How does the math work when buying airline miles?

How to compare two different files line by line in unix?

Drawing spherical mirrors

Trademark violation for app?

1-probability to calculate two events in a row

How did Fremen produce and carry enough thumpers to use Sandworms as de facto Ubers?

What is the difference between a "ranged attack" and a "ranged weapon attack"?

How long can equipment go unused before powering up runs the risk of damage?

A term for a woman complaining about things/begging in a cute/childish way

Semigroups with no morphisms between them

Is there public access to the Meteor Crater in Arizona?

What is an "asse" in Elizabethan English?

Misunderstanding of Sylow theory

Most bit efficient text communication method?

Central Vacuuming: Is it worth it, and how does it compare to normal vacuuming?

Dyck paths with extra diagonals from valleys (Laser construction)

Why do early math courses focus on the cross sections of a cone and not on other 3D objects?

Would it be easier to apply for a UK visa if there is a host family to sponsor for you in going there?

Is CEO the "profession" with the most psychopaths?

As Singapore Airlines (Krisflyer) Gold, can I bring my family into the lounge on a domestic Virgin Australia flight?

Putting class ranking in CV, but against dept guidelines

Why are my pictures showing a dark band on one edge?



Program that generates brainfuck code that outputs given text



Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm US/Eastern)
Announcing the arrival of Valued Associate #679: Cesar Manara
Unicorn Meta Zoo #1: Why another podcast?Brainfuck interpreter in C 3Optimizing string replacement program that uses recursionClassifying lexemes in a given C programInterpreting Brainfuck code to C#, then compiling to a .exeC program that reverses a stringBrainfuck code optimization in PythonC program that recovers lost JPEG filesProgram to find megaPrime numbers between 2 given integersDice roll game that generates random numberProgram that prints out the initials of a given nameText to Brainfuck translator



.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;








6












$begingroup$


I created program that generates brainfuck code that outputs given text.
Arguments for the program are input file with the text and output file where code will be generated to.
Here is the code:



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

#define ALLOCATION_ERROR 1
#define FILE_ERROR 2
#define OTHER_ERROR 3

static inline FILE*
get_file_pointer(const char* filename,const char* mode)
FILE* file_pointer=fopen(filename,mode);
if(file_pointer==NULL)
fprintf(stderr,"Error: failed to open file %sn",filename);
exit(FILE_ERROR);

return file_pointer;

static inline char*
int_to_brainfuck(int difference)
if(difference==0)
return ".";
else
char character_in_loop=difference>0?'+':'-';
difference=difference>0?difference:-difference;
const unsigned int loop_body_length=17;
const unsigned int number_of_ones=(unsigned int)(difference%10);
const unsigned int number_of_tens=(unsigned int)(difference/10);
char* brainfuck_code=calloc(number_of_tens+loop_body_length+number_of_ones+2,sizeof*brainfuck_code);
if(number_of_tens>0)
brainfuck_code[strlen(brainfuck_code)]='>';
memset(brainfuck_code+strlen(brainfuck_code),'+',number_of_tens);
strcat(brainfuck_code+strlen(brainfuck_code),"[<");
memset(brainfuck_code+strlen(brainfuck_code),character_in_loop,10);
strcat(brainfuck_code+strlen(brainfuck_code),">-]<");

memset(brainfuck_code+strlen(brainfuck_code),character_in_loop,number_of_ones);
brainfuck_code[strlen(brainfuck_code)]='.';
return brainfuck_code;


static inline void
generate_code(FILE* input_file,FILE* output_file)
int current_char,last_char=0;
while((current_char=fgetc(input_file))!=EOF)
char* brainfuck_code=int_to_brainfuck(current_char-last_char);
fputs(brainfuck_code,output_file);
if(brainfuck_code[0]!='.')
free(brainfuck_code);
last_char=current_char;


static inline void
parse_args(int argc)
if(argc!=3)
puts("Usage: bfgen <input> <output>");
exit(OTHER_ERROR);


int
main(int argc,char** argv)
parse_args(argc);
FILE* input_file=get_file_pointer(argv[1],"r");
FILE* output_file=get_file_pointer(argv[2],"wb");
generate_code(input_file,output_file);
fclose(input_file);
fclose(output_file);
return 0;










share|improve this question











$endgroup$











  • $begingroup$
    Please do not update the code in your question to incorporate feedback from answers, doing so goes against the Question + Answer style of Code Review. This is not a forum where you should keep the most updated version in your question. Please see what you may and may not do after receiving answers.
    $endgroup$
    – Simon Forsberg
    Apr 14 at 15:12










  • $begingroup$
    Thanks for information. I'm sorry, I did not know that.
    $endgroup$
    – DeBos99
    Apr 14 at 15:14

















6












$begingroup$


I created program that generates brainfuck code that outputs given text.
Arguments for the program are input file with the text and output file where code will be generated to.
Here is the code:



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

#define ALLOCATION_ERROR 1
#define FILE_ERROR 2
#define OTHER_ERROR 3

static inline FILE*
get_file_pointer(const char* filename,const char* mode)
FILE* file_pointer=fopen(filename,mode);
if(file_pointer==NULL)
fprintf(stderr,"Error: failed to open file %sn",filename);
exit(FILE_ERROR);

return file_pointer;

static inline char*
int_to_brainfuck(int difference)
if(difference==0)
return ".";
else
char character_in_loop=difference>0?'+':'-';
difference=difference>0?difference:-difference;
const unsigned int loop_body_length=17;
const unsigned int number_of_ones=(unsigned int)(difference%10);
const unsigned int number_of_tens=(unsigned int)(difference/10);
char* brainfuck_code=calloc(number_of_tens+loop_body_length+number_of_ones+2,sizeof*brainfuck_code);
if(number_of_tens>0)
brainfuck_code[strlen(brainfuck_code)]='>';
memset(brainfuck_code+strlen(brainfuck_code),'+',number_of_tens);
strcat(brainfuck_code+strlen(brainfuck_code),"[<");
memset(brainfuck_code+strlen(brainfuck_code),character_in_loop,10);
strcat(brainfuck_code+strlen(brainfuck_code),">-]<");

memset(brainfuck_code+strlen(brainfuck_code),character_in_loop,number_of_ones);
brainfuck_code[strlen(brainfuck_code)]='.';
return brainfuck_code;


static inline void
generate_code(FILE* input_file,FILE* output_file)
int current_char,last_char=0;
while((current_char=fgetc(input_file))!=EOF)
char* brainfuck_code=int_to_brainfuck(current_char-last_char);
fputs(brainfuck_code,output_file);
if(brainfuck_code[0]!='.')
free(brainfuck_code);
last_char=current_char;


static inline void
parse_args(int argc)
if(argc!=3)
puts("Usage: bfgen <input> <output>");
exit(OTHER_ERROR);


int
main(int argc,char** argv)
parse_args(argc);
FILE* input_file=get_file_pointer(argv[1],"r");
FILE* output_file=get_file_pointer(argv[2],"wb");
generate_code(input_file,output_file);
fclose(input_file);
fclose(output_file);
return 0;










share|improve this question











$endgroup$











  • $begingroup$
    Please do not update the code in your question to incorporate feedback from answers, doing so goes against the Question + Answer style of Code Review. This is not a forum where you should keep the most updated version in your question. Please see what you may and may not do after receiving answers.
    $endgroup$
    – Simon Forsberg
    Apr 14 at 15:12










  • $begingroup$
    Thanks for information. I'm sorry, I did not know that.
    $endgroup$
    – DeBos99
    Apr 14 at 15:14













6












6








6


1



$begingroup$


I created program that generates brainfuck code that outputs given text.
Arguments for the program are input file with the text and output file where code will be generated to.
Here is the code:



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

#define ALLOCATION_ERROR 1
#define FILE_ERROR 2
#define OTHER_ERROR 3

static inline FILE*
get_file_pointer(const char* filename,const char* mode)
FILE* file_pointer=fopen(filename,mode);
if(file_pointer==NULL)
fprintf(stderr,"Error: failed to open file %sn",filename);
exit(FILE_ERROR);

return file_pointer;

static inline char*
int_to_brainfuck(int difference)
if(difference==0)
return ".";
else
char character_in_loop=difference>0?'+':'-';
difference=difference>0?difference:-difference;
const unsigned int loop_body_length=17;
const unsigned int number_of_ones=(unsigned int)(difference%10);
const unsigned int number_of_tens=(unsigned int)(difference/10);
char* brainfuck_code=calloc(number_of_tens+loop_body_length+number_of_ones+2,sizeof*brainfuck_code);
if(number_of_tens>0)
brainfuck_code[strlen(brainfuck_code)]='>';
memset(brainfuck_code+strlen(brainfuck_code),'+',number_of_tens);
strcat(brainfuck_code+strlen(brainfuck_code),"[<");
memset(brainfuck_code+strlen(brainfuck_code),character_in_loop,10);
strcat(brainfuck_code+strlen(brainfuck_code),">-]<");

memset(brainfuck_code+strlen(brainfuck_code),character_in_loop,number_of_ones);
brainfuck_code[strlen(brainfuck_code)]='.';
return brainfuck_code;


static inline void
generate_code(FILE* input_file,FILE* output_file)
int current_char,last_char=0;
while((current_char=fgetc(input_file))!=EOF)
char* brainfuck_code=int_to_brainfuck(current_char-last_char);
fputs(brainfuck_code,output_file);
if(brainfuck_code[0]!='.')
free(brainfuck_code);
last_char=current_char;


static inline void
parse_args(int argc)
if(argc!=3)
puts("Usage: bfgen <input> <output>");
exit(OTHER_ERROR);


int
main(int argc,char** argv)
parse_args(argc);
FILE* input_file=get_file_pointer(argv[1],"r");
FILE* output_file=get_file_pointer(argv[2],"wb");
generate_code(input_file,output_file);
fclose(input_file);
fclose(output_file);
return 0;










share|improve this question











$endgroup$




I created program that generates brainfuck code that outputs given text.
Arguments for the program are input file with the text and output file where code will be generated to.
Here is the code:



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

#define ALLOCATION_ERROR 1
#define FILE_ERROR 2
#define OTHER_ERROR 3

static inline FILE*
get_file_pointer(const char* filename,const char* mode)
FILE* file_pointer=fopen(filename,mode);
if(file_pointer==NULL)
fprintf(stderr,"Error: failed to open file %sn",filename);
exit(FILE_ERROR);

return file_pointer;

static inline char*
int_to_brainfuck(int difference)
if(difference==0)
return ".";
else
char character_in_loop=difference>0?'+':'-';
difference=difference>0?difference:-difference;
const unsigned int loop_body_length=17;
const unsigned int number_of_ones=(unsigned int)(difference%10);
const unsigned int number_of_tens=(unsigned int)(difference/10);
char* brainfuck_code=calloc(number_of_tens+loop_body_length+number_of_ones+2,sizeof*brainfuck_code);
if(number_of_tens>0)
brainfuck_code[strlen(brainfuck_code)]='>';
memset(brainfuck_code+strlen(brainfuck_code),'+',number_of_tens);
strcat(brainfuck_code+strlen(brainfuck_code),"[<");
memset(brainfuck_code+strlen(brainfuck_code),character_in_loop,10);
strcat(brainfuck_code+strlen(brainfuck_code),">-]<");

memset(brainfuck_code+strlen(brainfuck_code),character_in_loop,number_of_ones);
brainfuck_code[strlen(brainfuck_code)]='.';
return brainfuck_code;


static inline void
generate_code(FILE* input_file,FILE* output_file)
int current_char,last_char=0;
while((current_char=fgetc(input_file))!=EOF)
char* brainfuck_code=int_to_brainfuck(current_char-last_char);
fputs(brainfuck_code,output_file);
if(brainfuck_code[0]!='.')
free(brainfuck_code);
last_char=current_char;


static inline void
parse_args(int argc)
if(argc!=3)
puts("Usage: bfgen <input> <output>");
exit(OTHER_ERROR);


int
main(int argc,char** argv)
parse_args(argc);
FILE* input_file=get_file_pointer(argv[1],"r");
FILE* output_file=get_file_pointer(argv[2],"wb");
generate_code(input_file,output_file);
fclose(input_file);
fclose(output_file);
return 0;







c brainfuck compiler






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Apr 14 at 15:12









Simon Forsberg

48.9k7130287




48.9k7130287










asked Apr 14 at 2:05









DeBos99DeBos99

1318




1318











  • $begingroup$
    Please do not update the code in your question to incorporate feedback from answers, doing so goes against the Question + Answer style of Code Review. This is not a forum where you should keep the most updated version in your question. Please see what you may and may not do after receiving answers.
    $endgroup$
    – Simon Forsberg
    Apr 14 at 15:12










  • $begingroup$
    Thanks for information. I'm sorry, I did not know that.
    $endgroup$
    – DeBos99
    Apr 14 at 15:14
















  • $begingroup$
    Please do not update the code in your question to incorporate feedback from answers, doing so goes against the Question + Answer style of Code Review. This is not a forum where you should keep the most updated version in your question. Please see what you may and may not do after receiving answers.
    $endgroup$
    – Simon Forsberg
    Apr 14 at 15:12










  • $begingroup$
    Thanks for information. I'm sorry, I did not know that.
    $endgroup$
    – DeBos99
    Apr 14 at 15:14















$begingroup$
Please do not update the code in your question to incorporate feedback from answers, doing so goes against the Question + Answer style of Code Review. This is not a forum where you should keep the most updated version in your question. Please see what you may and may not do after receiving answers.
$endgroup$
– Simon Forsberg
Apr 14 at 15:12




$begingroup$
Please do not update the code in your question to incorporate feedback from answers, doing so goes against the Question + Answer style of Code Review. This is not a forum where you should keep the most updated version in your question. Please see what you may and may not do after receiving answers.
$endgroup$
– Simon Forsberg
Apr 14 at 15:12












$begingroup$
Thanks for information. I'm sorry, I did not know that.
$endgroup$
– DeBos99
Apr 14 at 15:14




$begingroup$
Thanks for information. I'm sorry, I did not know that.
$endgroup$
– DeBos99
Apr 14 at 15:14










2 Answers
2






active

oldest

votes


















4












$begingroup$

I opened your code in CLion. The first thing it marked was:



#define ALLOCATION_ERROR 1


It's unused.



Other than that, there were no warnings, which is already quite good.



Next I compiled your code using both GCC and CLang:



$ gcc -Wall -Wextra -Os -c bfgen.c
$ clang -Wall -Weverything -Os -c bfgen.c
bfgen.c:5:9: warning: macro is not used [-Wunused-macros]
#define ALLOCATION_ERROR 1
^
1 warning generated.


That's also good. You prepared your code quite well for this code review by fixing the compiler warnings (if there had been any).



Now to the human part of the code review.



I would remove the inline from the function definitions. Trust the compiler to do the right thing here.



The word get in the function name get_file_pointer makes it sound as if this function had no side effects. This assumption is wrong. The function should have a better name. It is typical for these error-checking wrapper functions to be prefixed with x. You will find many implementations of xmalloc, xrealloc, xopen, and so on in other projects.



In the get_file_pointer function, you should include the kind of error in the fprintf output:



fprintf(stderr, "Error: failed to open file '%s': %sn", filename, strerror(errno));


The function int_to_brainfuck has a bad name. It's clear from the function signature that it takes an int, therefore the function name should rather describe what that int means. It's a difference, but there is no documentation about what differs. After reading the whole code of the function I know that it's the difference between the previous character and the next character. This information should be encoded in the function name.



Calling strlen repeatedly is a waste of time. At each point in the code you know exactly how long the string is, therefore it is more efficient to just store the current end of the brainfuck_code in a pointer and always strcpy to that pointer:



size_t code_len = number_of_tens + loop_body_length + number_of_ones + 2;
char *brainfuck_code = calloc(code_len, sizeof *brainfuck_code);
char *code = brainfuck_code;

if (number_of_tens > 0)
*code++ = '>';
memset(code, '+', number_of_tens);
code += number_of_tens;
strcpy(code, "[<");
code += 3;
memset(code, character_in_loop, 10);
code += 10;
strcpy(code, ">-]<");
code += 4;


memset(code, character_in_loop, number_of_ones);
code += number_of_ones;
*code++ = '.';

assert(brainfuck_code + code_len == code);

return brainfuck_code;


I added the assert at the end because these explicit length calculations can always go wrong. If the compiler is smart enough, it will find out that this assertion always succeeds and may even eliminate it. And in case you forgot a character to change the code later, you will quickly get a crash dump instead of undefined behavior because of a buffer overflow.



I suspected you had already calculated the length wrong because I couldn't find the first character in the formula. Instead, there's a magic number 2 in that formula. You should make the formula correspond to the actual code by writing it like this:



size_t code_len = 1 + number_of_tens + 3 + 10 + 4 number_of_ones + 1;


This allows you to quickly compare it to the code.



Even better would be if you would not need this whole calculation at all. Since you are writing the output to a file anyway, you don't need to allocate the memory yourself. I'm thinking of two functions like these:



typedef struct 
FILE *out;
bfgen;

static void bfgen_emit_str(bfgen *gen, const char *code)
...


static void bfgen_emit_repeat(bfgen *gen, char code, size_t n)
...



Then you can simply write:



static void
bfgen_emit_difference(bfgen *gen, int difference)
if (difference == 0)
bfgen_emit_str(".");
return;


char character_in_loop = difference > 0 ? '+' : '-';
unsigned int abs_diff = difference > 0 ? difference : -difference;
unsigned int number_of_tens = abs_diff / 10;

if (number_of_tens > 0)
bfgen_emit_str(gen, ">");
bfgen_emit_repeat(gen, '+', number_of_tens);
bfgen_emit_str(gen, "[<");
bfgen_emit_repeat(gen, character_in_loop, 10);
bfgen_emit_str(gen, ">-]<");


bfgen_emit_repeat(gen, character_in_loop, abs_diff % 10);
bfgen_emit_str(gen, ".");



This code looks much clearer. Now that you don't have to think about all this annoying buffer size calculation anymore, it becomes much easier to add new optimizations, such as avoiding the loop when number_of_tens is exactly 1. In the previous version of the code I wouldn't have added this feature out of laziness and fear of breaking things.



Based on this example, you can see that the functions bfgen_emit_str and bfgen_emit_repeat are really useful, and implementing them is easy.



static void bfgen_emit_str(bfgen *gen, const char *code) 
fputs(code, gen->out);


static void bfgen_emit_repeat(bfgen *gen, char code, size_t n)
for (size_t i = 0; i < n; i++)
fputc(code, gen->out);




Looking at bfgen_emit_difference again, that function doesn't do what its name says. It doesn't only emit code to calculate the difference, it also emits code to print the resulting character. It shouldn't do that. The call to bfgen_emit_str(gen, ".") belongs in bfgen_generate_code instead.




It doesn't matter anymore, but your original version of int_to_brainfuck was essentially:



static char *
int_to_brainfuck(...)
if (condition)
return ".";
else
return allocated_string;




You must never write such a function since the caller cannot know whether they should free the string or not. This leads either to memory leaks or to undefined behavior. You don't want either of these.




In the main function, you should open the input file in binary mode and the output file in text mode. Currently it's the other way round.




The main takeaway from this code review is that it makes sense to define your own data structures and the corresponding functions. Make these functions as easy as possible to use. Free the caller from any unnecessary tasks such as calculating buffer sizes or managing memory, which are really boring and error-prone.



An idea for further work is to make the generated code more efficient by keeping track of the actual memory contents. This can now be easily done in the struct bfgen. Then you can look which memory cell has currently the closest value and use that instead of just using a single memory cell.



The rewritten and restructured code is:



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

#define FILE_ERROR 2
#define OTHER_ERROR 3

static FILE *
xfopen(const char *filename, const char *mode)
FILE *file_pointer = fopen(filename, mode);
if (file_pointer == NULL)
fprintf(stderr, "Error: failed to open file '%s': %sn",
filename, strerror(errno));
exit(FILE_ERROR);

return file_pointer;


typedef struct
FILE *out;
bfgen;

static void
bfgen_emit_str(bfgen *gen, const char *code)
fputs(code, gen->out);


static void
bfgen_emit_repeat(bfgen *gen, char code, size_t n)
for (size_t i = 0; i < n; i++)
fputc(code, gen->out);



static void
bfgen_emit_difference(bfgen *gen, int difference)
if (difference == 0)
return;


char character_in_loop = difference > 0 ? '+' : '-';
unsigned int abs_diff = difference > 0 ? difference : -difference;
unsigned int number_of_tens = abs_diff / 10;

if (number_of_tens > 0)
bfgen_emit_str(gen, ">");
bfgen_emit_repeat(gen, '+', number_of_tens);
bfgen_emit_str(gen, "[<");
bfgen_emit_repeat(gen, character_in_loop, 10);
bfgen_emit_str(gen, ">-]<");


bfgen_emit_repeat(gen, character_in_loop, abs_diff % 10);


static void
bfgen_generate_code(bfgen *gen, FILE *input_file)
int current_char, last_char = 0;
while ((current_char = fgetc(input_file)) != EOF)
bfgen_emit_difference(gen, current_char - last_char);
bfgen_emit_str(gen, ".n");
last_char = current_char;



static void
parse_args(int argc)
if (argc != 3)
puts("Usage: bfgen <input> <output>");
exit(OTHER_ERROR);



int
main(int argc, char **argv)
parse_args(argc);
FILE *input_file = xfopen(argv[1], "rb");
FILE *output_file = xfopen(argv[2], "w");
bfgen gen = output_file;
bfgen_generate_code(&gen, input_file);
fclose(output_file);
fclose(input_file);
return 0;






share|improve this answer











$endgroup$












  • $begingroup$
    Thanks for the review. I forgot to add error check for calloc, so this is why this macro was unused. Why would you remove inline? codereview.stackexchange.com/a/216889/177688 . I names the function get_file_pointer because you are getting file pointer from that function. If I would use x, shouldn't be that xfopen instead of xopen? I will work on my int_to_brainfuck function. In main function input_file should be text I think because I want to read newline as one char (not as two chars e.g. on windows). I will post new code later.
    $endgroup$
    – DeBos99
    Apr 14 at 11:49






  • 1




    $begingroup$
    I added edited code to my post.
    $endgroup$
    – DeBos99
    Apr 14 at 12:30










  • $begingroup$
    @DeBos99 inline is indeed not required: since the program is a single file (or more generally, all function declarations are visible to the compiler) it will willingly inline them. inline could be used to express intent - saying "this function is speed critical, so it needs to be inlined" - but the compiler will inline (or not inline it) regardless. The only real way to force inlining is using a function attribute, __always_inline__ or similar.
    $endgroup$
    – valiano
    Apr 14 at 13:39










  • $begingroup$
    @DeBos99 good catch with xfopen, I've fixed the function name.
    $endgroup$
    – Roland Illig
    Apr 14 at 15:26










  • $begingroup$
    @valiano you are saying that inline is not required, but program runs faster with it, so I think that it should be there.
    $endgroup$
    – DeBos99
    Apr 14 at 16:04


















0












$begingroup$

After the first great review by Roland Illig, I could add a few comments on the second code revision, in order of appearance:



  • #include <string.h> - not required now, and could be removed.



  • define ALLOCATION_ERROR 1:

    Rather than preprocessor macros, consider using a named enum. With an enum, you get better diagnostics and type checking from the compiler, plus the error codes are grouped into one named construct:



    enum ERROR_CODES

    ALLOCATION_ERROR = 1,
    FILE_ERROR = 2,
    OTHER_ERROR = 3
    ;


    As a bonus, you get rid of the unused macro warning.




  • It's best to avoid single-line if and for blocks, which could cause subtle and hard to find bugs. I.e.:



    for(int i=0;i<n;++i)
    fputc(c,output_file);


    is better written as:



    for(int i=0;i<n;++i)

    fputc(c,output_file);




  • You could early exit the emit_difference function after the if(difference==0) check. Then, you could reduce the indentation level of the code that follows. This technique comes very handy when you have to check for several conditions before doing the actual work. I.e.,



    if(difference==0)
    fputc('.',output_file);
    else
    // ...



    May turn into:



    if(difference==0)

    fputc('.',output_file);
    return;


    // Code of the else block


  • Style comment: consider adding newlines between your functions, to create a clear separation between them.


  • inline: I second Ronald in that the inline keyword may be safely removed. Since the program is a single file (and more generally, all function declarations are visible to the compiler), it will willingly inline them.






share|improve this answer










New contributor




valiano is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






$endgroup$












  • $begingroup$
    Always use blocks instead of single statements is oft-disputed advice, though I won't restart that style-war here.
    $endgroup$
    – Deduplicator
    Apr 14 at 15:16










  • $begingroup$
    Thanks for review @valiano. I think that using macros for errors is sometimes better e.g. Roland got this warning about unused macro, so I could remove it. Should I add return; at the end of else block or only in if?
    $endgroup$
    – DeBos99
    Apr 14 at 16:09










  • $begingroup$
    @DeBos99 no need for a return at the end of the else block, since the function is to return anyway right afterwards.
    $endgroup$
    – valiano
    Apr 14 at 17:09












Your Answer






StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "196"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f217422%2fprogram-that-generates-brainfuck-code-that-outputs-given-text%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes









4












$begingroup$

I opened your code in CLion. The first thing it marked was:



#define ALLOCATION_ERROR 1


It's unused.



Other than that, there were no warnings, which is already quite good.



Next I compiled your code using both GCC and CLang:



$ gcc -Wall -Wextra -Os -c bfgen.c
$ clang -Wall -Weverything -Os -c bfgen.c
bfgen.c:5:9: warning: macro is not used [-Wunused-macros]
#define ALLOCATION_ERROR 1
^
1 warning generated.


That's also good. You prepared your code quite well for this code review by fixing the compiler warnings (if there had been any).



Now to the human part of the code review.



I would remove the inline from the function definitions. Trust the compiler to do the right thing here.



The word get in the function name get_file_pointer makes it sound as if this function had no side effects. This assumption is wrong. The function should have a better name. It is typical for these error-checking wrapper functions to be prefixed with x. You will find many implementations of xmalloc, xrealloc, xopen, and so on in other projects.



In the get_file_pointer function, you should include the kind of error in the fprintf output:



fprintf(stderr, "Error: failed to open file '%s': %sn", filename, strerror(errno));


The function int_to_brainfuck has a bad name. It's clear from the function signature that it takes an int, therefore the function name should rather describe what that int means. It's a difference, but there is no documentation about what differs. After reading the whole code of the function I know that it's the difference between the previous character and the next character. This information should be encoded in the function name.



Calling strlen repeatedly is a waste of time. At each point in the code you know exactly how long the string is, therefore it is more efficient to just store the current end of the brainfuck_code in a pointer and always strcpy to that pointer:



size_t code_len = number_of_tens + loop_body_length + number_of_ones + 2;
char *brainfuck_code = calloc(code_len, sizeof *brainfuck_code);
char *code = brainfuck_code;

if (number_of_tens > 0)
*code++ = '>';
memset(code, '+', number_of_tens);
code += number_of_tens;
strcpy(code, "[<");
code += 3;
memset(code, character_in_loop, 10);
code += 10;
strcpy(code, ">-]<");
code += 4;


memset(code, character_in_loop, number_of_ones);
code += number_of_ones;
*code++ = '.';

assert(brainfuck_code + code_len == code);

return brainfuck_code;


I added the assert at the end because these explicit length calculations can always go wrong. If the compiler is smart enough, it will find out that this assertion always succeeds and may even eliminate it. And in case you forgot a character to change the code later, you will quickly get a crash dump instead of undefined behavior because of a buffer overflow.



I suspected you had already calculated the length wrong because I couldn't find the first character in the formula. Instead, there's a magic number 2 in that formula. You should make the formula correspond to the actual code by writing it like this:



size_t code_len = 1 + number_of_tens + 3 + 10 + 4 number_of_ones + 1;


This allows you to quickly compare it to the code.



Even better would be if you would not need this whole calculation at all. Since you are writing the output to a file anyway, you don't need to allocate the memory yourself. I'm thinking of two functions like these:



typedef struct 
FILE *out;
bfgen;

static void bfgen_emit_str(bfgen *gen, const char *code)
...


static void bfgen_emit_repeat(bfgen *gen, char code, size_t n)
...



Then you can simply write:



static void
bfgen_emit_difference(bfgen *gen, int difference)
if (difference == 0)
bfgen_emit_str(".");
return;


char character_in_loop = difference > 0 ? '+' : '-';
unsigned int abs_diff = difference > 0 ? difference : -difference;
unsigned int number_of_tens = abs_diff / 10;

if (number_of_tens > 0)
bfgen_emit_str(gen, ">");
bfgen_emit_repeat(gen, '+', number_of_tens);
bfgen_emit_str(gen, "[<");
bfgen_emit_repeat(gen, character_in_loop, 10);
bfgen_emit_str(gen, ">-]<");


bfgen_emit_repeat(gen, character_in_loop, abs_diff % 10);
bfgen_emit_str(gen, ".");



This code looks much clearer. Now that you don't have to think about all this annoying buffer size calculation anymore, it becomes much easier to add new optimizations, such as avoiding the loop when number_of_tens is exactly 1. In the previous version of the code I wouldn't have added this feature out of laziness and fear of breaking things.



Based on this example, you can see that the functions bfgen_emit_str and bfgen_emit_repeat are really useful, and implementing them is easy.



static void bfgen_emit_str(bfgen *gen, const char *code) 
fputs(code, gen->out);


static void bfgen_emit_repeat(bfgen *gen, char code, size_t n)
for (size_t i = 0; i < n; i++)
fputc(code, gen->out);




Looking at bfgen_emit_difference again, that function doesn't do what its name says. It doesn't only emit code to calculate the difference, it also emits code to print the resulting character. It shouldn't do that. The call to bfgen_emit_str(gen, ".") belongs in bfgen_generate_code instead.




It doesn't matter anymore, but your original version of int_to_brainfuck was essentially:



static char *
int_to_brainfuck(...)
if (condition)
return ".";
else
return allocated_string;




You must never write such a function since the caller cannot know whether they should free the string or not. This leads either to memory leaks or to undefined behavior. You don't want either of these.




In the main function, you should open the input file in binary mode and the output file in text mode. Currently it's the other way round.




The main takeaway from this code review is that it makes sense to define your own data structures and the corresponding functions. Make these functions as easy as possible to use. Free the caller from any unnecessary tasks such as calculating buffer sizes or managing memory, which are really boring and error-prone.



An idea for further work is to make the generated code more efficient by keeping track of the actual memory contents. This can now be easily done in the struct bfgen. Then you can look which memory cell has currently the closest value and use that instead of just using a single memory cell.



The rewritten and restructured code is:



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

#define FILE_ERROR 2
#define OTHER_ERROR 3

static FILE *
xfopen(const char *filename, const char *mode)
FILE *file_pointer = fopen(filename, mode);
if (file_pointer == NULL)
fprintf(stderr, "Error: failed to open file '%s': %sn",
filename, strerror(errno));
exit(FILE_ERROR);

return file_pointer;


typedef struct
FILE *out;
bfgen;

static void
bfgen_emit_str(bfgen *gen, const char *code)
fputs(code, gen->out);


static void
bfgen_emit_repeat(bfgen *gen, char code, size_t n)
for (size_t i = 0; i < n; i++)
fputc(code, gen->out);



static void
bfgen_emit_difference(bfgen *gen, int difference)
if (difference == 0)
return;


char character_in_loop = difference > 0 ? '+' : '-';
unsigned int abs_diff = difference > 0 ? difference : -difference;
unsigned int number_of_tens = abs_diff / 10;

if (number_of_tens > 0)
bfgen_emit_str(gen, ">");
bfgen_emit_repeat(gen, '+', number_of_tens);
bfgen_emit_str(gen, "[<");
bfgen_emit_repeat(gen, character_in_loop, 10);
bfgen_emit_str(gen, ">-]<");


bfgen_emit_repeat(gen, character_in_loop, abs_diff % 10);


static void
bfgen_generate_code(bfgen *gen, FILE *input_file)
int current_char, last_char = 0;
while ((current_char = fgetc(input_file)) != EOF)
bfgen_emit_difference(gen, current_char - last_char);
bfgen_emit_str(gen, ".n");
last_char = current_char;



static void
parse_args(int argc)
if (argc != 3)
puts("Usage: bfgen <input> <output>");
exit(OTHER_ERROR);



int
main(int argc, char **argv)
parse_args(argc);
FILE *input_file = xfopen(argv[1], "rb");
FILE *output_file = xfopen(argv[2], "w");
bfgen gen = output_file;
bfgen_generate_code(&gen, input_file);
fclose(output_file);
fclose(input_file);
return 0;






share|improve this answer











$endgroup$












  • $begingroup$
    Thanks for the review. I forgot to add error check for calloc, so this is why this macro was unused. Why would you remove inline? codereview.stackexchange.com/a/216889/177688 . I names the function get_file_pointer because you are getting file pointer from that function. If I would use x, shouldn't be that xfopen instead of xopen? I will work on my int_to_brainfuck function. In main function input_file should be text I think because I want to read newline as one char (not as two chars e.g. on windows). I will post new code later.
    $endgroup$
    – DeBos99
    Apr 14 at 11:49






  • 1




    $begingroup$
    I added edited code to my post.
    $endgroup$
    – DeBos99
    Apr 14 at 12:30










  • $begingroup$
    @DeBos99 inline is indeed not required: since the program is a single file (or more generally, all function declarations are visible to the compiler) it will willingly inline them. inline could be used to express intent - saying "this function is speed critical, so it needs to be inlined" - but the compiler will inline (or not inline it) regardless. The only real way to force inlining is using a function attribute, __always_inline__ or similar.
    $endgroup$
    – valiano
    Apr 14 at 13:39










  • $begingroup$
    @DeBos99 good catch with xfopen, I've fixed the function name.
    $endgroup$
    – Roland Illig
    Apr 14 at 15:26










  • $begingroup$
    @valiano you are saying that inline is not required, but program runs faster with it, so I think that it should be there.
    $endgroup$
    – DeBos99
    Apr 14 at 16:04















4












$begingroup$

I opened your code in CLion. The first thing it marked was:



#define ALLOCATION_ERROR 1


It's unused.



Other than that, there were no warnings, which is already quite good.



Next I compiled your code using both GCC and CLang:



$ gcc -Wall -Wextra -Os -c bfgen.c
$ clang -Wall -Weverything -Os -c bfgen.c
bfgen.c:5:9: warning: macro is not used [-Wunused-macros]
#define ALLOCATION_ERROR 1
^
1 warning generated.


That's also good. You prepared your code quite well for this code review by fixing the compiler warnings (if there had been any).



Now to the human part of the code review.



I would remove the inline from the function definitions. Trust the compiler to do the right thing here.



The word get in the function name get_file_pointer makes it sound as if this function had no side effects. This assumption is wrong. The function should have a better name. It is typical for these error-checking wrapper functions to be prefixed with x. You will find many implementations of xmalloc, xrealloc, xopen, and so on in other projects.



In the get_file_pointer function, you should include the kind of error in the fprintf output:



fprintf(stderr, "Error: failed to open file '%s': %sn", filename, strerror(errno));


The function int_to_brainfuck has a bad name. It's clear from the function signature that it takes an int, therefore the function name should rather describe what that int means. It's a difference, but there is no documentation about what differs. After reading the whole code of the function I know that it's the difference between the previous character and the next character. This information should be encoded in the function name.



Calling strlen repeatedly is a waste of time. At each point in the code you know exactly how long the string is, therefore it is more efficient to just store the current end of the brainfuck_code in a pointer and always strcpy to that pointer:



size_t code_len = number_of_tens + loop_body_length + number_of_ones + 2;
char *brainfuck_code = calloc(code_len, sizeof *brainfuck_code);
char *code = brainfuck_code;

if (number_of_tens > 0)
*code++ = '>';
memset(code, '+', number_of_tens);
code += number_of_tens;
strcpy(code, "[<");
code += 3;
memset(code, character_in_loop, 10);
code += 10;
strcpy(code, ">-]<");
code += 4;


memset(code, character_in_loop, number_of_ones);
code += number_of_ones;
*code++ = '.';

assert(brainfuck_code + code_len == code);

return brainfuck_code;


I added the assert at the end because these explicit length calculations can always go wrong. If the compiler is smart enough, it will find out that this assertion always succeeds and may even eliminate it. And in case you forgot a character to change the code later, you will quickly get a crash dump instead of undefined behavior because of a buffer overflow.



I suspected you had already calculated the length wrong because I couldn't find the first character in the formula. Instead, there's a magic number 2 in that formula. You should make the formula correspond to the actual code by writing it like this:



size_t code_len = 1 + number_of_tens + 3 + 10 + 4 number_of_ones + 1;


This allows you to quickly compare it to the code.



Even better would be if you would not need this whole calculation at all. Since you are writing the output to a file anyway, you don't need to allocate the memory yourself. I'm thinking of two functions like these:



typedef struct 
FILE *out;
bfgen;

static void bfgen_emit_str(bfgen *gen, const char *code)
...


static void bfgen_emit_repeat(bfgen *gen, char code, size_t n)
...



Then you can simply write:



static void
bfgen_emit_difference(bfgen *gen, int difference)
if (difference == 0)
bfgen_emit_str(".");
return;


char character_in_loop = difference > 0 ? '+' : '-';
unsigned int abs_diff = difference > 0 ? difference : -difference;
unsigned int number_of_tens = abs_diff / 10;

if (number_of_tens > 0)
bfgen_emit_str(gen, ">");
bfgen_emit_repeat(gen, '+', number_of_tens);
bfgen_emit_str(gen, "[<");
bfgen_emit_repeat(gen, character_in_loop, 10);
bfgen_emit_str(gen, ">-]<");


bfgen_emit_repeat(gen, character_in_loop, abs_diff % 10);
bfgen_emit_str(gen, ".");



This code looks much clearer. Now that you don't have to think about all this annoying buffer size calculation anymore, it becomes much easier to add new optimizations, such as avoiding the loop when number_of_tens is exactly 1. In the previous version of the code I wouldn't have added this feature out of laziness and fear of breaking things.



Based on this example, you can see that the functions bfgen_emit_str and bfgen_emit_repeat are really useful, and implementing them is easy.



static void bfgen_emit_str(bfgen *gen, const char *code) 
fputs(code, gen->out);


static void bfgen_emit_repeat(bfgen *gen, char code, size_t n)
for (size_t i = 0; i < n; i++)
fputc(code, gen->out);




Looking at bfgen_emit_difference again, that function doesn't do what its name says. It doesn't only emit code to calculate the difference, it also emits code to print the resulting character. It shouldn't do that. The call to bfgen_emit_str(gen, ".") belongs in bfgen_generate_code instead.




It doesn't matter anymore, but your original version of int_to_brainfuck was essentially:



static char *
int_to_brainfuck(...)
if (condition)
return ".";
else
return allocated_string;




You must never write such a function since the caller cannot know whether they should free the string or not. This leads either to memory leaks or to undefined behavior. You don't want either of these.




In the main function, you should open the input file in binary mode and the output file in text mode. Currently it's the other way round.




The main takeaway from this code review is that it makes sense to define your own data structures and the corresponding functions. Make these functions as easy as possible to use. Free the caller from any unnecessary tasks such as calculating buffer sizes or managing memory, which are really boring and error-prone.



An idea for further work is to make the generated code more efficient by keeping track of the actual memory contents. This can now be easily done in the struct bfgen. Then you can look which memory cell has currently the closest value and use that instead of just using a single memory cell.



The rewritten and restructured code is:



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

#define FILE_ERROR 2
#define OTHER_ERROR 3

static FILE *
xfopen(const char *filename, const char *mode)
FILE *file_pointer = fopen(filename, mode);
if (file_pointer == NULL)
fprintf(stderr, "Error: failed to open file '%s': %sn",
filename, strerror(errno));
exit(FILE_ERROR);

return file_pointer;


typedef struct
FILE *out;
bfgen;

static void
bfgen_emit_str(bfgen *gen, const char *code)
fputs(code, gen->out);


static void
bfgen_emit_repeat(bfgen *gen, char code, size_t n)
for (size_t i = 0; i < n; i++)
fputc(code, gen->out);



static void
bfgen_emit_difference(bfgen *gen, int difference)
if (difference == 0)
return;


char character_in_loop = difference > 0 ? '+' : '-';
unsigned int abs_diff = difference > 0 ? difference : -difference;
unsigned int number_of_tens = abs_diff / 10;

if (number_of_tens > 0)
bfgen_emit_str(gen, ">");
bfgen_emit_repeat(gen, '+', number_of_tens);
bfgen_emit_str(gen, "[<");
bfgen_emit_repeat(gen, character_in_loop, 10);
bfgen_emit_str(gen, ">-]<");


bfgen_emit_repeat(gen, character_in_loop, abs_diff % 10);


static void
bfgen_generate_code(bfgen *gen, FILE *input_file)
int current_char, last_char = 0;
while ((current_char = fgetc(input_file)) != EOF)
bfgen_emit_difference(gen, current_char - last_char);
bfgen_emit_str(gen, ".n");
last_char = current_char;



static void
parse_args(int argc)
if (argc != 3)
puts("Usage: bfgen <input> <output>");
exit(OTHER_ERROR);



int
main(int argc, char **argv)
parse_args(argc);
FILE *input_file = xfopen(argv[1], "rb");
FILE *output_file = xfopen(argv[2], "w");
bfgen gen = output_file;
bfgen_generate_code(&gen, input_file);
fclose(output_file);
fclose(input_file);
return 0;






share|improve this answer











$endgroup$












  • $begingroup$
    Thanks for the review. I forgot to add error check for calloc, so this is why this macro was unused. Why would you remove inline? codereview.stackexchange.com/a/216889/177688 . I names the function get_file_pointer because you are getting file pointer from that function. If I would use x, shouldn't be that xfopen instead of xopen? I will work on my int_to_brainfuck function. In main function input_file should be text I think because I want to read newline as one char (not as two chars e.g. on windows). I will post new code later.
    $endgroup$
    – DeBos99
    Apr 14 at 11:49






  • 1




    $begingroup$
    I added edited code to my post.
    $endgroup$
    – DeBos99
    Apr 14 at 12:30










  • $begingroup$
    @DeBos99 inline is indeed not required: since the program is a single file (or more generally, all function declarations are visible to the compiler) it will willingly inline them. inline could be used to express intent - saying "this function is speed critical, so it needs to be inlined" - but the compiler will inline (or not inline it) regardless. The only real way to force inlining is using a function attribute, __always_inline__ or similar.
    $endgroup$
    – valiano
    Apr 14 at 13:39










  • $begingroup$
    @DeBos99 good catch with xfopen, I've fixed the function name.
    $endgroup$
    – Roland Illig
    Apr 14 at 15:26










  • $begingroup$
    @valiano you are saying that inline is not required, but program runs faster with it, so I think that it should be there.
    $endgroup$
    – DeBos99
    Apr 14 at 16:04













4












4








4





$begingroup$

I opened your code in CLion. The first thing it marked was:



#define ALLOCATION_ERROR 1


It's unused.



Other than that, there were no warnings, which is already quite good.



Next I compiled your code using both GCC and CLang:



$ gcc -Wall -Wextra -Os -c bfgen.c
$ clang -Wall -Weverything -Os -c bfgen.c
bfgen.c:5:9: warning: macro is not used [-Wunused-macros]
#define ALLOCATION_ERROR 1
^
1 warning generated.


That's also good. You prepared your code quite well for this code review by fixing the compiler warnings (if there had been any).



Now to the human part of the code review.



I would remove the inline from the function definitions. Trust the compiler to do the right thing here.



The word get in the function name get_file_pointer makes it sound as if this function had no side effects. This assumption is wrong. The function should have a better name. It is typical for these error-checking wrapper functions to be prefixed with x. You will find many implementations of xmalloc, xrealloc, xopen, and so on in other projects.



In the get_file_pointer function, you should include the kind of error in the fprintf output:



fprintf(stderr, "Error: failed to open file '%s': %sn", filename, strerror(errno));


The function int_to_brainfuck has a bad name. It's clear from the function signature that it takes an int, therefore the function name should rather describe what that int means. It's a difference, but there is no documentation about what differs. After reading the whole code of the function I know that it's the difference between the previous character and the next character. This information should be encoded in the function name.



Calling strlen repeatedly is a waste of time. At each point in the code you know exactly how long the string is, therefore it is more efficient to just store the current end of the brainfuck_code in a pointer and always strcpy to that pointer:



size_t code_len = number_of_tens + loop_body_length + number_of_ones + 2;
char *brainfuck_code = calloc(code_len, sizeof *brainfuck_code);
char *code = brainfuck_code;

if (number_of_tens > 0)
*code++ = '>';
memset(code, '+', number_of_tens);
code += number_of_tens;
strcpy(code, "[<");
code += 3;
memset(code, character_in_loop, 10);
code += 10;
strcpy(code, ">-]<");
code += 4;


memset(code, character_in_loop, number_of_ones);
code += number_of_ones;
*code++ = '.';

assert(brainfuck_code + code_len == code);

return brainfuck_code;


I added the assert at the end because these explicit length calculations can always go wrong. If the compiler is smart enough, it will find out that this assertion always succeeds and may even eliminate it. And in case you forgot a character to change the code later, you will quickly get a crash dump instead of undefined behavior because of a buffer overflow.



I suspected you had already calculated the length wrong because I couldn't find the first character in the formula. Instead, there's a magic number 2 in that formula. You should make the formula correspond to the actual code by writing it like this:



size_t code_len = 1 + number_of_tens + 3 + 10 + 4 number_of_ones + 1;


This allows you to quickly compare it to the code.



Even better would be if you would not need this whole calculation at all. Since you are writing the output to a file anyway, you don't need to allocate the memory yourself. I'm thinking of two functions like these:



typedef struct 
FILE *out;
bfgen;

static void bfgen_emit_str(bfgen *gen, const char *code)
...


static void bfgen_emit_repeat(bfgen *gen, char code, size_t n)
...



Then you can simply write:



static void
bfgen_emit_difference(bfgen *gen, int difference)
if (difference == 0)
bfgen_emit_str(".");
return;


char character_in_loop = difference > 0 ? '+' : '-';
unsigned int abs_diff = difference > 0 ? difference : -difference;
unsigned int number_of_tens = abs_diff / 10;

if (number_of_tens > 0)
bfgen_emit_str(gen, ">");
bfgen_emit_repeat(gen, '+', number_of_tens);
bfgen_emit_str(gen, "[<");
bfgen_emit_repeat(gen, character_in_loop, 10);
bfgen_emit_str(gen, ">-]<");


bfgen_emit_repeat(gen, character_in_loop, abs_diff % 10);
bfgen_emit_str(gen, ".");



This code looks much clearer. Now that you don't have to think about all this annoying buffer size calculation anymore, it becomes much easier to add new optimizations, such as avoiding the loop when number_of_tens is exactly 1. In the previous version of the code I wouldn't have added this feature out of laziness and fear of breaking things.



Based on this example, you can see that the functions bfgen_emit_str and bfgen_emit_repeat are really useful, and implementing them is easy.



static void bfgen_emit_str(bfgen *gen, const char *code) 
fputs(code, gen->out);


static void bfgen_emit_repeat(bfgen *gen, char code, size_t n)
for (size_t i = 0; i < n; i++)
fputc(code, gen->out);




Looking at bfgen_emit_difference again, that function doesn't do what its name says. It doesn't only emit code to calculate the difference, it also emits code to print the resulting character. It shouldn't do that. The call to bfgen_emit_str(gen, ".") belongs in bfgen_generate_code instead.




It doesn't matter anymore, but your original version of int_to_brainfuck was essentially:



static char *
int_to_brainfuck(...)
if (condition)
return ".";
else
return allocated_string;




You must never write such a function since the caller cannot know whether they should free the string or not. This leads either to memory leaks or to undefined behavior. You don't want either of these.




In the main function, you should open the input file in binary mode and the output file in text mode. Currently it's the other way round.




The main takeaway from this code review is that it makes sense to define your own data structures and the corresponding functions. Make these functions as easy as possible to use. Free the caller from any unnecessary tasks such as calculating buffer sizes or managing memory, which are really boring and error-prone.



An idea for further work is to make the generated code more efficient by keeping track of the actual memory contents. This can now be easily done in the struct bfgen. Then you can look which memory cell has currently the closest value and use that instead of just using a single memory cell.



The rewritten and restructured code is:



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

#define FILE_ERROR 2
#define OTHER_ERROR 3

static FILE *
xfopen(const char *filename, const char *mode)
FILE *file_pointer = fopen(filename, mode);
if (file_pointer == NULL)
fprintf(stderr, "Error: failed to open file '%s': %sn",
filename, strerror(errno));
exit(FILE_ERROR);

return file_pointer;


typedef struct
FILE *out;
bfgen;

static void
bfgen_emit_str(bfgen *gen, const char *code)
fputs(code, gen->out);


static void
bfgen_emit_repeat(bfgen *gen, char code, size_t n)
for (size_t i = 0; i < n; i++)
fputc(code, gen->out);



static void
bfgen_emit_difference(bfgen *gen, int difference)
if (difference == 0)
return;


char character_in_loop = difference > 0 ? '+' : '-';
unsigned int abs_diff = difference > 0 ? difference : -difference;
unsigned int number_of_tens = abs_diff / 10;

if (number_of_tens > 0)
bfgen_emit_str(gen, ">");
bfgen_emit_repeat(gen, '+', number_of_tens);
bfgen_emit_str(gen, "[<");
bfgen_emit_repeat(gen, character_in_loop, 10);
bfgen_emit_str(gen, ">-]<");


bfgen_emit_repeat(gen, character_in_loop, abs_diff % 10);


static void
bfgen_generate_code(bfgen *gen, FILE *input_file)
int current_char, last_char = 0;
while ((current_char = fgetc(input_file)) != EOF)
bfgen_emit_difference(gen, current_char - last_char);
bfgen_emit_str(gen, ".n");
last_char = current_char;



static void
parse_args(int argc)
if (argc != 3)
puts("Usage: bfgen <input> <output>");
exit(OTHER_ERROR);



int
main(int argc, char **argv)
parse_args(argc);
FILE *input_file = xfopen(argv[1], "rb");
FILE *output_file = xfopen(argv[2], "w");
bfgen gen = output_file;
bfgen_generate_code(&gen, input_file);
fclose(output_file);
fclose(input_file);
return 0;






share|improve this answer











$endgroup$



I opened your code in CLion. The first thing it marked was:



#define ALLOCATION_ERROR 1


It's unused.



Other than that, there were no warnings, which is already quite good.



Next I compiled your code using both GCC and CLang:



$ gcc -Wall -Wextra -Os -c bfgen.c
$ clang -Wall -Weverything -Os -c bfgen.c
bfgen.c:5:9: warning: macro is not used [-Wunused-macros]
#define ALLOCATION_ERROR 1
^
1 warning generated.


That's also good. You prepared your code quite well for this code review by fixing the compiler warnings (if there had been any).



Now to the human part of the code review.



I would remove the inline from the function definitions. Trust the compiler to do the right thing here.



The word get in the function name get_file_pointer makes it sound as if this function had no side effects. This assumption is wrong. The function should have a better name. It is typical for these error-checking wrapper functions to be prefixed with x. You will find many implementations of xmalloc, xrealloc, xopen, and so on in other projects.



In the get_file_pointer function, you should include the kind of error in the fprintf output:



fprintf(stderr, "Error: failed to open file '%s': %sn", filename, strerror(errno));


The function int_to_brainfuck has a bad name. It's clear from the function signature that it takes an int, therefore the function name should rather describe what that int means. It's a difference, but there is no documentation about what differs. After reading the whole code of the function I know that it's the difference between the previous character and the next character. This information should be encoded in the function name.



Calling strlen repeatedly is a waste of time. At each point in the code you know exactly how long the string is, therefore it is more efficient to just store the current end of the brainfuck_code in a pointer and always strcpy to that pointer:



size_t code_len = number_of_tens + loop_body_length + number_of_ones + 2;
char *brainfuck_code = calloc(code_len, sizeof *brainfuck_code);
char *code = brainfuck_code;

if (number_of_tens > 0)
*code++ = '>';
memset(code, '+', number_of_tens);
code += number_of_tens;
strcpy(code, "[<");
code += 3;
memset(code, character_in_loop, 10);
code += 10;
strcpy(code, ">-]<");
code += 4;


memset(code, character_in_loop, number_of_ones);
code += number_of_ones;
*code++ = '.';

assert(brainfuck_code + code_len == code);

return brainfuck_code;


I added the assert at the end because these explicit length calculations can always go wrong. If the compiler is smart enough, it will find out that this assertion always succeeds and may even eliminate it. And in case you forgot a character to change the code later, you will quickly get a crash dump instead of undefined behavior because of a buffer overflow.



I suspected you had already calculated the length wrong because I couldn't find the first character in the formula. Instead, there's a magic number 2 in that formula. You should make the formula correspond to the actual code by writing it like this:



size_t code_len = 1 + number_of_tens + 3 + 10 + 4 number_of_ones + 1;


This allows you to quickly compare it to the code.



Even better would be if you would not need this whole calculation at all. Since you are writing the output to a file anyway, you don't need to allocate the memory yourself. I'm thinking of two functions like these:



typedef struct 
FILE *out;
bfgen;

static void bfgen_emit_str(bfgen *gen, const char *code)
...


static void bfgen_emit_repeat(bfgen *gen, char code, size_t n)
...



Then you can simply write:



static void
bfgen_emit_difference(bfgen *gen, int difference)
if (difference == 0)
bfgen_emit_str(".");
return;


char character_in_loop = difference > 0 ? '+' : '-';
unsigned int abs_diff = difference > 0 ? difference : -difference;
unsigned int number_of_tens = abs_diff / 10;

if (number_of_tens > 0)
bfgen_emit_str(gen, ">");
bfgen_emit_repeat(gen, '+', number_of_tens);
bfgen_emit_str(gen, "[<");
bfgen_emit_repeat(gen, character_in_loop, 10);
bfgen_emit_str(gen, ">-]<");


bfgen_emit_repeat(gen, character_in_loop, abs_diff % 10);
bfgen_emit_str(gen, ".");



This code looks much clearer. Now that you don't have to think about all this annoying buffer size calculation anymore, it becomes much easier to add new optimizations, such as avoiding the loop when number_of_tens is exactly 1. In the previous version of the code I wouldn't have added this feature out of laziness and fear of breaking things.



Based on this example, you can see that the functions bfgen_emit_str and bfgen_emit_repeat are really useful, and implementing them is easy.



static void bfgen_emit_str(bfgen *gen, const char *code) 
fputs(code, gen->out);


static void bfgen_emit_repeat(bfgen *gen, char code, size_t n)
for (size_t i = 0; i < n; i++)
fputc(code, gen->out);




Looking at bfgen_emit_difference again, that function doesn't do what its name says. It doesn't only emit code to calculate the difference, it also emits code to print the resulting character. It shouldn't do that. The call to bfgen_emit_str(gen, ".") belongs in bfgen_generate_code instead.




It doesn't matter anymore, but your original version of int_to_brainfuck was essentially:



static char *
int_to_brainfuck(...)
if (condition)
return ".";
else
return allocated_string;




You must never write such a function since the caller cannot know whether they should free the string or not. This leads either to memory leaks or to undefined behavior. You don't want either of these.




In the main function, you should open the input file in binary mode and the output file in text mode. Currently it's the other way round.




The main takeaway from this code review is that it makes sense to define your own data structures and the corresponding functions. Make these functions as easy as possible to use. Free the caller from any unnecessary tasks such as calculating buffer sizes or managing memory, which are really boring and error-prone.



An idea for further work is to make the generated code more efficient by keeping track of the actual memory contents. This can now be easily done in the struct bfgen. Then you can look which memory cell has currently the closest value and use that instead of just using a single memory cell.



The rewritten and restructured code is:



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

#define FILE_ERROR 2
#define OTHER_ERROR 3

static FILE *
xfopen(const char *filename, const char *mode)
FILE *file_pointer = fopen(filename, mode);
if (file_pointer == NULL)
fprintf(stderr, "Error: failed to open file '%s': %sn",
filename, strerror(errno));
exit(FILE_ERROR);

return file_pointer;


typedef struct
FILE *out;
bfgen;

static void
bfgen_emit_str(bfgen *gen, const char *code)
fputs(code, gen->out);


static void
bfgen_emit_repeat(bfgen *gen, char code, size_t n)
for (size_t i = 0; i < n; i++)
fputc(code, gen->out);



static void
bfgen_emit_difference(bfgen *gen, int difference)
if (difference == 0)
return;


char character_in_loop = difference > 0 ? '+' : '-';
unsigned int abs_diff = difference > 0 ? difference : -difference;
unsigned int number_of_tens = abs_diff / 10;

if (number_of_tens > 0)
bfgen_emit_str(gen, ">");
bfgen_emit_repeat(gen, '+', number_of_tens);
bfgen_emit_str(gen, "[<");
bfgen_emit_repeat(gen, character_in_loop, 10);
bfgen_emit_str(gen, ">-]<");


bfgen_emit_repeat(gen, character_in_loop, abs_diff % 10);


static void
bfgen_generate_code(bfgen *gen, FILE *input_file)
int current_char, last_char = 0;
while ((current_char = fgetc(input_file)) != EOF)
bfgen_emit_difference(gen, current_char - last_char);
bfgen_emit_str(gen, ".n");
last_char = current_char;



static void
parse_args(int argc)
if (argc != 3)
puts("Usage: bfgen <input> <output>");
exit(OTHER_ERROR);



int
main(int argc, char **argv)
parse_args(argc);
FILE *input_file = xfopen(argv[1], "rb");
FILE *output_file = xfopen(argv[2], "w");
bfgen gen = output_file;
bfgen_generate_code(&gen, input_file);
fclose(output_file);
fclose(input_file);
return 0;







share|improve this answer














share|improve this answer



share|improve this answer








edited Apr 14 at 15:06

























answered Apr 14 at 5:31









Roland IlligRoland Illig

11.7k11947




11.7k11947











  • $begingroup$
    Thanks for the review. I forgot to add error check for calloc, so this is why this macro was unused. Why would you remove inline? codereview.stackexchange.com/a/216889/177688 . I names the function get_file_pointer because you are getting file pointer from that function. If I would use x, shouldn't be that xfopen instead of xopen? I will work on my int_to_brainfuck function. In main function input_file should be text I think because I want to read newline as one char (not as two chars e.g. on windows). I will post new code later.
    $endgroup$
    – DeBos99
    Apr 14 at 11:49






  • 1




    $begingroup$
    I added edited code to my post.
    $endgroup$
    – DeBos99
    Apr 14 at 12:30










  • $begingroup$
    @DeBos99 inline is indeed not required: since the program is a single file (or more generally, all function declarations are visible to the compiler) it will willingly inline them. inline could be used to express intent - saying "this function is speed critical, so it needs to be inlined" - but the compiler will inline (or not inline it) regardless. The only real way to force inlining is using a function attribute, __always_inline__ or similar.
    $endgroup$
    – valiano
    Apr 14 at 13:39










  • $begingroup$
    @DeBos99 good catch with xfopen, I've fixed the function name.
    $endgroup$
    – Roland Illig
    Apr 14 at 15:26










  • $begingroup$
    @valiano you are saying that inline is not required, but program runs faster with it, so I think that it should be there.
    $endgroup$
    – DeBos99
    Apr 14 at 16:04
















  • $begingroup$
    Thanks for the review. I forgot to add error check for calloc, so this is why this macro was unused. Why would you remove inline? codereview.stackexchange.com/a/216889/177688 . I names the function get_file_pointer because you are getting file pointer from that function. If I would use x, shouldn't be that xfopen instead of xopen? I will work on my int_to_brainfuck function. In main function input_file should be text I think because I want to read newline as one char (not as two chars e.g. on windows). I will post new code later.
    $endgroup$
    – DeBos99
    Apr 14 at 11:49






  • 1




    $begingroup$
    I added edited code to my post.
    $endgroup$
    – DeBos99
    Apr 14 at 12:30










  • $begingroup$
    @DeBos99 inline is indeed not required: since the program is a single file (or more generally, all function declarations are visible to the compiler) it will willingly inline them. inline could be used to express intent - saying "this function is speed critical, so it needs to be inlined" - but the compiler will inline (or not inline it) regardless. The only real way to force inlining is using a function attribute, __always_inline__ or similar.
    $endgroup$
    – valiano
    Apr 14 at 13:39










  • $begingroup$
    @DeBos99 good catch with xfopen, I've fixed the function name.
    $endgroup$
    – Roland Illig
    Apr 14 at 15:26










  • $begingroup$
    @valiano you are saying that inline is not required, but program runs faster with it, so I think that it should be there.
    $endgroup$
    – DeBos99
    Apr 14 at 16:04















$begingroup$
Thanks for the review. I forgot to add error check for calloc, so this is why this macro was unused. Why would you remove inline? codereview.stackexchange.com/a/216889/177688 . I names the function get_file_pointer because you are getting file pointer from that function. If I would use x, shouldn't be that xfopen instead of xopen? I will work on my int_to_brainfuck function. In main function input_file should be text I think because I want to read newline as one char (not as two chars e.g. on windows). I will post new code later.
$endgroup$
– DeBos99
Apr 14 at 11:49




$begingroup$
Thanks for the review. I forgot to add error check for calloc, so this is why this macro was unused. Why would you remove inline? codereview.stackexchange.com/a/216889/177688 . I names the function get_file_pointer because you are getting file pointer from that function. If I would use x, shouldn't be that xfopen instead of xopen? I will work on my int_to_brainfuck function. In main function input_file should be text I think because I want to read newline as one char (not as two chars e.g. on windows). I will post new code later.
$endgroup$
– DeBos99
Apr 14 at 11:49




1




1




$begingroup$
I added edited code to my post.
$endgroup$
– DeBos99
Apr 14 at 12:30




$begingroup$
I added edited code to my post.
$endgroup$
– DeBos99
Apr 14 at 12:30












$begingroup$
@DeBos99 inline is indeed not required: since the program is a single file (or more generally, all function declarations are visible to the compiler) it will willingly inline them. inline could be used to express intent - saying "this function is speed critical, so it needs to be inlined" - but the compiler will inline (or not inline it) regardless. The only real way to force inlining is using a function attribute, __always_inline__ or similar.
$endgroup$
– valiano
Apr 14 at 13:39




$begingroup$
@DeBos99 inline is indeed not required: since the program is a single file (or more generally, all function declarations are visible to the compiler) it will willingly inline them. inline could be used to express intent - saying "this function is speed critical, so it needs to be inlined" - but the compiler will inline (or not inline it) regardless. The only real way to force inlining is using a function attribute, __always_inline__ or similar.
$endgroup$
– valiano
Apr 14 at 13:39












$begingroup$
@DeBos99 good catch with xfopen, I've fixed the function name.
$endgroup$
– Roland Illig
Apr 14 at 15:26




$begingroup$
@DeBos99 good catch with xfopen, I've fixed the function name.
$endgroup$
– Roland Illig
Apr 14 at 15:26












$begingroup$
@valiano you are saying that inline is not required, but program runs faster with it, so I think that it should be there.
$endgroup$
– DeBos99
Apr 14 at 16:04




$begingroup$
@valiano you are saying that inline is not required, but program runs faster with it, so I think that it should be there.
$endgroup$
– DeBos99
Apr 14 at 16:04













0












$begingroup$

After the first great review by Roland Illig, I could add a few comments on the second code revision, in order of appearance:



  • #include <string.h> - not required now, and could be removed.



  • define ALLOCATION_ERROR 1:

    Rather than preprocessor macros, consider using a named enum. With an enum, you get better diagnostics and type checking from the compiler, plus the error codes are grouped into one named construct:



    enum ERROR_CODES

    ALLOCATION_ERROR = 1,
    FILE_ERROR = 2,
    OTHER_ERROR = 3
    ;


    As a bonus, you get rid of the unused macro warning.




  • It's best to avoid single-line if and for blocks, which could cause subtle and hard to find bugs. I.e.:



    for(int i=0;i<n;++i)
    fputc(c,output_file);


    is better written as:



    for(int i=0;i<n;++i)

    fputc(c,output_file);




  • You could early exit the emit_difference function after the if(difference==0) check. Then, you could reduce the indentation level of the code that follows. This technique comes very handy when you have to check for several conditions before doing the actual work. I.e.,



    if(difference==0)
    fputc('.',output_file);
    else
    // ...



    May turn into:



    if(difference==0)

    fputc('.',output_file);
    return;


    // Code of the else block


  • Style comment: consider adding newlines between your functions, to create a clear separation between them.


  • inline: I second Ronald in that the inline keyword may be safely removed. Since the program is a single file (and more generally, all function declarations are visible to the compiler), it will willingly inline them.






share|improve this answer










New contributor




valiano is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






$endgroup$












  • $begingroup$
    Always use blocks instead of single statements is oft-disputed advice, though I won't restart that style-war here.
    $endgroup$
    – Deduplicator
    Apr 14 at 15:16










  • $begingroup$
    Thanks for review @valiano. I think that using macros for errors is sometimes better e.g. Roland got this warning about unused macro, so I could remove it. Should I add return; at the end of else block or only in if?
    $endgroup$
    – DeBos99
    Apr 14 at 16:09










  • $begingroup$
    @DeBos99 no need for a return at the end of the else block, since the function is to return anyway right afterwards.
    $endgroup$
    – valiano
    Apr 14 at 17:09
















0












$begingroup$

After the first great review by Roland Illig, I could add a few comments on the second code revision, in order of appearance:



  • #include <string.h> - not required now, and could be removed.



  • define ALLOCATION_ERROR 1:

    Rather than preprocessor macros, consider using a named enum. With an enum, you get better diagnostics and type checking from the compiler, plus the error codes are grouped into one named construct:



    enum ERROR_CODES

    ALLOCATION_ERROR = 1,
    FILE_ERROR = 2,
    OTHER_ERROR = 3
    ;


    As a bonus, you get rid of the unused macro warning.




  • It's best to avoid single-line if and for blocks, which could cause subtle and hard to find bugs. I.e.:



    for(int i=0;i<n;++i)
    fputc(c,output_file);


    is better written as:



    for(int i=0;i<n;++i)

    fputc(c,output_file);




  • You could early exit the emit_difference function after the if(difference==0) check. Then, you could reduce the indentation level of the code that follows. This technique comes very handy when you have to check for several conditions before doing the actual work. I.e.,



    if(difference==0)
    fputc('.',output_file);
    else
    // ...



    May turn into:



    if(difference==0)

    fputc('.',output_file);
    return;


    // Code of the else block


  • Style comment: consider adding newlines between your functions, to create a clear separation between them.


  • inline: I second Ronald in that the inline keyword may be safely removed. Since the program is a single file (and more generally, all function declarations are visible to the compiler), it will willingly inline them.






share|improve this answer










New contributor




valiano is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






$endgroup$












  • $begingroup$
    Always use blocks instead of single statements is oft-disputed advice, though I won't restart that style-war here.
    $endgroup$
    – Deduplicator
    Apr 14 at 15:16










  • $begingroup$
    Thanks for review @valiano. I think that using macros for errors is sometimes better e.g. Roland got this warning about unused macro, so I could remove it. Should I add return; at the end of else block or only in if?
    $endgroup$
    – DeBos99
    Apr 14 at 16:09










  • $begingroup$
    @DeBos99 no need for a return at the end of the else block, since the function is to return anyway right afterwards.
    $endgroup$
    – valiano
    Apr 14 at 17:09














0












0








0





$begingroup$

After the first great review by Roland Illig, I could add a few comments on the second code revision, in order of appearance:



  • #include <string.h> - not required now, and could be removed.



  • define ALLOCATION_ERROR 1:

    Rather than preprocessor macros, consider using a named enum. With an enum, you get better diagnostics and type checking from the compiler, plus the error codes are grouped into one named construct:



    enum ERROR_CODES

    ALLOCATION_ERROR = 1,
    FILE_ERROR = 2,
    OTHER_ERROR = 3
    ;


    As a bonus, you get rid of the unused macro warning.




  • It's best to avoid single-line if and for blocks, which could cause subtle and hard to find bugs. I.e.:



    for(int i=0;i<n;++i)
    fputc(c,output_file);


    is better written as:



    for(int i=0;i<n;++i)

    fputc(c,output_file);




  • You could early exit the emit_difference function after the if(difference==0) check. Then, you could reduce the indentation level of the code that follows. This technique comes very handy when you have to check for several conditions before doing the actual work. I.e.,



    if(difference==0)
    fputc('.',output_file);
    else
    // ...



    May turn into:



    if(difference==0)

    fputc('.',output_file);
    return;


    // Code of the else block


  • Style comment: consider adding newlines between your functions, to create a clear separation between them.


  • inline: I second Ronald in that the inline keyword may be safely removed. Since the program is a single file (and more generally, all function declarations are visible to the compiler), it will willingly inline them.






share|improve this answer










New contributor




valiano is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






$endgroup$



After the first great review by Roland Illig, I could add a few comments on the second code revision, in order of appearance:



  • #include <string.h> - not required now, and could be removed.



  • define ALLOCATION_ERROR 1:

    Rather than preprocessor macros, consider using a named enum. With an enum, you get better diagnostics and type checking from the compiler, plus the error codes are grouped into one named construct:



    enum ERROR_CODES

    ALLOCATION_ERROR = 1,
    FILE_ERROR = 2,
    OTHER_ERROR = 3
    ;


    As a bonus, you get rid of the unused macro warning.




  • It's best to avoid single-line if and for blocks, which could cause subtle and hard to find bugs. I.e.:



    for(int i=0;i<n;++i)
    fputc(c,output_file);


    is better written as:



    for(int i=0;i<n;++i)

    fputc(c,output_file);




  • You could early exit the emit_difference function after the if(difference==0) check. Then, you could reduce the indentation level of the code that follows. This technique comes very handy when you have to check for several conditions before doing the actual work. I.e.,



    if(difference==0)
    fputc('.',output_file);
    else
    // ...



    May turn into:



    if(difference==0)

    fputc('.',output_file);
    return;


    // Code of the else block


  • Style comment: consider adding newlines between your functions, to create a clear separation between them.


  • inline: I second Ronald in that the inline keyword may be safely removed. Since the program is a single file (and more generally, all function declarations are visible to the compiler), it will willingly inline them.







share|improve this answer










New contributor




valiano is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this answer



share|improve this answer








edited Apr 14 at 17:07





















New contributor




valiano is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









answered Apr 14 at 14:16









valianovaliano

1266




1266




New contributor




valiano is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





valiano is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






valiano is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











  • $begingroup$
    Always use blocks instead of single statements is oft-disputed advice, though I won't restart that style-war here.
    $endgroup$
    – Deduplicator
    Apr 14 at 15:16










  • $begingroup$
    Thanks for review @valiano. I think that using macros for errors is sometimes better e.g. Roland got this warning about unused macro, so I could remove it. Should I add return; at the end of else block or only in if?
    $endgroup$
    – DeBos99
    Apr 14 at 16:09










  • $begingroup$
    @DeBos99 no need for a return at the end of the else block, since the function is to return anyway right afterwards.
    $endgroup$
    – valiano
    Apr 14 at 17:09

















  • $begingroup$
    Always use blocks instead of single statements is oft-disputed advice, though I won't restart that style-war here.
    $endgroup$
    – Deduplicator
    Apr 14 at 15:16










  • $begingroup$
    Thanks for review @valiano. I think that using macros for errors is sometimes better e.g. Roland got this warning about unused macro, so I could remove it. Should I add return; at the end of else block or only in if?
    $endgroup$
    – DeBos99
    Apr 14 at 16:09










  • $begingroup$
    @DeBos99 no need for a return at the end of the else block, since the function is to return anyway right afterwards.
    $endgroup$
    – valiano
    Apr 14 at 17:09
















$begingroup$
Always use blocks instead of single statements is oft-disputed advice, though I won't restart that style-war here.
$endgroup$
– Deduplicator
Apr 14 at 15:16




$begingroup$
Always use blocks instead of single statements is oft-disputed advice, though I won't restart that style-war here.
$endgroup$
– Deduplicator
Apr 14 at 15:16












$begingroup$
Thanks for review @valiano. I think that using macros for errors is sometimes better e.g. Roland got this warning about unused macro, so I could remove it. Should I add return; at the end of else block or only in if?
$endgroup$
– DeBos99
Apr 14 at 16:09




$begingroup$
Thanks for review @valiano. I think that using macros for errors is sometimes better e.g. Roland got this warning about unused macro, so I could remove it. Should I add return; at the end of else block or only in if?
$endgroup$
– DeBos99
Apr 14 at 16:09












$begingroup$
@DeBos99 no need for a return at the end of the else block, since the function is to return anyway right afterwards.
$endgroup$
– valiano
Apr 14 at 17:09





$begingroup$
@DeBos99 no need for a return at the end of the else block, since the function is to return anyway right afterwards.
$endgroup$
– valiano
Apr 14 at 17:09


















draft saved

draft discarded
















































Thanks for contributing an answer to Code Review Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

Use MathJax to format equations. MathJax reference.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f217422%2fprogram-that-generates-brainfuck-code-that-outputs-given-text%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Club Baloncesto Breogán Índice Historia | Pavillón | Nome | O Breogán na cultura popular | Xogadores | Adestradores | Presidentes | Palmarés | Historial | Líderes | Notas | Véxase tamén | Menú de navegacióncbbreogan.galCadroGuía oficial da ACB 2009-10, páxina 201Guía oficial ACB 1992, páxina 183. Editorial DB.É de 6.500 espectadores sentados axeitándose á última normativa"Estudiantes Junior, entre as mellores canteiras"o orixinalHemeroteca El Mundo Deportivo, 16 setembro de 1970, páxina 12Historia do BreogánAlfredo Pérez, o último canoneiroHistoria C.B. BreogánHemeroteca de El Mundo DeportivoJimmy Wright, norteamericano do Breogán deixará Lugo por ameazas de morteResultados de Breogán en 1986-87Resultados de Breogán en 1990-91Ficha de Velimir Perasović en acb.comResultados de Breogán en 1994-95Breogán arrasa al Barça. "El Mundo Deportivo", 27 de setembro de 1999, páxina 58CB Breogán - FC BarcelonaA FEB invita a participar nunha nova Liga EuropeaCharlie Bell na prensa estatalMáximos anotadores 2005Tempada 2005-06 : Tódolos Xogadores da Xornada""Non quero pensar nunha man negra, mais pregúntome que está a pasar""o orixinalRaúl López, orgulloso dos xogadores, presume da boa saúde económica do BreogánJulio González confirma que cesa como presidente del BreogánHomenaxe a Lisardo GómezA tempada do rexurdimento celesteEntrevista a Lisardo GómezEl COB dinamita el Pazo para forzar el quinto (69-73)Cafés Candelas, patrocinador del CB Breogán"Suso Lázare, novo presidente do Breogán"o orixinalCafés Candelas Breogán firma el mayor triunfo de la historiaEl Breogán realizará 17 homenajes por su cincuenta aniversario"O Breogán honra ao seu fundador e primeiro presidente"o orixinalMiguel Giao recibiu a homenaxe do PazoHomenaxe aos primeiros gladiadores celestesO home que nos amosa como ver o Breo co corazónTita Franco será homenaxeada polos #50anosdeBreoJulio Vila recibirá unha homenaxe in memoriam polos #50anosdeBreo"O Breogán homenaxeará aos seus aboados máis veteráns"Pechada ovación a «Capi» Sanmartín e Ricardo «Corazón de González»Homenaxe por décadas de informaciónPaco García volve ao Pazo con motivo do 50 aniversario"Resultados y clasificaciones""O Cafés Candelas Breogán, campión da Copa Princesa""O Cafés Candelas Breogán, equipo ACB"C.B. Breogán"Proxecto social"o orixinal"Centros asociados"o orixinalFicha en imdb.comMario Camus trata la recuperación del amor en 'La vieja música', su última película"Páxina web oficial""Club Baloncesto Breogán""C. B. Breogán S.A.D."eehttp://www.fegaba.com

Vilaño, A Laracha Índice Patrimonio | Lugares e parroquias | Véxase tamén | Menú de navegación43°14′52″N 8°36′03″O / 43.24775, -8.60070

Cegueira Índice Epidemioloxía | Deficiencia visual | Tipos de cegueira | Principais causas de cegueira | Tratamento | Técnicas de adaptación e axudas | Vida dos cegos | Primeiros auxilios | Crenzas respecto das persoas cegas | Crenzas das persoas cegas | O neno deficiente visual | Aspectos psicolóxicos da cegueira | Notas | Véxase tamén | Menú de navegación54.054.154.436928256blindnessDicionario da Real Academia GalegaPortal das Palabras"International Standards: Visual Standards — Aspects and Ranges of Vision Loss with Emphasis on Population Surveys.""Visual impairment and blindness""Presentan un plan para previr a cegueira"o orixinalACCDV Associació Catalana de Cecs i Disminuïts Visuals - PMFTrachoma"Effect of gene therapy on visual function in Leber's congenital amaurosis"1844137110.1056/NEJMoa0802268Cans guía - os mellores amigos dos cegosArquivadoEscola de cans guía para cegos en Mortágua, PortugalArquivado"Tecnología para ciegos y deficientes visuales. Recopilación de recursos gratuitos en la Red""Colorino""‘COL.diesis’, escuchar los sonidos del color""COL.diesis: Transforming Colour into Melody and Implementing the Result in a Colour Sensor Device"o orixinal"Sistema de desarrollo de sinestesia color-sonido para invidentes utilizando un protocolo de audio""Enseñanza táctil - geometría y color. Juegos didácticos para niños ciegos y videntes""Sistema Constanz"L'ocupació laboral dels cecs a l'Estat espanyol està pràcticament equiparada a la de les persones amb visió, entrevista amb Pedro ZuritaONCE (Organización Nacional de Cegos de España)Prevención da cegueiraDescrición de deficiencias visuais (Disc@pnet)Braillín, un boneco atractivo para calquera neno, con ou sen discapacidade, que permite familiarizarse co sistema de escritura e lectura brailleAxudas Técnicas36838ID00897494007150-90057129528256DOID:1432HP:0000618D001766C10.597.751.941.162C97109C0155020