Alright Sup Forums

Alright Sup Forums.
cout or printf? Which one is better?

Other urls found in this thread:

en.cppreference.com/w/cpp/memory/new/operator_new
github.com/nothings/stb/blob/master/stb_sprintf.h
stackoverflow.com/a/25615981
twitter.com/AnonBabble

cout ofc

The methodology that allows C's printf library to work the way it does is fully accessible to the user so they may write their own printf library.
It's called stdarg.h.

Good luck figuring out how C++98 overloaded the goddamn >>

format

print! > printf > cout

cout.

The real question is "new" or "malloc"

new ofc

std::experimental::pmr::polymorphic_allocator or gtfo

operator overloading was a mistake, but streams are nice

make_shared :^)

cout

cout is like printf but for smart people.

Professionals use printf.

new is problematic because it's an operator. It has massive overhead if you wish to use another allocator.

With malloc you just change your calling convention. You can easily detect every instance of malloc and replace. If you aim to do the same with a codebase which uses new you'd either have to overload the new for every struct and class, including the primitives, or replace it all with different function calls.

It's beyond me why they would make it like this. They could easily have had a more convenient way to let you choose allocator without writing a massive set of overloads. As it stands the malloc interface is less of a bad design and more of a limited design.

printf is way more readable

>streams are nice
Elaborate.

the pro with it being an operator is that you can overload it. Then you can use a memory pool, getting around the problem of allocating in runtime.

I think streams are a good abstraction for I/O. The stream analogy works nicely for files, pipes, sockets, and terminal I/O. I think Java's Stream API is a bit more sensible, and I think the overloading of > for stream reading and writing is very stupid.

Streams seem like overkill when writing simple text-only programs, but when managing multiple I/O sources, streams that can be opened and closed with uniform function names are nice.

In addition, while printf and family are not bad, the ability to overload the stream print and read methods for different data types is really convenient, and allows different libraries to present the same interface for printing, as well as for other forms of I/O.

I'm looking forward to when C++ has a cross-platform socket stream in the standard library, but I hear Boost has one already.

Using printf:
unsigned a = 0x1337;
printf("0x%08X\n", a);


Using cout:
unsigned a = 0x1337;
std::cout

