newbie Question

Pages: 12


I learn C can i post C prob in here or i just got to post C++?

I going to learn C first that why i am asking.:)
C is mainly a subset of C++ and most C++ programmers know C so you can ask also things regarding C.

Is not really good learning C before C++ as you may get used to solutions which aren't good in C++
I like C. The only thing I like more about C++ is the STL (standard template library); particularly std::strings and std::vectors. Otherwise, the C lib is perfect for me.

Although this is probably mostly because I haven't learned classes and templates properly yet. I'm more interested in all things low-level and in data structures (structs not classes) than anything else.
Reason i ask was i couldn't find no better place to learn C and C++.

Maybe i should learn C++ but not sure what C++ is good for.


thank for the ideas:)
C++ is good at almost anything.
With C++ you can do the same things of C but more efficiently and in an easier way.
If you want to learn C++ try the tutorials: http://www.cplusplus.com/doc/tutorial/
I got a C++ primer book 4th

And i think i start to read it againSo you saying i can use sys/socket.h in my C++ programs?
Yes
closed account (1wqDSL3A)
Definetly! Do not fool yourself into thinking that you gotta learn C first to write programs in C++ later!. C++ is faster, more efficient and easier (i personally think it is!) to learn and work with. I am quite sure these tutorials http://www.cplusplus.com/doc/tutorial/ are obest in web. In addition get one of the Stroustrup's book after you learn more advanced concepts.
^I agree.
Pfft! What? C++ easier than C? I don't even want to imagine what kind of hellish dialect of C you've been exposed to. It may be more practical to do certain things in C++, but C a lot simpler than C++.
Well, some things are simpler, especially beginner stuff.

e.g.:
C++:
1
2
3
4
5
6
std::cout << type1 << type2 << type3 << ...;
std::getline(std::cin, some_string); //unlimited data
//or even
std::cin >> my_int;
//although this leaves you with a '\n' and can glitch, same thing happens to scanf, and it's
//harder to handle the error (IMO) 


C:
1
2
3
printf("%d%f%lf%s", someint, somefloat, somedouble, somestring);
scanf("%20s", some_char_ptr_over_20_in_length);
//have to remember to keep the & on non-pointers as well 
Last edited on
closed account (z05DSL3A)
In addition get one of the Stroustrup's book after you learn more advanced concepts.

or start with one of the: Programming -- Principles and Practice Using C++
http://www.research.att.com/~bs/programming.html
closed account (1wqDSL3A)
Pfft! What? C++ easier than C? I don't even want to imagine what kind of hellish dialect of C you've been exposed to. It may be more practical to do certain things in C++, but C a lot simpler than C++.
I'm not talking about syntax. The same calculations, etc. are a lot easier to use in c++ than c. Maybe c syntax is easier but c++ - more efficient.
The same calculations, etc. are a lot easier to use in c++ than c.
Could you give an example?

Maybe c syntax is easier but c++ - more efficient.
What do you mean? That it takes up less space? Well, yeah, I suppose that's true, what with templates and other constructs. But I don't see how it makes the language any easier.
As C++ has more paradigms, accomplishing the same thing in C++ is easier than C as you can choose the way you like most.
C++ may take longer to learn than C as it is a bigger language but it's certainly easier to use
Could you give an example?

std::string > C-string (const char* str, char str[])
However I don't like OOP, so...

What do you mean? That it takes up less space? Well, yeah, I suppose that's true, what with templates and other constructs. But I don't see how it makes the language any easier

I think in C typecasts make more sense: volatile char* str = (volatile char*) number vs volatile char* str = volatile char*(number).

I also dislike that in C++ you're "not meant" to use the C preprocessor.

C++ may take longer to learn than C as it is a bigger language but it's certainly easier to use

C is meant to be a compact language. In fact, if I quote (roughly); K&R says "C is a compact language." C++ is too big... C is meant to be a portable, higher-level assembly. It doesn't need classes... hence C++; but it shouldn't be so big.

