Improving your templates' skills

Pages: 12
Aikon (75)
Hello everybody

If you are a programmer and you want to learn C++ ans especially templates.
Don't wait to follow me in this blog:

http://surprising-code.blogspot.com

My last post, overloading functions templates

http://surprising-code.blogspot.com/2012/02/overloading-function-templates.html

Thx
Gaminic (1621)
I'll gladly review your blog if you would be so kind to pick a colour scheme that didn't hurt my eyes. Unless you have a very good reason, the background of a blog should be white (or something very, very light in any case).

Also, I seem to remember you already posted a link to your blog a few days back. Please don't make new topics. If you really want feedback, bump your old topic!
morando (163)

I'll gladly review your blog if you would be so kind to pick a colour scheme that didn't hurt my eyes. Unless you have a very good reason, the background of a blog should be white (or something very, very light in any case).

+1 It painful to read.
Last edited on
guestgulkan (2942)
Agree with the comments so far about the colour scheme - no programmer is going to bother to read that.
therockon7throw (284)
I just left the page as soon as I see the black background
ne555 (10692)
Yeah white background with yellow and cyan foreground.
I like dark schemes.

1
2
 
//I'm using this macro just to write an end line, don't get used to, macros can be powerful and dangerous
#define print() std::cout << std::endl
¿then why are you using a macro?

inline T* const& max (T* const& a, T* const& b); puaj.
Aikon (75)
I'll gladly review your blog if you would be so kind to pick a colour scheme that didn't hurt my eyes. Unless you have a very good reason, the background of a blog should be white (or something very, very light in any case).

You are right, I got some criticism so I will consider your offering.

¿then why are you using a macro?

I'm just making an advise, macros in general is not a good practice, of course are useful and even
can improve reading code, but something so stupid like:

#define mult(a,b) a*b

It can make an unexpected result. Beside, I don't know what is the level of my readers,so if you are a skillful using macros, go ahead, but if not, take care about it.

inline T* const& max (T* const& a, T* const& b); puaj.

I really don't get it what you mean with puaj


I just left the page as soon as I see the black background

It's not necessary be unpleasant, if you don't like my blog just left, as you did, but isn't necessary the comment unless you are making constructive criticisms and isn't that case.

Thank you all
Gaminic (1621)
It is constructive; he's pointing out why he left.

On the macros: You're telling people not to use macro's, then you use macro's. That's a bit odd, especially since it's such a bad example. It definitely does not improve readability, partly because of the bad naming, partly because you could have made it a simple function instead. It would have been easier to understand, "better practice" and less hypocritical.

On "inline T* etc": That function signature is plain terrible. It seems like you wanted to throw in as many keywords and ref/adr operators in there as possible, without proper reason. If anything, you're confusing the people who read your blog.

Also, this:
inline char const* const& max (char const* const& a, char const* const& b){ Really? Come on, man. The few colourblind people still left reading are surely going to quit here.
Aikon (75)
On the macros: You're telling people not to use macro's, then you use macro's. That's a bit odd, especially since it's such a bad example. It definitely does not improve readability, partly because of the bad naming, partly because you could have made it a simple function instead. It would have been easier to understand, "better practice" and less hypocritical.

You are absolutely right, isn't a good practice so I will change it. For this reason, I was trying to advise that was an ungly macro and I didn't want people start doing something like mine.

But is better to fix it.


On "inline T* etc": That function signature is plain terrible. It seems like you wanted to throw in as many keywords and ref/adr operators in there as possible, without proper reason. If anything, you're confusing the people who read your blog.

That's not so terrible as you think what happens is that I'm trying to introduce bit a bit. So I like to explain my reasons slowly.

About the colors. I have to improved, but I don't have much time.


I really appreciate your comments, thank you.
cire (8284)
Well, the color issue seems to be fixed, but I have to agree with the other posters here. The content is poor and certainly not an example of "best practices." You should probably be refining your understanding of templates and their uses, not trying to inform others.
Aikon (75)
Well, the color issue seems to be fixed, but I have to agree with the other posters here. The content is poor and certainly not an example of "best practices." You should probably be refining your understanding of templates and their uses, not trying to inform others.

This blog only have 4 days, of course the content is poor.

New post: About constant and pointers:
http://surprising-code.blogspot.com/2012/02/pointer-versus-constant.html
cire (8284)
By poor, I meant of low quality. Not sparse.
Gaminic (1621)
@Aikon: the title of the post alone is reason enough for me not to read it. 'versus' signifies a one or the other relationship. There is no such thing for pointers and constants. 'Pointers versus references' makes sense; 'const versus define' might make sense. 'Pointers versus const'? Completely meaningless. Try thinking of a single situation where you could say "We can either use pointers, or a const for this!".
hanst99 (2869)
It would probably be better if you would just read on the subject instead of writing a blog about it. For example, reading boost code can be quite helpful in learning about templates (or rather, in how to perform magic with templates). If you insist on a blog (I guess it does help sometimes), you should probably work on your english skills. I am not exactly a language-genius myself, but even I can see that your grammar skills are somewhat lacking, which makes it kinda hard to understand what you're trying to say.
guestgulkan (2942)
I suppose if he wrote about C++011 rvalue references in template argument deduction .... :-))
Aikon (75)
@Gaminic: well, it's posible that my title isn't good enough because I'm not really facing off it, Pointers and constant is a bit better (If you have a better name for my low example please told me, my english is horrible).

Although, if you read it carefully, you'll note that I'm not really comparing them. Beside, I have the impression you don't get that I'm trying to make a course.

@guestgulkan: ..., like I said I'm trying to teach slowly, so It's better if I try to solve, in generel, the panic to pointers, and of course I know that char* is so low level.

@hanst99 About my english, you are absolutely right, and in fact, is one of my goals making this blog, improve it. I said it in the first post. I'll try to review my last posts.


Aikon (75)
hanst99 (2869)
You incorrectly label 
1
2
3
4
 
inline char const* max(char const* a, char const* b) {
     std::cout << "call-by-value" << std::endl;
     return (std::strcmp(a, b) < 0) ? b : a;
}


as call by value - this is call by reference. And it would be great if you dropped the "inline" - it doesn't add anything, and really just serves as an obfuscation of what's going on. Also, either use const char* or char const *, don't alternate between the two.

Also, the problem here really isn't with references, but with you having ambiguous overloads. The issue there also isn't that one is call by reference and the other one isn't, but that due to the way the function is defined the pointer get's wrapped up within a reference, and that in C++ references have slightly different semantics than pointers.
cire (8284)
Technically that is call by value. Pointers, like most types, are passed by value.
Aikon (75)
Last edited on
Pages: 12