Why artificially limit your code to C? • Hacker News Board

Re: Why artificially limit your code to C?

#31

Post by ExpiredLink » Sat, Apr 14, 2012, 11:31 AM UTC

cageface wrote: post #24

ExpiredLink wrote: post #18

Earlier quoted context omitted.

> where the caller of your method is a closing brace Although I agree with the sentiment of your comment destructors and RAII in general are arguably the best C++ features. If I were forced to use C++ again I would restrict my code to a lightweight subset of C++, especially I would not use the C++ Standard library (STL, iostreams, string) and of course not use BOOST (or any template heavy library) and C++0x. But I wo…

The big problem with RAII and destructors is that you have no way of returning an error. You're not supposed to throw an exception and you have no way to return an error code so you can't really do much in a destructor if you want to write 100% correct code. Manually managing error codes is tedious but it's also more explicit and flexible.

> The big problem with RAII and destructors is that you have no way of returning an error.

That's actually a feature. Destructors are for cleanup. If code is supposed to report an error (by throwing an exception) it should not be put into a destructor.

Re: Why artificially limit your code to C?

#32

Post by cageface » Sat, Apr 14, 2012, 11:36 AM UTC

ExpiredLink wrote: post #31

cageface wrote: post #24

Earlier quoted context omitted.

The big problem with RAII and destructors is that you have no way of returning an error. You're not supposed to throw an exception and you have no way to return an error code so you can't really do much in a destructor if you want to write 100% correct code. Manually managing error codes is tedious but it's also more explicit and flexible.

> The big problem with RAII and destructors is that you have no way of returning an error. That's actually a feature. Destructors are for cleanup. If code is supposed to report an error (by throwing an exception) it should not be put into a destructor.

So if I have an RAII object that supposed to close or delete a file and that fails for some reason, then what?

Re: Why artificially limit your code to C?

#33

Post by ExpiredLink » Sat, Apr 14, 2012, 11:38 AM UTC

wladimir wrote: post #20

ExpiredLink wrote: post #18

Earlier quoted context omitted.

> where the caller of your method is a closing brace Although I agree with the sentiment of your comment destructors and RAII in general are arguably the best C++ features. If I were forced to use C++ again I would restrict my code to a lightweight subset of C++, especially I would not use the C++ Standard library (STL, iostreams, string) and of course not use BOOST (or any template heavy library) and C++0x. But I wo…

What would you use for string handling, then? Please don't tell me you prefer strcpy/strcat and zero-terminated strings?

A class or template that doesn't need 3 template parameters.

Re: Why artificially limit your code to C?

#34

Post by ExpiredLink » Sat, Apr 14, 2012, 11:51 AM UTC

cageface wrote: post #32

ExpiredLink wrote: post #31

Earlier quoted context omitted.

> The big problem with RAII and destructors is that you have no way of returning an error. That's actually a feature. Destructors are for cleanup. If code is supposed to report an error (by throwing an exception) it should not be put into a destructor.

So if I have an RAII object that supposed to close or delete a file and that fails for some reason, then what?

It depends.

- If the file has been opened for reading only you can put fclose into the destructor and safely ignore the return value.

- If the file has been opened for writing you need to call fclose() before the destructor to be able to react accordingly. Throwing an exception in the destructor would not be helpful in this case anyway because your scope is gone.

BTW, writing a file safely is much harder than what many internet sources and textbooks make it appear.

Re: Why artificially limit your code to C?

#35

Post by cageface » Sat, Apr 14, 2012, 12:21 PM UTC

ExpiredLink wrote: post #34

cageface wrote: post #32

Earlier quoted context omitted.

So if I have an RAII object that supposed to close or delete a file and that fails for some reason, then what?

It depends. - If the file has been opened for reading only you can put fclose into the destructor and safely ignore the return value. - If the file has been opened for writing you need to call fclose() before the destructor to be able to react accordingly. Throwing an exception in the destructor would not be helpful in this case anyway because your scope is gone. BTW, writing a file safely is much harder than what ma…

