Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

CPP

Name: Anonymous 2011-11-27 10:04

Hi,

is it a good practice to write this #def in cpp?

#define print(X) std::cout<<X<<std::endl

so that it can be used as:

print("what " << "ever" << " I " << "want");

btw.. how do I insert sniplet of code here?

Name: Anonymous 2011-11-27 10:05

is it a good practice to write this #def in cpp?
No.

how do I insert sniplet of code here?
Read SICP.

Name: Anonymous 2011-11-27 10:05

>>1
No. Don't use C++ iostreams, no one uses them outside of toy programs anyway.

Use Standard C printf/vnprintf based functions.

Name: Anonymous 2011-11-27 10:11

>>2
what is SICP?

>>3
>don't use c++ iostream
why?
btw is just to print out debugging info to the console, if I want to print out something needed for my app probably I will use the printf version...

Name: Anonymous 2011-11-27 10:11

>>3
No. Don't use standard C text output, no one uses it outside of toy programs anyway.

Use POSIX write based functions.

Name: Anonymous 2011-11-27 10:12

>>5
no don't use POSIX, it will only work in unix based system, draw the letter directly by modifing the pixels on your machine...

Name: Anonymous 2011-11-27 10:13

>>4
whatis SICP?
A miserable little pile of abstractions!

Name: Anonymous 2011-11-27 10:14

>>1
Don't listen to >>2-3, they are kind of fag...

Though that would be pretty bad practice.