void StreamPrintf(std::ostream stream, const char *format, ...) {
char buffer[1024];
va_list args;
memset(buffer, 0, sizeof buffer);
va_start(args, format);
vsnprintf(buffer, (sizeof buffer) - 1, format, args);
va_end(args);
stream

So now you have to overload it for every single type user. That's the problem.
New should be settable. (at least that's a simple solution, more is required)
>then you can use a memory pool
You could try any other allocation scheme, many of which require more than the operator new permits.
If you want a good solution you end up with a template/macro mess.

Of course you can get wherever you want with sufficient amounts of code but that's never what programming languages are about.

I end up adding this function in every C++ program I write, the format system is really useful

I love c++1x so I probably have brain damage but even I prefer printf

>So now you have to overload it for every single type user
no

printf is good for quick and dirty output and simple things. It comes with the flexibility of C with all the security and other hazards of C.

cout has proper type checking and casting. Formatting is extremely explicit making code easier to read. Being able to pipe the stream wherever is also nice. Complex formatting jobs can be a bitch to write. Default buffering can do odd things on the command line. Sometimes overloaded or templated stream operators can shit themselves when converting code from ASCII to wide/unicode.

me too, my man

Explain how I can use a single allocator new for every type in the language without specifying it for my types.

puts

cout > printf but \n > endl by far

>my types.
Oh and for the primitives too obviously.

templates my dude, probably the most worthwhile C++ feature imo

Would be nice if every language overloaded the '%' operator for strings like ruby and python.

Isn't str.format() the preferred method in python now?

I don't see how templates would automatically get you beyond what a global replacement would.

Whoops, I was incorrect. I just checked what the operator overload options are for templates, and you're correct, templates would not resolve this. In that case then, why isn't a global replacement sufficient?

Alignment mostly. You can always constrain yourself to the most extreme case for your machine but that's very wasteful.
If you look into actual shipping allocators they're not all that simple. I can't say I'd need more than adjusting alignment personally though.

puts

Hmm, well that's a pretty clear shortcoming in the language. I'd think that typespecific overloads for new would be a thing, but apparently not.

>So now you have to overload it for every single type user. That's the problem.

Naah, only for things that are allocated at runtime; which shouldn't be that much.
I don't even have to differentiate between an overloaded new and a regular new when doing the actual coding, just call new every time.

I think the power to define what the allocator actually does from time to time is better, plus it's type safe.
But I guess it's a matter of preference.

ooh, another good thing I like about new, is that it actually calls the constructor of the object you want to allocate, whereas malloc does not.

Both are garbage.
printf - runtime interpreting of the format string every time, slow as shit.
iostreams - just inherently slow as shit, global state changes, verbose as fuck.

Maybe it'd be nice to be able to specify from a global set of allocators too.
Yeah you can overload for specific types but that's not really the end goal..
en.cppreference.com/w/cpp/memory/new/operator_new
As you see they're fixing alignment that with C++17.
They're super late.

Really it's kinda worthless to use half-assed features. I'd much rather just use a function-based interface at that point.
>only for things allocated at runtime
user this is all very trivial if you don't have any need for dynamic allocation obviously. Regardless of the amount that's being allocated you need good facilities to manage it well. Having to work around specific cases in your code is always a hassle, hits you in the morale pretty hard I'm sure you agree.
>printf - runtime interpreting of the format string every time, slow as shit.
Compilers often allow themselves to optimize many of the standard library features aggressively. But they certainly don't do it as well as you could with a custom solution. And of course their solutions aren't as good as they could be even for a generic case:
github.com/nothings/stb/blob/master/stb_sprintf.h
I kinda just assumed that these functions would be really well optimized but these numbers are nuts.

Yes, there is a bit of hassle, but I firmly think it's worth it as I don't have to worry about allocating enough space. Heap corruptions are a nightmare to debug.

print("{}".format("yes"))

printf("std::cout");

print("{0}".format("yes"))

im relative newfag so i dont know how to post code but the point is you need a 0 in the braces so that you could keep going with more insertion variables in the .format() call

std::cout

it doesnt compile

This.

.format() will automatically go to the next positional argument after each {} in your string. You only need a number if you need a specific positional argument.

well i'll be... how did i never notice this?

write(1, str, strlen(str)); ofc

inferior
here's the supreme version

print(f"{'yes'}")

I quite admire the level of knowledge you guys got on this, but may I ask, is this book still relevant to learn C as its used today?

or should I go straight with C++?

Whatever your answer is, can you recommend a book?

thanks.

if you don't know/know little C it's still relevant.

This post is not meant for normal sjw tier /g users.

I've been learning C off and on for a decade and over the past couple years it's become my go-to language and one I nearly know by heart

I can't think of any feature of C++ I miss, that couldn't be replaced by better design patterns anyways

objects and generics are bad for computers and bad for effectively solving problems
and even the things that are rationally modeled by objects can be designed just as easily by struct object and int object_method(struct object self)

>objects and generics are bad for computers and bad for effectively solving problems
>and even the things that are rationally modeled by objects can be designed just as easily bystruct object
and
int object_method(struct object self)
Does KRC has this concept explained in it?
int object_method(struct object self)
I am in chapter 6 and haven't found this.

Which book are you talking about nigger?

>I quite admire the level of knowledge you guys got on this, but may I ask, is this book still relevant to learn C as its used today?
Barely. It only covers C89, and the terse programming style it promotes is too clever by half at best, outright dangerous at worst.

It is a neat historical artifact, and I have a copy for that reason alone, but I would never use it as a tutorial or a reference.

Something Patrick Wyatt said in a Q&A where he was asked specifically about old books and if they're any good to read he mentioned K&R and how it didn't really help him much with programming in C coming from a Pascal background (indented audience for the book really).
Having learned from it I can't exactly say I'm as negative as he seemingly was but perhaps that's lack of greater insight. His complaint was that it teaches you about all the C features but it doesn't really give you ideas into how you would use them. Perhaps he had a period where he had issues supplementing that knowledge and it really stuck with him. But either way I see the case that it's not a particularly pragmatic book even though it may seem very down with the language. Learning materials that have you solve issues using what you learn would probably be more to his liking.
C++ books more often than not teaches the higher level parts of the language a lot. They have a tendency to shy away from teaching a good understanding of the basic blocks the language is based on.
I don't know of good C books but I'd look for that rather than reading K&R because I see the issues mentioned.

It's just a function. It's not really a concept that needs explaining. Whereas in C++ all object methods are placed within the object itself, and called from the object, in C the object would hold just its data and it's 'methods' would be functions you'd call and just pass in the object as a parameter. For example, in C++ you'd do:
class Object {
int value;
void method() {
std::cout

I have to ask why you don't prefer using the C++ version. It's equivalent and gives you plenty of convenience for that specific situation.
I don't find that object programming is ever that useful but if I were to do it I'd certainly pick C++ over C for it.

You said it yourself, I don't find that object programming is ever that useful either.
Most of my projects are in C and I don't really use objects at all. But if I, for some reason, wanted to add sort of objects to something I worked on, I'd just do the latter in C and not switch the entire codebase to C++.

Also I hate the STL with a burning passion and that's reason enough for me to not want to use C++ ever.

Friendly reminder that nested types of the form are confused as shift operators AND stream operators because C++ is so shit.

No, Gone With The Wind isn't particularly useful for learning C.

Yes, Now I should ask you. The template is very powerful. I don't think C is capable of compile time(statically as some people say) decision of defining function signature or declaring function.Is it never required in software development or this can be achieved with some hacks in C?

It can be achieved with hacks, to list some:
void pointers, opaque types, union types, tagged unions, macros.
But the idea is different. Usually in C you're very conscious of the kind of data you're using and only in very few cases will you want the same function for different types. Usually types are well-defined and the functions that operate them are just as well-defined. C is, in general, more concrete than abstract.

System.out.println

Most of my compile time evaluation is done by writing another program that outputs the data I wanted compile time evaluated.
It's not the most pretty but it beats constexpr, and it can be a rather slow solution usually as I just need to hash the source files to see if it needs to be compiled/re-run in my build system.

It's pretty nice for what it is but it's clearly not the strong suit of C. Data entry in C is very poor overall.

You are saying abstract function definitions are not required as much as people think they would require?And if required C hacks are "better" or C hacks can get the job done while not being "better" than C++ couterpart?

printf is faster than cout.

don't ask me how i know.

putchar > all

Can anyone explain this?
I used a constructor that has int type parameter.
So whatever int literal I pass it is copied to that parameter which I would use to initialize int& i member variable. But since contructor parameter was automatic/temporary object, how does that struct foo object still prints i member variable?
Is this some C++ "good guys" optimized thing or I am missing something?
#include
struct foo{
int& i;
//foo(int& _i):i(_i){}
foo(int l):i(l){}
void print();
};
void foo::print(){
std::cout

Both are inferior to echo

Reminder that since c++14

return (x);
and
return x;

are two different things :^)

How?

I guess
return (x)
would cast it to the return type of declared return type of function. So basically more sjw elements. #FREEDOM

I am not smart enough to explain so:
stackoverflow.com/a/25615981

The real question is why are you doing "struct foo ebin()"?

This is retarded

C++ is such an intuitive language. And of course we all know about these fine relevant details in the language and then it's easy.
I don't see what people are complaining about when they say C++ is unwieldy.

ebinnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn

You don't need to specify that it's a struct when declaring it; foo ebin() would have been enough

from __future__ import print_function
print(" is better")

Not in C++11 anymore

what the fuck? is this real?

im drunk

i know that. u thought i would not know that?
I have OCD.

puts

only use getchar_unclocked() and putchar_unlocked()
All you need, and is up to 5x faster than printf/cout.
For example to read some integers with getchar_unlocked safely omiting whitespace:

template
inline bool sc(T &num){
bool neg=0;
int c;
num=0;
while(c=getchar_unlocked(),c47;c=getchar_unlocked())
num=num*10+c-48;
if(neg)
num*=-1;
return true;
}
template
inline void sc(T &num, Args &...args){
bool neg=0;
int c;
num=0;
while(c=getchar_unlocked(),c47;c=getchar_unlocked())
num=num*10+c-48;
if(neg)
num*=-1;
sc(args...);
}


and then you can just get all numbers like this:
int a,b,c;
sc(a,b,c);


You can make this into 1 line, and put it into your c++ template file, really worth it man

System.Console.Write

puts

mah nigga!

Now, how are you gonna quickly output an integer, or input an integer?

INT 21 AH=09

The fact a language lets you do the same thing in more than one way = trash