But similar constructions in other languages (Python's with- statement, various Lisp versions, using in C#) can handle this cleanly. C++ doesn't give you "finally" and since you can't do non-trivial cleanup in destructors RAII is really a lot less useful than it seems at first blush.

Re: Why artificially limit your code to C?

#36

Post by pjmlp » Sat, Apr 14, 2012, 2:17 PM UTC

TheNewAndy wrote: post #10

pjmlp wrote: post #7

Earlier quoted context omitted.

Everyone loves to bash the lack of a C++ ABI. Now please name another language with native implementations with a standard ABI across different compilers. C implementations have a standard ABI, because they usually are the operating system ABI.

I'm not sure what you mean here by "name another language". Do you mean other than C? I don't understand what that would demonstrate.

For example, Lisp, Scheme, Ada, Modula-3, Delphi, D, Go, Oberon don't have compiler implementations that produce object files compatible across vendors.

Usually you are only able to link to libraries compiled with the same compiler. The same way as it happens to C++.

Re: Why artificially limit your code to C?

#37

Post by pjmlp » Sat, Apr 14, 2012, 2:19 PM UTC

angersock wrote: post #12

pjmlp wrote: post #7

Earlier quoted context omitted.

Everyone loves to bash the lack of a C++ ABI. Now please name another language with native implementations with a standard ABI across different compilers. C implementations have a standard ABI, because they usually are the operating system ABI.

We love to bash it because it's shit. Also, to answer your question: Java, C#/Mono.

Ok, there you have a point, thanks to the bytecode as ABI.

I forgot about that, as I was thinking about compilation directly to native code, as I wrote my comment.

Re: Why artificially limit your code to C?

#38

Post by ExpiredLink » Sat, Apr 14, 2012, 3:23 PM UTC

cageface wrote: post #35

ExpiredLink wrote: post #34

Earlier quoted context omitted.

It depends. - If the file has been opened for reading only you can put fclose into the destructor and safely ignore the return value. - If the file has been opened for writing you need to call fclose() before the destructor to be able to react accordingly. Throwing an exception in the destructor would not be helpful in this case anyway because your scope is gone. BTW, writing a file safely is much harder than what ma…

But similar constructions in other languages (Python's with- statement, various Lisp versions, using in C#) can handle this cleanly. C++ doesn't give you "finally" and since you can't do non-trivial cleanup in destructors RAII is really a lot less useful than it seems at first blush.

In C++ you can write the cleanup code once in the destructor, "similar constructions in other languages" must be written every time you use it. You can and should do "non-trivial cleanup in destructors", e.g. DB rollback, but you should do only cleanup in destructors.

Re: Why artificially limit your code to C?

#39

Post by drucken » Sat, Apr 14, 2012, 5:22 PM UTC

Detailed comment on that stackflow thread says it all: life is short, use C.

Re: Why artificially limit your code to C?

#40

Post by pjmlp » Sun, Apr 15, 2012, 8:52 AM UTC

batista wrote: post #30

TheNewAndy wrote: post #10

Earlier quoted context omitted.

I'm not sure what you mean here by "name another language". Do you mean other than C? I don't understand what that would demonstrate.

That it's not that common?

No, because language standards only specify the language itself not the implementations.

So each vendor comes up with its own library format and tricks how to make the language usable in dynamic libraries. And as far as I know, they seldom talk among themselves about common ABIs.

C ends up being used as universal ABI, because in the end all implementations that generate native code need to interface with the operating system, which usually is developed in C.

But this was not always like this. Before C won its place as system programming language outside the UNIX world, there were other systems programming languages in use. On those systems there was no C ABI as such.

The Pascal calling convention ABI exists, because on the early 80s a few operating systems were developed in extended version of Pascal, like the first MacOS, for example.