Could someone tell me whether this:
1
2
    struct myStruct* myStruct_object;
    myStruct_object->myVariable;

is any faster than
1
2
    struct myStruct myStruct_object;
    myStruct_object.myVariable;
?
Because apparantly pointer notation tends to be faster than other things, e.g.
1
2
3
4
5
6
7
8
9
size_t strlen(const char* str) {
    size_t i = 0;
    /* This: */
    for (; *str != '\0'; str++, i++);
    return i;
    /* is supposedly faster than this: */
    for (; str[i] != '\0'; i++);
    return i;
}


which I think could also be written as
1
2
3
4
5
6
size_t strlen(const char* str) {
    size_t i = 0;
    while (*str++)
        i++;
    return i;
}
Last edited on
I also dislike that in C++ you're "not meant" to use the C preprocessor.
You can use the preprocessor in C++. The only thing is that macros should be replaced by inlined functions

C++ is too big... but it shouldn't be so big.
I can't think any C++ feature I would like to be removed. Is this which makes C++ great, it has may different tools you can choose from.

C is meant to be a portable, higher-level assembly. It doesn't need classes...
If C doesn't need classes why does it have structures?
It doesn't need classes because it has structures, unions and enumerations. It needs them because it they're incredibly useful. Unions, for example, are very memory-efficient. But it doesn't need classes. In C++ there's no difference between the two. In C; structs cannot contain functions. But they can contain pointers to functions; so it isn't really important.
Last edited on
std::string > C-string (const char* str, char str[])
Okay, assuming I agreed with that definition of "calculation", C++ doesn't make it easier than a string library would.

I think in C typecasts make more sense: volatile char* str = (volatile char*) number vs volatile char* str = volatile char*(number).
Hahahahah! Ah... Both are the same cast using a different syntax.
A cast is a unary operator and there's two versions:
'(' type ')' expression
type expression
(I'm not sure, but both version may actually be condensed into "type_expression expression")
Being an operator, it has precedence. Sometimes you'll want to surround the expression in parentheses to make sure the compiler knows exactly which expression you're trying to cast. That's why it's not unusual to see a cast as T(x), rather than (T)x.

Could someone tell me whether this:
struct myStruct* myStruct_object;
myStruct_object->myVariable;
is any faster than
struct myStruct myStruct_object;
myStruct_object.myVariable;
?
The latter is faster because it just accesses the stack. The former first accesses the stack, then dereferences a pointer.
These are equivalent:
1
2
struct{int a,b,c;} a;
a.a=0;

1
2
int a,b,c;
a=0;


(First strlen() snippet)
There's a lot of debate about which version is faster after compiler optimizations. There's no clear answer.

It doesn't need classes because it has structures, unions and enumerations. It needs them because it they're incredibly useful. Unions, for example, are very memory-efficient. But it doesn't need classes. In C++ there's no difference between the two. In C; structs cannot contain functions. But they can contain pointers to functions; so it isn't really important.
Or maybe, just maybe, it doesn't need classes because it's not OO.
Hahahahah! Ah... Both are the same cast using a different syntax.

What, they're used for both languages? I didn't know that...

The latter is faster because it just accesses the stack. The former first accesses the stack, then dereferences a pointer.

Thanks.

It doesn't need classes because it has structures, unions and enumerations. It needs them because it they're incredibly useful. Unions, for example, are very memory-efficient. But it doesn't need classes. In C++ there's no difference between the two. In C; structs cannot contain functions. But they can contain pointers to functions; so it isn't really important.
Or maybe, just maybe, it doesn't need classes because it's not OO

That's sort of what I was getting at. It doesn't need classes because it has structs. Structs are a suitable replacement. Ergo it doesn't need to be OO, so it isn't. But in K&R they say they chose not to "force" OOP, but "allowed" it, and made it possible. They didn't want a "one-size-fits-all" solution, which, IMO, would have been a bad decision.
Pages: 12