You can insert code snippets here using [code] tag (google for bbcode if you don't know what it means)

Name: Anonymous 2011-11-27 10:16

>>4
Build two small program that print hello world, one using printf, the other using cout. Compare the difference in size of the resulting binaries. C++ iostreams are bloated and slow.

>>5
printf is a POSIX function, it's in both POSIX and the Standard C specifications. write doesn't do text based formatting and conversion of integers/floats to text.

Name: Anonymous 2011-11-27 10:18

really???
[quote] bbcode [/quote]
I just have to write bbcode?
I could have tried before asking... damn me...


HAI
CAN HAS STDIO?
VISIBLE "HAI WORLD!"
KTHXBYE

Name: Anonymous 2011-11-27 10:20

>>9
C++ iostreams are bloated and slow
I agree they might be little bloated compared to C-functions. They are, however, superior to C-functions, because they are typesafe and extensible.

And it doesn't matter if you output to terminal. It will always be very slow, no matter if using iostream or stdio. The difference is not even measurable.

Name: F r o z e n V o i d !!mJCwdV5J0Xy2A21 2011-11-27 10:22

>>5
You can be even faster if you set the terminal window content to an array pointer which has your data.(a single pointer change)

Name: Anonymous 2011-11-27 10:22

http://yosefk.com/c++fqa/io.html

Name: Anonymous 2011-11-27 10:26

>>12
Thats a horrible, unportable hack.

Name: Anonymous 2011-11-27 10:27

>>1
Yes, this is a common practice. You can also include as much namespaces as you use to make your code shorter and therefore more readable:
using namespace std;
#define print(X) cout<<X<<endl

Name: Anonymous 2011-11-27 10:33

>>15
I see!

btw... you can put your using namespace std; even in the print:

#define print(X) using namespace std; cout<<X<<endl

Name: Anonymous 2011-11-27 10:36

>>15
Namespace pollution is a Bad Thing.

Name: F r o z e n V o i d !!mJCwdV5J0Xy2A21 2011-11-27 10:39

>>14
Pfft, thats nothing, you can write OpenGL-accelerated 1000+ fps Terminal with Unicode and colors, if you were serious about it and provide  termio/stdio api to the called functions or hooks like changing content pointer,vsync and flipping buffers.

Name: Anonymous 2011-11-27 10:41

A Jew came up with the concept for the C++ iostreams library. Avoid it, unless you want to become a shabbos goy.

Name: Anonymous 2011-11-27 10:41

btw:

printf:0.019151s cout:0.01957s

with this program:



#include <iostream>
#include <ctime>

int main (int argc, char * const argv[]) {
    clock_t cstart,cend,cppstart,cppend;
   
    cstart = clock();
    for (int i =0; i < 10000; ++i) {
        printf("Hello World\n");
    }
    cend = clock();
    double diff_c = cend/(float)CLOCKS_PER_SEC - cstart/(float)CLOCKS_PER_SEC;
   
    cppstart = clock();
    for (int i = 0; i<10000; ++i) {
        std::cout<<"Hello World\n";
    }
    cppend = clock();
   
    double diff_cpp = cppend/(float)CLOCKS_PER_SEC - cppstart/(float)CLOCKS_PER_SEC;
   
    std::cout<< "c:" << diff_c << "cpp:" << diff_cpp<< std::endl;
    std::cout<< std::endl;
    return 0;
}

Name: Anonymous 2011-11-27 10:46

>>19
http://www2.research.att.com/~bs/hopl2.pdf
Jerry Schwarz reimplemented and partially redesigned the
streams library

You weren't joking.

Name: Anonymous 2011-11-27 10:49

>>20
std::time only has millisecond resolution, nor is it guaranteed to be monotonic. You can't use it for serious timing.

If you're on a POSIX system, use clock_gettime with CLOCK_CLOCK_THREAD_CPUTIME_ID, which has accurate monotonic nanosecond resolution time for the calling thread, and doesn't take into account process/thread context switching.

http://linux.die.net/man/3/clock_gettime

Name: Anonymous 2011-11-27 10:56



>>22
too much work...

Name: Anonymous 2011-11-27 11:09

Awww, too hard for the little baby...

timespec start, end;
double seconds;
clock_gettime(CLOCK_CLOCK_THREAD_CPUTIME_ID, &start);
// do shit
clock_gettime(CLOCK_CLOCK_THREAD_CPUTIME_ID, &end);
seconds = (end.tv_sec - start.tv_sec) + (end.tv_nsec - start.tv_nsec) / 1000000000.0;

Name: Anonymous 2011-11-27 11:11

dumb q: why is it CLOCK_CLOCK_THREAD_CPUTIME_ID and not just CLOCK_THREAD_CPUTIME_ID

Name: F r o z e n V o i d !!mJCwdV5J0Xy2A21 2011-11-27 11:12

>>20-24
The lengths people go to avoid using RDTSC, just because its "unportable asm"

Name: Anonymous 2011-11-27 11:12

It shows that >>1 didn't even bother to lurk at least twenty seconds and doesn't care about us enough to use proper punctuation, yet you respond to it.

Name: Anonymous 2011-11-27 11:22

>>26
RDTSC is obsolete, and doesn't work as you would expect on modern CPUs that self-adjust the clock frequency to reduce power consumption and maximize performance, like the Core i5/i7 series.

The recommended way on modern x86-64 PC systems for some time has been to use the HPET hardware, which is somewhat more complicated to use because it's a separate chip and requires BIOS support.

http://en.wikipedia.org/wiki/High_Precision_Event_Timer

Name: Anonymous 2011-11-27 11:48

>>28
You completely miss the point. RDTSC actually is a better performance-measurement tool than time precisely because modern CPU can self-adjust their frequency.

Name: Anonymous 2011-11-27 11:55

>>29
Nope. Doesn't take into account interrupts and thread context switching. cli/sti instructions don't work in user mode on modern operating systems, the interrupt flag is protected by ring 0, they're no-ops or cause a protection fault (and the fault handler generally just treats it as a no-op).

Name: Anonymous 2011-11-27 11:59

>>28,29
In the first Core architecture (brand name "Core 2 Duo"), RDTSC indeed scaled with frequency, as you'd expect.

However on Sandy Bridge (haven't tested on Nehalem) it seems it always runs at the chip's nominal frequency.

Some old games that used to be very broken on variable speed CPUs seem to work perfectly too. Cycle performance counters report >2 billion cycles used by a single thread in a second, even when the CPU is locked at much lower speeds.

So maybe they realized this was a compatibility problem and gave up and just turned RDTSC into a high-frequency fixed clock.

RDTSC actually is a better performance-measurement tool than time precisely because modern CPU can self-adjust their frequency.
Sort of. The CPU/memory ratio, which is significant for some workloads, will vary, and cycle counting doesn't compensate for that. Learn to use your OS, it provides interfaces to lock the CPU frequency to any given value. For turbo enabled CPUs, you can lock them to their nominal frequency (there's no need to disable it in the BIOS).

Name: Anonymous 2011-11-27 12:00

>>30
Doesn't take into account interrupts and thread context switching.
That's just bullshit. No OS I know of fiddle with the TSC on context switch.

Name: Anonymous 2011-11-27 12:02

>>32
No OS I know of fiddle with the TSC on context switch.
Exactly. Which means that TSC ends up being polluted by the number of cycles elapsed from executing the code to handle the context switch, or other interrupt handlers, resulting in an inaccurate reading.

Name: Anonymous 2011-11-27 12:06

>>33
That isn't really pollution. Different codes with the same purpose can cause additional context switches and it's good to be able to detect such inneficiencies.

Name: F r o z e n V o i d !!mJCwdV5J0Xy2A21 2011-11-27 12:29

RDTSC is only unreliable if you use it for long intervals(for which clock() is better suited) when context switches/interrupts occur

Name: Anonymous 2011-11-27 13:54

>>24
damn... it doesn't compile... gettime not in scope...
mac OSX 10.6.8, Xcode 4, gcc

Name: Anonymous 2011-11-27 14:05

>>36
Mac OS X doesn't have the POSIX clock_gettime function because it is shit and not fully POSIX 2008.1 compliant. Instead, it has mach_absolute_time.

http://developer.apple.com/library/mac/#documentation/Darwin/Conceptual/KernelProgramming/services/services.html

Name: Anonymous 2011-11-27 14:18

>>37
I knew it, unix is better than macosx...

Name: Anonymous 2011-11-27 16:40

holy shit the autism in this thread

>>1-san: Why do you use macros in C++? Are you autistic? No, don't answer that, you clearly are.

here's the non-autismal-as-fuck version:

template<typename Stream, typename Type>
void print(Stream st, Type item)
{
    st << item << std::endl;
}

template<typename Type>
void print(Type item)
{
    print(std::cout, item);
}

Name: Anonymous 2011-11-27 17:55

>>39
templates
oh wow

Name: Anonymous 2011-11-27 19:14

>>40
c++.
c++ has... why the fuck do i even try to argue with an autismal subhuman like you?

just go back to your LITHPu, you scum

Name: Anonymous 2011-12-02 17:53

>>39
your solution 225 characters

his solution 40 characters

result? pretty much the same...

Name: sage 2012-01-16 19:23

>test
|♖|♘|♗|♕|♔|♗|♘|♖|
|♙|_|_|♙|♙|♙|♙|♙|
|_|♙|_|_|_|_|_|_|
|_|_|_|_|_|_|_|_|
|_|_|♙|♟|_|_|_|_|
|_|_|♟|♛|_|_|_|_|
|♟|♟|_|_|♟|♟|♟|♟|
|♜|♞|♝|_|♚|♝|♞|♜|

Name: Anonymous 2012-01-16 20:01

>>43

|♖|♘|♗|♕|♔|♗|♘|♖|
|♙|_|_|♙|♙|♙|♙|♙|
|_|♙|_|_|_|_|_|_|
|_|_|_|_|_|_|_|_|
|_|_|♙|♟|_|_|_|_|
|_|_|♟|♛|_|_|_|_|
|♟|♟|_|_|♟|♟|♟|♟|
|♜|♞|♝|_|♚|♝|♞|♜

Name: Anonymous 2012-01-16 20:16

NIGGER FORTITUDE

Name: Anonymous 2012-01-16 21:52

>>43
So. . . Many. . . Failures. . . And all in a single post too. . .
Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List
All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode -